Current Server Time: 03:30 (Central Europe)

#apertus IRC Channel Logs

2013/11/30

Timezone: UTC


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