00:00 | rexbron | left the channel | |
00:00 | theverant | I just ask because I have that stuff available to me
| |
00:00 | rexbron | joined the channel | |
00:00 | rexbron | left the channel | |
00:00 | rexbron | joined the channel | |
00:00 | theverant | if you want footage to compare what you are pulling from your system
| |
00:00 | Bertl | when somebody thinks, this feature would be cool, here have a camera to show you how it does or doesn't work
| |
00:00 | Bertl | so you will be a valuable asset when we get to testing
| |
00:01 | theverant | like I said, I'd like to help if I can
| |
00:01 | Bertl | appreciated!
| |
00:02 | theverant | I wish I had a vector to fish around for some grant money
| |
00:02 | Bertl | so, in case you are really planning to build an axiom alpha prototype, please make sure to contact me for updated layouts and a bunch of tips how to assemble the FE
| |
00:03 | Bertl | (as well as getting the software part working)
| |
00:04 | theverant | You mean the camera system software? Or software to work with the footage?
| |
00:04 | Bertl | the development/build system for the camera software, yes
| |
00:04 | Bertl | i.e. FPGA bitstream, linux kernel and userspace
| |
00:05 | Bertl | regarding post processing you probably know better than I do :)
| |
00:06 | theverant | yes, well, maybe an area I can help as well
| |
00:08 | Bertl | great!
| |
00:15 | theverant | Are you familiar with Red's wifi based remote control system?
| |
00:16 | Bertl | nope
| |
00:16 | theverant | "Redmote" (I really hate their naming scheme)
| |
00:16 | theverant | oh!
| |
00:16 | theverant | It's so useful
| |
00:16 | theverant | basically the camera has wifi, as does the remote
| |
00:16 | theverant | you pair them together
| |
00:17 | Bertl | well, we plan to have ethernet, probably wifi as well
| |
00:17 | theverant | and you have this device which you can remote start/stop, control menus, etc
| |
00:17 | theverant | it mounts directly to the module mount on the camera
| |
00:17 | theverant | to charge, or just to use it attached
| |
00:17 | Bertl | and we definitely plan to allow modifying all aspects via network
| |
00:18 | Bertl | may it be via applets on smarphones or just a web browser
| |
00:18 | theverant | yeah, a iOS app could achieve the same thing without proprietary (expensive) hardware
| |
00:18 | theverant | yeah, great idea
| |
00:18 | theverant | wifi ought to be part of the central body
| |
00:18 | guesst | have you tried to use a smartphone with wet hands ? :)
| |
00:19 | theverant | ethernet makes sense as a module
| |
00:19 | theverant | lol
| |
00:19 | theverant | yeah
| |
00:19 | theverant | sometimes specialized hardware is useful
| |
00:19 | Bertl | guesst: probably depends on the digitizer
| |
00:19 | theverant | physical wheels make a lot of sense too
| |
00:19 | theverant | but you could build a controller very cheaply with Arduino and wifi
| |
00:20 | Bertl | ethernet will probably be a base I/O for several reasons
| |
00:20 | theverant | oh? Interesting
| |
00:20 | Bertl | with wifi, there are at least two issues ...
| |
00:21 | Bertl | first, it is not easy to find a wifi module/stack which doesn't require proprietary firmware blobs
| |
00:21 | Bertl | (unfortunate one of the lost freedoms)
| |
00:21 | theverant | right
| |
00:22 | Bertl | secondly, I'm not convinced that you want somebody in the vicinity to disrupt or even hijack your camera and maybe attached motion system :)
| |
00:22 | theverant | Doesn't seem to be a problem with the Red cameras
| |
00:22 | theverant | it's not an open SSID on there
| |
00:22 | theverant | plus you have to pair the devices with each other before you can remotely control
| |
00:23 | Bertl | I'm pretty sure that the TV manufacturers will tell you that the TV-off gadgets are not a problem either :)
| |
00:23 | guesst | never heard of ssl?
| |
00:23 | theverant | there must be some secure handshake routine you could use. Obviously it is a point of potential weakness
| |
00:23 | guesst | why it has to be so open
| |
00:23 | theverant | but the benefits would outweigh the negatives
| |
00:24 | Bertl | yes, there are many options, just not convinced that (open) wifi should be one of them :)
| |
00:24 | theverant | no I never said open wifi, that's a terrible idea
| |
00:24 | guesst | there is no difference between an open/closed wifi... the application has to be secure
| |
00:24 | theverant | but wifi as a protocol because of it's flexibility
| |
00:25 | guesst | you can as well as break an eth cable and steal control
| |
00:25 | Bertl | but I suggest to try to make a point by finding a wifi module which works just fine on linux without binary blobs
| |
00:25 | guesst | does it matter if a blob is part of module (pre-flashed) or not part of it (ram-only module) ?
| |
00:26 | Bertl | as long as it doesn't involve special royalties or conditions, a hardware module with a well documented interface will be fine
| |
00:27 | Bertl | the problem with most devices is that they do require a proprietary driver, and that is not really an option for us
| |
00:27 | guesst | browse the linux sourcecodes (or ask on list) and make a deal with the maker of that super wifi
| |
00:28 | Bertl | note that bluetooth might be a viable alternative
| |
00:29 | guesst | what if blackmagic makes their cameras open to custom firmwares? (or somebody hacks them?)
| |
00:29 | Bertl | then the world will be a better place I guess? :)
| |
00:31 | theverant | doesn't Bluetooth have relatively poor range?
| |
00:31 | guesst | if you put it in a metal box, yes
| |
00:31 | Bertl | well, about 20m should be fine, up to 100m on open range I'd say
| |
00:31 | theverant | everything sucks inside a metal box
| |
00:32 | theverant | that;s why the Red cameras have a plastic cover over the wifi module
| |
00:32 | guesst | others got antennas
| |
00:32 | theverant | nah, antennas are silly
| |
00:33 | theverant | unless you are running an ENG style camera and need the crazy range
| |
00:33 | theverant | antenna is just something to break off in a cinema style shoot
| |
00:33 | guesst | rather an antenna than lost control..
| |
00:33 | Bertl | actually zigbee works exceptionally well inside metal boxes :)
| |
00:33 | theverant | yeah I figured you'd play that card :D
| |
00:33 | guesst | running with $100k over the place an you worry about breaking an antenna?:)
| |
00:34 | theverant | guesst: have you even done a cinema style shoot with a crew?
| |
00:35 | guesst | nope
| |
00:35 | theverant | you don't want little bits sticking off the camera, trust me
| |
00:35 | theverant | especially if they are required for communicating with the camera
| |
00:35 | theverant | there are already going to be wires everywhere
| |
00:36 | theverant | things being attached and detached
| |
00:36 | theverant | if you did have a small antenna it would have to be recessed, protected somehow
| |
00:37 | theverant | but yeah
| |
00:37 | theverant | zigbee would be awesome
| |
00:37 | theverant | too bad most devices don't natively support it
| |
00:37 | theverant | but what if Zigbee on the camera and a Zigbee-wifi bridge? would that still be a no no for you guys?
| |
00:38 | theverant | Bertl: do you get sick of people telling you how to build your camera? :D
| |
00:38 | Bertl | there is no no-no per se, even if we decide not to go this or that route for whatever reason, you still can add that part yourself (or find somebody to do it for you)
| |
00:39 | Bertl | no, actually I appreciate it like I appreciate all input ... it just depends on how the information is presented and what arguments come up
| |
00:40 | Bertl | usually information which is accompanied by expressions like 'because I say so' or 'that's how it is supposed to be' get a lower rating than those presented with a striking argument :)
| |
00:43 | theverant | but what if I'm *right*? :D
| |
00:44 | theverant | "build your own damn camera
| |
00:44 | theverant | "
| |
00:44 | theverant | hahaha :D
| |
00:45 | guesst | what happened with the elphel cameras?
| |
00:45 | guesst | would not be much easier to make for them a new sensor front, they were opensource and open for such a mod..
| |
00:46 | Bertl | they are still built and improved by andrey, AFAIK
| |
00:46 | Bertl | the problem is more that andrey doesn't really want to share development stuff
| |
00:47 | Bertl | unfortunately, there will be some parallel develeopment, but I still hope we will be able to exchange in some way
| |
00:48 | Bertl | (for example, you won't we able to get access to the latest designs, may it be schematic or layout with elphel)
| |
00:48 | guesst | well, he has to run the business somehow
| |
00:49 | Bertl | that is alays the problem with and/or explanation for not being open :)
| |
00:49 | guesst | so you can make business and be open? or you just like to work for free? :)
| |
00:49 | Bertl | both, yes
| |
01:07 | Bertl | off to bed now ... have fun!
| |
01:15 | dmj_nova | btw: Bertl there are now a number of wifi modules with open drivers, some are still closed but they shouldn't be problematic to avoid.
| |
01:18 | dmj_nova | also, regarding wifi controllable cameras and security, Novacut has some nifty open source secure peering technology.
| |
01:18 | dmj_nova | We use it it peer computers for collaborative editing and asset management.
| |
02:19 | theverant | left the channel | |
04:18 | dmj_nova | left the channel | |
04:18 | dmj_nova1 | joined the channel | |
06:59 | Wescotte | joined the channel | |
07:29 | Bertl | morning folks!
| |
08:02 | dmj_nova1 | Bertl: I don't think finding wifi with open drivers will be much of an issue
| |
08:03 | dmj_nova1 | It's not 2007 anymore
| |
08:03 | Bertl | maybe you can make a suggestion for a module which can be easily integrated and has open drivers then?
| |
08:03 | dmj_nova1 | though we may need to avoid one or two of the major brands
| |
08:04 | dmj_nova1 | I'm not entirely certain as to the easily integrated part
| |
08:06 | Bertl | well, we probably won't have high bandwidth USB, and we definitely do not have PCI(e) or related interfaces
| |
08:07 | Bertl | anything which connects to a microcontroller or operates like an ethernet phy would be fine though
| |
08:07 | dmj_nova1 | but an intel or atheros chip at least has open source drivers to my knowledge
| |
08:08 | dmj_nova1 | broadcom has binary crap unless that's changed recently
| |
08:09 | dmj_nova1 | system76 might have a good idea as to wifi driver support, though interfacing with custom boards is another story
| |
08:10 | Bertl | http://hackaday.com/2013/08/09/tiny-wifi-modules-again/
| |
08:10 | Bertl | something like this might work 'out of the box' and be sufficient for remote control
| |
08:10 | dmj_nova1 | http://en.wikipedia.org/wiki/Comparison_of_open_source_wireless_drivers
| |
08:13 | Bertl | well, I know the atheros chips, I even used a bunch of atheros cards back then -- the driver was horrible :)
| |
08:13 | Bertl | that might have changed over the past few years though
| |
08:15 | Bertl | I'm not sure what the missing fields in the non-free firmware required column mean for the realtek chips
| |
08:15 | Bertl | but it general, the question is what you want to do via wifi
| |
08:15 | dmj_nova1 | Bertl: either means unknown (to the author) or not applicable
| |
08:16 | dmj_nova1 | Bertl: Could be lots of things
| |
08:16 | Bertl | I'm mostly interested in the amount of data
| |
08:16 | dmj_nova1 | remote operation, transmission to video village, peering with other devices
| |
08:17 | dmj_nova1 | granted you couldn't transmit everything in full quality in realtime, but you could do very interesting things
| |
08:18 | dmj_nova1 | plus, I'd recommend integrating a wifi AC chip
| |
08:18 | Bertl | can you put any bandwidth numbers on those things?
| |
08:19 | dmj_nova1 | realtime video transmission would need to be lower quality (generate jpegs and send those), so it's whatever your encoding is
| |
08:19 | Bertl | one frame per second :)
| |
08:19 | dmj_nova1 | but you can totally send HD video over wifi, bandwidth just affects the bitrate
| |
08:20 | Bertl | what would be the point to send HD video in terrible quality over wifi from a movie camera?
| |
08:20 | dmj_nova1 | as far as sending full-quality, the camera could catch up between takes
| |
08:21 | dmj_nova1 | say you can't tether the camera with a physical cable
| |
08:21 | dmj_nova1 | such a thing would let the director see the live camera output
| |
08:22 | Bertl | well, if you have such a special scenario, I guess it is easy to hook up a wireless bridge to the gigabit ethernet port and be done, no?
| |
08:24 | dmj_nova1 | Though that would be more cumbersome
| |
08:25 | Bertl | why?
| |
08:25 | dmj_nova1 | Another dongle to mount on your camera
| |
08:25 | dmj_nova1 | then setting up the wireless bridge becomes another task, etc.
| |
08:27 | Bertl | well, we can't integrate everything into the camera, otherwise it will require four people to carry it, not speaking of the batteries :)
| |
08:27 | Bertl | and if you encounter this setup on a regular basis, the bridge will be already configured
| |
08:27 | dmj_nova1 | true, though I doubt a wifi chip will change much
| |
08:28 | Bertl | feel free to design a module/extension for that
| |
08:28 | dmj_nova1 | Wifi could also be on a separate board attached to the main bus
| |
08:28 | dmj_nova1 | in the storage unit would make sense
| |
08:29 | Bertl | sorry, not to me -- I don't see why you would want to torture your SSDs with wifi :)
| |
08:31 | dmj_nova1 | Persistent wifi + storage = automation
| |
08:31 | dmj_nova1 | so the camera and your PC can manage your footage behind the scenes without you fussing
| |
08:33 | dmj_nova1 | Before you even plug in your SSDs, the ingest machine would already have a head start with material being logged and backed up.
| |
08:33 | Bertl | do a quick calculation what amount of data we are talking about and how long the synchronization via wifi would take
| |
08:33 | dmj_nova1 | which would save quite a bit of time on set
| |
08:34 | Bertl | also calculate what amount of efford would go into handling partial syncs and proper recombination
| |
08:34 | dmj_nova1 | also considering an 8:1 ratio of minutes on set to minutes recorded
| |
08:34 | dmj_nova1 | Bertl: no effort at all
| |
08:35 | dmj_nova1 | (providing you structure your data well)
| |
08:37 | Bertl | btw, is this a real world scenario at all, i.e. that you want to process your raw footage on site? wouldn't it make much more sense to record everything and then do the time consuming post processing somewhere else?
| |
08:38 | dmj_nova1 | You could get up to 5 fps under optimal conditions
| |
08:39 | dmj_nova1 | Bertl: so there are stages: recording, ingest, logging, light grade, editing, final grading...
| |
08:39 | dmj_nova1 | recording is what your camera does
| |
08:40 | dmj_nova1 | ingest is importing the footage from the camera's recording media to your asset management system
| |
08:41 | dmj_nova1 | logging is going through the footage, tagging it and such
| |
08:41 | dmj_nova1 | depending on the production, at least recording and ingest are done on set
| |
08:42 | dmj_nova1 | but logging, light grade, and even editing may also be done on set
| |
08:45 | dmj_nova1 | It used to be that you began the logging process with the "dailies" after the film lab got done processing the footage from the previous day's shoot, but with digital you can start whenever the files are on a computer
| |
08:47 | dmj_nova1 | If you give the option to process on site, some filmmakers won't use it and some will.
| |
08:48 | Bertl | assuming your 'computer' can handle the bandwidth, the SSDs can be read with 500MB/s and more, that means roughly 30 minutes for a single SSD with 1TB
| |
08:49 | Bertl | of course, there is no reason to copy those disks one after the other (except for maybe the limited performance of your storage system)
| |
08:51 | Bertl | assuming that you will barely get 25MB/s over wifi, this means roughly 10 hours for a single drive over wifi
| |
08:51 | Bertl | note that this would require the wifi to be used exclusively for transferring the data
| |
08:55 | dmj_nova1 | I don't think only 25MB/s is a safe assumption with wifi anymore
| |
08:55 | dmj_nova1 | it's a baseline, but you can easily get more
| |
09:00 | dmj_nova1 | Bertl: so wifi AC can achieve close to 7gbps theoretically and maybe 1.7-2.5 gbps in practice
| |
09:01 | dmj_nova1 | of course that's best case
| |
09:03 | Bertl | which one from the list was the AC chipset with open drivers and firmware?
| |
09:05 | troy_s | You never edit on set.
| |
09:05 | dmj_nova1 | troy_s: that's true for *most* filmmakers
| |
09:05 | troy_s | Perhaps to test an effects shot or a alug.
| |
09:05 | dmj_nova1 | there are some exceptions
| |
09:06 | troy_s | That is true for all. I have done the gamut sir. ;)
| |
09:06 | troy_s | And even temp edits aren't editorial.
| |
09:06 | troy_s | Pure tests.
| |
09:06 | dmj_nova1 | Robert Rodriguez does
| |
09:06 | troy_s | A one light for certain
| |
09:06 | dmj_nova1 | troy_s: fair enough
| |
09:07 | troy_s | (which is done off of the high quality raws and often baked into the editorials)
| |
09:09 | dmj_nova1 | Bertl: of course with modern chips, it seems you will likely get under 100 MB/s in actual TCP throughput
| |
09:09 | dmj_nova1 | troy_s: do you need all the frames for doing a one light?
| |
09:10 | troy_s | Normally the DIT is pulling the full raws and doing the one light.
| |
09:11 | dmj_nova1 | I mean, does the DIT need access to all the raws from a given clip to begin working on the one light?
| |
09:11 | troy_s | And the resultant LUT would be baked into editorial, so yes, they would need the frames.
| |
09:11 | troy_s | Simple example from an F65 would be to take the deck disk and do a copy and grade, then bake the crap editorials.
| |
09:11 | Bertl | dmj_nova1: single stream maximum of 802.11ac is 866Mbit/s under optimal conditions
| |
09:12 | troy_s | Yes.
| |
09:12 | troy_s | The DIT would do a dupe off of the original disk.
| |
09:12 | dmj_nova1 | Bertl: yeah, I already checked and the first source (which I commented from initially) got it wrong
| |
09:12 | dmj_nova1 | they multiplied a number already factored in
| |
09:13 | Bertl | also note that if you have a 1:8 recording/non-recording ratio, you can easily do all the transfers with just two sets of SSDs
| |
09:13 | dmj_nova1 | looking at actual benchmarks, 250-600 mb/s looks typical
| |
09:13 | troy_s | rexbron can likely walk you through a few typical scenarios better than I as he has been a DIT a few times.
| |
09:13 | Bertl | i.e. just change the SSD pack in the first pause and you'll be done before the next recording starts
| |
09:13 | dmj_nova1 | troy_s: of course you'd actually get all the frames that day
| |
09:13 | troy_s | 8 to 1 shooting ratio?
| |
09:14 | Bertl | that was a (random) number dmj_nova1 picked to argue for transferring the footage over wifi
| |
09:14 | troy_s | I have yet to see wifi transfer.
| |
09:14 | dmj_nova1 | was mainly considering whether you could do the human grading labor before all the files had finished copying if the system would take care of applying the LUT to the frames as they arrived
| |
09:15 | troy_s | SDI everywhere. Teradek or such for wireless display.
| |
09:15 | troy_s | Most of the DIT rigs I see are based off of a dumper at the station itself.
| |
09:15 | troy_s | Either a R3D rocket scenario or the Sony reader etx.
| |
09:16 | troy_s | (and of course fiber)
| |
09:17 | dmj_nova1 | troy_s: what recieves the teradek signal at video village?
| |
09:18 | dmj_nova1 | it's just an h.264 stream right?
| |
09:18 | troy_s | Personally I would think it is all moot by and large given the target audience. Likely say, dual SSDs on board? Then all one would need is an eSATA or USB3 or Tbolt drive dock.
| |
09:18 | troy_s | The bolts I have seen for remote heads etc.
| |
09:18 | Bertl | precisely
| |
09:18 | dmj_nova1 | yeah, the teradek stuff looks to use high speed wifi
| |
09:18 | troy_s | I have no clue about Bolt protocols.
| |
09:18 | troy_s | Also have seen custom microwave units etx.
| |
09:19 | Bertl | dmj_nova1: maybe consider a proper directional microwave link?
| |
09:19 | troy_s | Basic idea is "take disk from camera and dump" and that applies right up the food chain in my experience.
| |
09:20 | Bertl | you could get really good rates with that and even supply the camera with power or recharge during breaks :)
| |
09:20 | troy_s | (where the raw disks are also taken to the lab for file vaulting / archiving)
| |
09:20 | troy_s | Microwaves still freak me out. There are some xmitters that easily exceed regulations.
| |
09:21 | Bertl | yeah, you must make sure not to step into the beam, otherwise you'll get fried :)
| |
09:21 | troy_s | But for a get-it-done goal driven mindset, SSDs or dual SSD striping or whatever would seem fine.
| |
09:21 | dmj_nova1 | no, do not stripe
| |
09:21 | dmj_nova1 | bad
| |
09:21 | dmj_nova1 | evil
| |
09:21 | troy_s | Huh?
| |
09:22 | dmj_nova1 | can lead to data loss much more easily
| |
09:22 | troy_s | If all you can muster is a stripe, so be it.
| |
09:22 | Bertl | there will be striping unless the SSDs get really fast soon
| |
09:22 | troy_s | Striped frames.
| |
09:22 | troy_s | Not a bloody raid.
| |
09:22 | dmj_nova1 | troy_s: oh
| |
09:22 | dmj_nova1 | that's fine
| |
09:22 | troy_s | Nothing wrong with striping though.
| |
09:23 | dmj_nova1 | as long as individual files are put on a normal filesystem I'm cool with it
| |
09:23 | Bertl | dmj_nova1: what kind of data loss do you see/expect with striping?
| |
09:23 | troy_s | And I can't see Bertl quietly designing a new bus protocol that suddenly eliminates overheads. :)
| |
09:23 | dmj_nova1 | Bertl: RAID array striping easily results in brokenness
| 09:23 | Bertl | puts that on the todo list right after world domination
|
09:24 | dmj_nova1 | As far as alternating frames accross drives, yeah, we should
| |
09:24 | troy_s | I have yet to see it "easily" in my experience, but alas... only a useless personal anecdote.
| |
09:24 | troy_s | I have only seen RAID striping suck with hardware RAID, and that is always a snapped controller doing its own thing.
| |
09:25 | Bertl | well, I've implemented striping systems (up to 16 disks) for various customers (for performance reasons) and there has never been a problem except for failing drives
| |
09:25 | dmj_nova1 | At the data volumes we're looking at, we may want file-based striping and mirroring
| |
09:25 | troy_s | But again, living in reality when designing is never a bad thing. Get-er'-done is infinitely better than never-done. Or to quote Patton "A good plan today is better than a perfect plan tomorrow."
| |
09:25 | dmj_nova1 | Because if you're shooting terabytes a day, you will get bad copies on a daily basis
| |
09:26 | Bertl | of course, you increase the potential for failure with each and every drive, but except for that, I don't see what should go wrong
| |
09:26 | troy_s | All hypothetical.
| |
09:26 | dmj_nova1 | Bertl: you should expect an unrecoverable read error every 3TB or therabouts
| |
09:26 | troy_s | Having a camera that can shoot five minutes is still infinitely far away. ;)
| |
09:26 | Bertl | troy_s: speaking of getting things done ... I finished the second alpha prototype :)
| |
09:27 | dmj_nova1 | Bertl: :)
| |
09:27 | troy_s | Wow. Better sensor?
| |
09:27 | Bertl | yes, it is a 'perfect' sensor, but it isn't mounted yet
| |
09:27 | troy_s | I will have some uptime near XMas before Spain.
| |
09:27 | troy_s | I will try to get an OCIO LUT set done.
| |
09:27 | dmj_nova1 | Bertl: what year was your RAID experience in?
| |
09:27 | Bertl | dmj_nova1: you should change the brand of your SSDs :)
| |
09:28 | dmj_nova1 | Bertl: the numbers are based on manufacturer specs
| |
09:28 | Bertl | if you get an unrecoverable read error every 3TB :)
| |
09:29 | dmj_nova1 | Bertl: with striping you would likely not even notice
| |
09:29 | troy_s | I would think the project would be celebrating a read error.
| |
09:29 | Bertl | one of my customers has a striped SSD raid with 6 disks, which has a data throughput of about 200TB each night
| |
09:29 | dmj_nova1 | It would just silently give you data different than was stored
| |
09:30 | Bertl | the data is checksummed, so any error would show up
| |
09:30 | troy_s | We should exert an effort to stay in reality
| |
09:30 | dmj_nova1 | Ah, SSD
| |
09:30 | Bertl | over the last 3 years, there have been about 12 replacements
| |
09:30 | Bertl | (because the disks just died :)
| |
09:30 | troy_s | Which currently is a "camera" that is mounted to a room and can only shoot still frames.
| |
09:31 | dmj_nova1 | troy_s: what kind of drives are used for post production, is it all SSD based?
| |
09:31 | Bertl | but there hasn't been a single uncorrectable read error yet .. so do the math :)
| |
09:31 | troy_s | And isn't even profiled.
| |
09:31 | troy_s | dmj_nova1: Personally? I use mag disks and SSDs.
| |
09:31 | troy_s | Mags for storage and SSDs for working slushes.
| |
09:32 | troy_s | I think rexbron does a similar thing.
| |
09:32 | dmj_nova1 | mag disk?
| |
09:32 | troy_s | Mags are cheap and reasonably brisk.
| |
09:32 | troy_s | Magnetic.
| |
09:32 | Bertl | btw, in what way would 'silently giving wrong data' be different with a single disk vs striped?
| |
09:33 | dmj_nova1 | troy_s: you mean hard drives?
| |
09:33 | troy_s | Yes
| |
09:33 | dmj_nova1 | okay
| |
09:33 | Bertl | yes, those are magnetic disks
| |
09:33 | troy_s | Just use a dock.
| |
09:33 | troy_s | Cost effective
| |
09:33 | dmj_nova1 | yeah, I know HDDs are magnetic disks, just am not used to them being called "mag disks"
| |
09:34 | dmj_nova1 | Bertl: 'silently giving wrong data' is the same for single vs striped
| |
09:34 | Bertl | so back to why striping is 'very bad' then, I guess?
| |
09:34 | dmj_nova1 | in parity raid, it's a killer because it can seriously fuck more data up in the name of "correcting" the data
| |
09:35 | Bertl | nobody uses mirror raid without quorum :)
| |
09:35 | troy_s | You boys are being silly zippers.
| |
09:35 | Bertl | well, yeah, maybe some folks do, but nobody seriously interested in keeping their data :)
| |
09:35 | troy_s | No camera yet remember?
| |
09:35 | troy_s | ;)
| |
09:36 | dmj_nova1 | I don't like to rely on anything that propagates hardware failure
| |
09:36 | Bertl | troy_s: we trust that you are already working on it ... :)
| |
09:36 | dmj_nova1 | striping is fine as long as it's not at the partition level
| |
09:36 | Bertl | no, I wouldn't stripe a partition
| |
09:36 | Bertl | I definitely would stripe the entire disk :)
| |
09:36 | dmj_nova1 | but alternating frames is fine
| |
09:36 | troy_s | To be fair... HFS propagates corrupted data and it is the most in-vogue OS out there right now.
| |
09:37 | dmj_nova1 | stripe at the file level, not the filesystem level
| |
09:37 | dmj_nova1 | who the fuck uses HFS?
| |
09:37 | Bertl | all mac os users I guess?
| |
09:38 | dmj_nova1 | well, OS X and Windows do have shit file systems
| |
09:38 | Bertl | well, actually HFS+, but those are details
| |
09:38 | dmj_nova1 | oh "in vogue OS" not "in vogue filesystem"
| |
09:39 | dmj_nova1 | Bertl: So for striping, I'm uncomfortable with anything that you couldn't plug any single disk from the set into a machine and have it just work.
| |
09:39 | troy_s | if Bertl gave me a 150 fps 12 stop prototype that fragged frames every 3 tb I would be ecstatic actually...
| |
09:40 | Bertl | LOL
| |
09:41 | dmj_nova1 | btw, my whole thing about file systems and wifi transmission is that I think it's possible to do better than the status quo given the right foundation
| |
09:42 | Bertl | like with dmj_nova1's eight antenna wireless sync module and basestation ... soon to be designed :)
| |
09:43 | Bertl | I agree that it is a good thing to explore possibilities
| |
09:43 | Bertl | without that, there is no progress
| |
09:44 | Bertl | I also agree that both wifi and storage is not our primary concern for the next stage (after the crowd funding)
| |
09:44 | troy_s | Get-it-done-tomorrow
| |
09:44 | Bertl | we will be busy identifying the proper baseboard and sensor interfaces and hopefully figure out a way to make it extensible
| |
09:45 | troy_s | If Ax keeps that thinking, it is all win.
| |
09:45 | Bertl | Ax?
| |
09:45 | troy_s | Similar vein in creating work - leave the speculative fictions that change directions for Project Next.
| |
09:45 | troy_s | Axiom
| |
09:45 | Bertl | ah, we have a two letter acronym already, nice!
| |
09:46 | troy_s | Project Next always appears more appealing than Project Must Finish
| |
09:46 | troy_s | Ax - The Scent of Vapourcamera.
| |
09:47 | dmj_nova1 | haha
| |
09:49 | troy_s | dmj_nova1: I have to ask...
| |
09:49 | dmj_nova1 | ask away :P
| |
09:49 | Bertl | off for now ... bbl
| |
09:49 | troy_s | dmj_nova1: What the _fsck_ is going on with Novacut?
| |
09:59 | dmj_nova1 | mostly improvements to dmedia for the moment, though there's some other things that are pretty exciting
| |
10:09 | troy_s | DMedia confuses the shit out of me.
| |
10:09 | troy_s | But alas... must sleep. Joy.
| |
10:09 | troy_s | Night all. Be well.
| |
10:09 | troy_s | Nacht dmj_nova1.
| |
13:23 | jucar1 | joined the channel | |
13:24 | jucar | left the channel | |
17:48 | philippej | joined the channel | |
18:04 | Wescotte | left the channel | |
18:50 | jucar1 | left the channel | |
19:05 | jucar | joined the channel | |
20:25 | philippej2 | joined the channel | |
20:28 | philippej | left the channel | |
20:41 | philippej2 | left the channel | |
21:06 | intracube | left the channel | |
21:32 | se6astian | joined the channel | |
21:37 | se6astian | good evening
| |
21:37 | Bertl | evening!
| |
21:39 | se6astian | are you at the happylab?
| |
21:48 | guesst | will be there any 4k video footage from the prototype soon?
| |
22:02 | Bertl | nope
| |
22:02 | guesst | you are doing a 4k camera and you can not show footage?
| |
22:02 | guesst | silly as blackmagic :)
| |
22:02 | guesst | at least they got a brand
| |
22:09 | Bertl | we will do 4k snapshots and full HD footage, the prototype cannot handle more output
| |
22:10 | Bertl | it is a limitation of the zedboard's I/O
| |
22:10 | guesst | there are lot of other boards with fmc
| |
22:11 | guesst | i suggest to get some of those
| |
22:11 | Bertl | send us one
| |
22:11 | guesst | you can borrow one from xilinx dist
| |
22:11 | guesst | i got some older, they are not fmc
| |
22:11 | guesst | consider it, gotta go
| |
23:15 | troy_s | Oh god.
| |
23:15 | troy_s | 4k. 4k. 4k.
| |
23:15 | troy_s | Junk bullshit numbers everywhere.
| |
23:15 | Bertl | yeah, 4k looks completely different than 2k :)
| |
23:16 | troy_s | Such idiocy.
| |
23:16 | troy_s | Using the mythical numbers of the sunglasses-cum-camera vendor, the Panavision Genesis mark one was a 6k camera.
| |
23:17 | troy_s | The _only_ 4k camera currently on the market is the Sony F65, and I am quite certain no troll in this channel has ever touched one.
| |
23:18 | troy_s | (With perhaps an exception for rexbron)
| |
23:25 | Bertl | hehe
| |
23:43 | se6astian | time for bed
| |
23:44 | se6astian | already later than usual for me :)
| |
23:44 | se6astian | good night!
| |
23:44 | se6astian | left the channel |