[Ffmpeg-devel-irc] ffmpeg-devel.log.20140208

[burek]

[00:12] <saste> ubitux: ping
[00:12] <ubitux> saste: pong
[00:13] <saste> ubitux, about the misc libavfilter task, i'm not going to mentor it
[00:13] <saste> should i remove it, or do you want to mentor it?
[00:13] <ubitux> can i answer that tomorrow?
[00:13] <ubitux> i need to read that wiki page&
[00:13] <saste> also some entries should be removed, for example lua scripting and the part about the controller filter
[00:13] <saste> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2014
[00:14] <saste> ubitux: ^ reading is easy :)
[00:14] <ubitux> brain is off, i'll probably go to sleep in a few minutes
[00:29] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:1a3ed056c523: avcodec/hevc: make check for previous slice segment tighter
[00:29] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:64278039e55f: avcodec/hevc: Simplify get_qPy_pred()
[00:49] <cone-12> ffmpeg.git 03Martin Storsjö 07master:5bcbb516f2ff: arm: Add X() around all references to extern symbols
[00:49] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:bf90abe1dd51: Merge commit '5bcbb516f2ff45290ef7995b081762e668693672'
[00:54] <cone-12> ffmpeg.git 03Martin Storsjö 07master:e3fec3f095ab: arm: Add EXTERN_ASM to the .func and .type declarations for exported symbols
[00:54] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:a7574a36afa1: Merge commit 'e3fec3f095ab5ea08ee662942d98526aaf5e3635'
[01:03] <cone-12> ffmpeg.git 03Christophe Gisquet 07master:2bd44cb70534: dcadsp: add int8x8_fmul_int32 to dsp context
[01:03] <cone-12> ffmpeg.git 03Christophe Gisquet 07master:481a46a462ca: dcadsp: add int8x8_fmul_int32 to DSP context
[01:04] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:7ffe78a445f4: Merge commit '2bd44cb705340c4f7bd7e459a1efed5074bf45fc'
[01:13] <BBB> kurosu_: yeah I really like the optimizations you're doing, there's lots of codecs with virtually no simd so this helps a lot
[01:21] <cone-12> ffmpeg.git 03Christophe Gisquet 07master:5b59a9fc6152: x86: dcadsp: implement int8x8_fmul_int32
[01:21] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:82ae8a44e631: Merge commit '5b59a9fc6152169599561f04b4f66370edda5c9c'
[02:15] <BBB> ubitux: fuzzed7.ivf fixed
[02:54] <cone-12> ffmpeg.git 03Christophe Gisquet 07master:5fdbfcb5b793: dcadsp: split lfe_dir cases
[02:54] <cone-12> ffmpeg.git 03Christophe Gisquet 07master:45854df9a522: dcadsp: split lfe_dir cases
[02:54] <cone-12> ffmpeg.git 03Michael Niedermayer 07master:5794e9fce22a: Merge remote-tracking branch 'qatar/master'
[03:15] <cone-12> ffmpeg.git 03Lukasz Marek 07master:aeb2905fb7ce: lavc/jpeg2000dec: silent warning discards qualifiers
[03:15] <cone-12> ffmpeg.git 03Lukasz Marek 07master:3f47e24cbeb8: lavc/mpegvideo: add missing const
[04:44] <cone-12> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:47ba4728149f: ffserver: cosmetics and grammar
[04:44] <cone-12> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:1507e2a09532: ffserver: drop obvious comment
[04:44] <cone-12> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:db93c2d03131: ffserver: move misplaced comment
[04:44] <cone-12> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:958d98cc1cac: ffserver: drop unneeded delay1 var
[08:32] <kurosu_> BBB: like for you, time's available is the limit
[08:32] <kurosu_> I have been sitting on these for 2 years...
[08:33] <kurosu_> sometimes reviews are taking more time than what they really should, in particular when you actually have to spend time playing catchup
[11:00] <ubitux> BBB: ah, cool
[11:00] <ubitux> thanks
[11:00] <ubitux> i found a way to simplify a little the transpose in 44/48/84/88
[11:00] <ubitux> (final one)
[11:00] <ubitux> and it's a bit faster
[11:11] <cone-897> ffmpeg.git 03Clément BSsch 07master:669d4f9053f9: x86/vp9lpf: simplify 2nd transpose in 44/48/88/84.
[11:21] <cone-897> ffmpeg.git 03Ronald S. Bultje 07master:bbc3425fa25e: vp9: fix mix-up of last-frame/cur-frame in frame size checks.
[11:27] <ubitux> BBB: uploaded fuzzed8.ivf for you
[11:27] <ubitux> BBB: probably a problem in the parser
[11:33] <ubitux> BBB: also uploaded fuzzed9.ivf, which is thread relevant
[12:08] <cone-897> ffmpeg.git 03Carl Eugen Hoyos 07master:4bcc6febcff2: Fix compilation with --disable-everything --enable-encoder=flac.
[12:42] <cone-897> ffmpeg.git 03Lukasz Marek 07master:18c3313e65f7: lavd/sdl: make waiting spurious wakeup aware
[12:42] <cone-897> ffmpeg.git 03Lukasz Marek 07master:20fe316e47fe: lavd/sdl: reset context variables after destroy
[12:42] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:1e263133cc06: avcodec/hevc: remove unused variables
[12:42] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:3b6655ebff7c: avcodec/hevc: remove FFUMOD() in slice qp_y init
[12:51] <BBB> ubitux: fuzzed8.ivf fixed (crap :) )
[12:57] <cone-897> ffmpeg.git 03Ronald S. Bultje 07master:c72f587353d9: vp9/parser: change size type to unsigned.
[13:06] <ubitux> BBB: thx :)
[13:06] <ubitux> BBB: able to reproduce the 2nd one?
[13:18] <BBB> yes, I think I know what causes it
[13:18] <BBB> will have a fix in a bit, not a hard one
[13:23] <BBB> maybe you can fix it
[13:23] <BBB> I have to run for a bit
[13:24] <BBB> the issue is that we allocate b_base and eob_base in update_size but they depend on parallelmode/refreshctx also
[13:24] <BBB> so if we allocate them small but then they change to "need_big_now", we should re-allocate them anyway
[13:24] <BBB> I'll do it in a few hours, but have to run now
[13:27] <ubitux> i'm busy :(
[13:39] <kurosu_> is there a specifier or whatever to declare that a variabe that looks to be used unitialized, isn't (or rather, that we don't care) ?
[13:54] <BBB> kurosu_: AV_UNUSED I believe
[13:54] <BBB> oh av_unused
[13:54] <BBB> oh wait I'm confused ignore me
[13:55] <BBB> sorry
[13:56] <kurosu_> trying to write intrinsics, this starts to get awful, but there are probably cleaner solution I don't yet know
[13:56] <kurosu_> union { const int8_t* p; const __m128i *p16; } val = { .p = src };
[13:56] <kurosu_> will that break msvc, btw ?
[13:57] <BBB> no
[13:57] <BBB> msvc is fine nowadays
[13:58] <j-b> *almost* fine
[13:58] <kurosu_> anyway, I can probably write val = { src };
[13:59] <j-b> kurosu_: the above will work
[14:24] <BBB> ubitux: fixed fuzzed9.ivf
[14:25] <BBB> kurosu_: omg why on earth would you write intrinsics :-p
[14:26] <ubitux> kurosu_: av_uninit
[14:33] <BtbN> can i just use the input pts as output dts and pts, if i re-order them correctly for the pts? Or are the input frames in an encoder not sorted by pts?
[14:34] <nevcairiel> usually an encoder has the ability to give you timestamps, especially in a complex format like h264
[14:34] <BtbN> not nvenc
[14:35] <BtbN> all it does is ordering the input timestamps
[14:35] <BtbN> so stuff like B-Frames get a correct timestamp
[14:37] <BtbN> but it doesn't output a ready to use pts/dts. Only exactly one timestamp per frame
[14:50] <BBB> BtbN: it gives you pts; let's assume input pts is always incrementing in order A, B, C, D, E (where B >= A, C >= B, D >= C, E >= D)
[14:50] <BBB> BtbN: then the output pts is N1, N2, and you haven't received N3 yet, but you're wondering what the dts is
[14:50] <BBB> BtbN: each Nx needs to be one of A, B, C, D, E and can only occur once
[14:50] <BBB> BtbN: so keep an input rolling array of "given timestamps" and remove the ones recovered back
[14:51] <kurosu_> BBB: because my recent inline asm can't benefit msvc & co
[14:51] <BBB> BtbN: then the output dts is min(pts, rolling_array[@])
[14:51] <BBB> kurosu_: oh; just don't write inline asm :-p
[14:51] <kurosu_> and I suspect that gcc constrains are nowhere near enough
[14:51] <BtbN> the output pts isn't the problem, that's handled by nvenc. It's the output dts. The question was more like if it's a problem if i use the same time values for dts and pts, so that some frames might have identical dts and pts
[14:52] <kurosu_> BBB: well, someone did, I haven't checked how relevant it was but the function call is non-negligible
[14:52] <BBB> BtbN: so if N1 is A and N2 is D, then rolling_array[] = {B,C,D,E} and min(rolling_array[@]) is B, thus min(N2,min(rolling_array[@])) is B, thus dts=B and pts=N2=D
[14:52] <nevcairiel> its normal for some frames to h ave pts=dts, but dts needs to be monotonically increasing, while pts does not (on an encoded bitstream)
[14:52] <BBB> oh you get dts not pts? how annoying
[14:53] <BtbN> no, i get whatever i input, it does not process it in any way, it just re-orders it, when it does re-ordering for b-frames
[14:53] <nevcairiel> then you get pts
[14:53] <BBB> in a simple non-pyramid B scheme you can calculate pts still
[14:53] <BBB> in a pyramid scheme I don't think you can
[14:53] <nevcairiel> if it does re-ordering for you, then the result is pts
[14:53] <BBB> BtbN: yeah reordering means you get pts; dts can be calculated like I said
[14:53] <BtbN> yes, the result is pts. Did i write dts?
[14:54] <BBB> BtbN: then what I wrote works to calculate dts from pts; enjoy!
[14:55] <BtbN> the way nvenc works makes that rather easy
[15:01] <BtbN> hm, some kind of dynamic list would be usefull for this. Or i just mark empty array spots as invalid somehow
[15:14] <ubitux> BBB: the patch doesn't apply
[15:15] <BBB> oh
[15:15] <BBB> well my tree changed a bit
[15:15] <BBB> maybe we should merge more of my tree, let me rebase though on top of master first
[15:25] <BBB> odd
[15:25] <BBB> a straight cherrypick works fine here
[15:25] <BBB> on origin/master
[15:26] <BBB> ubitux: what's the apply error?
[15:27] <ubitux> error: patch failed: libavcodec/vp9.c:348
[15:28] <ubitux> git am doesn't generate a conflict diff& so i don't know much, i should look
[15:30] <BBB> I'll work on cleaning up my context-opts branch a bit so we can merge that, that would decrease my local changes quite a bit
[15:30] <BBB> let me know if you need me to re-send this patch
[15:33] <kurosu_> for anybody's information, the best I could come up using intrinsics for a recent dcadsp inline function is something generating 3 extra moves and is 1 cycle slower
[15:34] <kurosu_> http://pastebin.com/aeTycSAz
[15:36] <BBB> kurosu_: does the function _have_ to be inlined?
[15:37] <kurosu_> well there's already yasm versions, but the cycle count is 23-27 depending on the processor, and the call generates 3-7 more cycles
[15:38] <kurosu_> there's a gain, but the call causes a non-negligible loss here
[15:38] <BBB> hm right
[15:40] <BBB> why is this code block in that calling loop?
[15:40] <BBB>             if (!s->debug_flag & 0x01) {
[15:40] <BBB>                 av_log(s->avctx, AV_LOG_DEBUG,
[15:40] <BBB>                        "Stream with high frequencies VQ coding\n");
[15:40] <BBB>                 s->debug_flag |= 0x01;
[15:40] <BBB>             }
[15:40] <BBB> also there's a bracket missing
[15:40] <BBB> like if (!(.. & ..)) instead of if (!.. & ..)
[15:41] <BBB> can't you put the whole loop in assembly?
[15:41] <kurosu_> that's a predictable jump, I don't think it really matters
[15:41] <kurosu_> http://pastebin.com/6yDnyyG3 <- the generated sequence
[15:41] <kurosu_> oh
[15:42] <kurosu_> I had never checked that before
[15:42] <BBB> why not put the whole loop in assembly?
[15:42] <BBB> then you don't need all this pain
[15:43] <BBB> and I still think the if statement is missing brackets (not knowing anything about dca, but I can read C and that looks awfully weird)
[15:43] <kurosu_> on the other hand, hfvq = s->high_freq_vq[k][l] makes it unlikely there's much sequentiality in the look up, so the inner loop will be small
[15:44] <kurosu_> you're right, this code has nothing to do here
[15:44] <kurosu_> I didn't see the loop ended so soon
[15:44] <BBB> well you have to load one register with various (possible far-away) values for hfvq, yes
[15:44] <BBB> but the rest is all l-incremental and could thus benefit from doing multiple at a time
[15:49] <kurosu_> http://pastebin.com/q6SfVQGj <- that + dspize then
[15:49] <kurosu_> need to go bye
[15:51] <BBB> yeah (seeyou!)
[16:48] <Daemon404> i think that with the amount of time trac has been down
[16:48] <Daemon404> we really should have put a placeholder page...
[16:48] <j-b> what is the issue?
[16:48] <Daemon404> trac has been down for 3-4 days
[16:48] <j-b> why?
[16:48] <Daemon404> times out; its down for maitenenece
[16:48] <Daemon404> or something
[16:49] <j-b> I guessed so, but why is it not up again?
[16:50] <Daemon404> still down for maintenence?
[16:50] <Daemon404> i dont know.
[16:50] <Daemon404> i dont think timing out for days on end is good for users
[16:50] <beastd> Daemon404: you should see a maintenance page
[16:51] <Daemon404> oh indeed its 503 now
[16:51] <Daemon404> but 503 tends to just mean broken to me
[16:51] <Daemon404> since in teh good old 1990s 503 really mean their perl cgi fucked up
[16:51] <Daemon404> :D
[16:51] <beastd> :)
[16:52] <Daemon404> only thing worse was 500
[16:53] <beastd> got to go now. see you tomorrow
[16:54] <Daemon404> bye
[17:07] <cone-897> ffmpeg.git 03Janne Grunau 07master:0cffd6fff59f: x86: use the inline int8x8_fmul_int32 only if inline SSE2 is availbale
[17:07] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:dd2b33034777: Merge commit '0cffd6fff59f192120dc93aa6c3cb8180f5506e3'
[17:14] <cone-897> ffmpeg.git 03Vittorio Giovara 07master:b141c7b37eb5: h264: give numbers to nalus
[17:14] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:4df9d9ca4f5a: Merge commit 'b141c7b37eb52aca41ac83738f159b63b9c09d5c'
[17:30] <ubitux> BBB: if you want the patch to be applied before merging your branch, i can cherry-pick from your branch
[17:30] <ubitux> BBB: do you want to do something in particular before the merge?
[17:31] <cone-897> ffmpeg.git 03Janne Grunau 07master:5c1c6e82261b: dca: include dcadsp.h in {arm,x86}/dca.h for checkheaders
[17:31] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:df98b36aa63c: Merge commit '5c1c6e82261b856214499b9fef3a08bf3ff6e0ae'
[17:47] <J_Darnley> cbsrobot
[17:48] <J_Darnley> Oops sorry.  <rant>damn tiny backspace key!</rant>
[18:17] <BBB> ubitux: just reword some commit msgs
[18:18] <BBB> ubitux: but this one can be merged before it, it applies cleanly here, want a new pastebin of it on top of origin/master?
[18:19] <ubitux> BBB: i can cherry-pick it from the branch, that's probably simpler
[18:19] <ubitux> if you pushed it somewhere
[18:20] <cone-897> ffmpeg.git 03Tim Walker 07master:c0c45188e56c: mlp: improve request_channel_layout behavior.
[18:20] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:aedc10137de0: Merge commit 'c0c45188e56cfa3050bb39f8299025345b8a204c'
[18:20] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:1a8050ad616c: avcodec/mlpdec: fix mulichannel output
[18:20] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:bd35d58463f0: avcodec/mlp_parser: fix multichannel
[18:20] <BBB> ubitux: no not yet :-p
[18:22] <BBB> ubitux: https://github.com/rbultje/ffmpeg/commits/vp9-context-opts
[18:22] <BBB> ubitux: first commit on top of the main tree
[18:23] <BBB> ubitux: and maybe the next one should be merged also, it aligns buffers a little better so big buffers are actually 16-byte aligned
[18:25] <ubitux> ok
[18:30] <cone-897> ffmpeg.git 03Ronald S. Bultje 07master:af63ea7078c8: vp9: re-allocate block buffers on uses_2pass change w/o size change.
[18:30] <cone-897> ffmpeg.git 03Ronald S. Bultje 07master:7f0f47b3df9d: vp9: some variable re-arrangements for alignment.
[18:30] <ubitux> BBB: tested and applied, thanks
[18:30] <BBB> ty
[18:30] <ubitux> BBB: also uploaded fuzzed10.ivf for you :)
[18:31] <BBB> argh
[18:31] <BBB> that bad?
[18:31] <BBB> when does it get safer?
[18:31] <ubitux> :)
[18:31] <ubitux> it's an invalid read, with threading
[18:32] <BBB> how long do you fuzz before you get anything?
[18:32] <BBB> like millions per second, or a few seconds per one, or a few hours per one?
[18:32] <ubitux> about 1 min
[18:32] <BBB> :(
[18:32] <ubitux> often less :p
[18:33] <BBB> I was really expecting it to be harder by now
[18:40] <ubitux> most of them are related to threading
[18:41] <ubitux> that doesn't encourage me to do some mt work :D
[18:47] <BBB> seems like we're not allocating a buffer correctly or so?
[18:47] <ubitux> no idea :)
[19:01] <cone-897> ffmpeg.git 03Tim Walker 07master:76a75c523cd3: lavr: mix front center channel as indicated in the ATSC A/52 specification.
[19:01] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:b08f554fdc08: Merge commit '76a75c523cd3c63560185394a0a5cd7249db962a'
[20:03] <cone-897> ffmpeg.git 03Kostya Shishkov 07master:cde7df25ef74: Mirillis FIC video decoder
[20:03] <cone-897> ffmpeg.git 03Michael Niedermayer 07master:0c4bf87b2961: Merge remote-tracking branch 'qatar/master'
[21:31] <ubitux> saste: most of what is said about the lavfi tasks look outdated
[21:31] <saste> oh i was on the wrong channel
[21:31] <ubitux> but there is definitely stuff to do in lavfi& 
[21:32] <ubitux> saste: you don't want to mentor at all, or you don't want to mentor on lavfi?
[21:32] <saste> so the question boils down to: who will mentor?
[21:32] <saste> i don't want to mentor at all
[21:32] <saste> i won't have time
[21:32] <ubitux> ok
[21:32] <saste> and i prefer working on ffmpeg myself if i'll have time
[21:32] <saste> i'm not a gsoc enthusiast
[21:33] <ubitux> i'm not either ;)
[21:33] <ubitux> most of the stuff is about api though
[21:33] <saste> ubitux, what filters do you think we are still missing?
[21:34] <ubitux> slowmo
[21:34] <ubitux> a useful denoiser
[21:34] <ubitux> and speed improvements
[21:35] <saste> i can act as backup mentor, but i won't be the main mentor
[21:35] <ubitux> is what come to my mind with 1m of thinking
[21:35] <wm4> port useful avisynth filters to lavfi
[21:36] <saste> wm4: you going to mentor?
[21:36] <wm4> probably not
[21:36] <wm4> at least not for this topic
[21:36] <saste> ubitux, so most likely, i'll kill the entry and that's all
[21:36] <wm4> but it'd provide an endless source of work to do
[21:37] <ubitux> saste: i think you can replace it with a slowmo filter :P
[21:37] <BBB> omg something is asking hm questions on the ml
[21:38] <saste> BBB: hm?
[21:48] <BBB> hevc reference encoder
[21:49] <BBB> ubitux: fixed
[21:49] <BBB> that was mildly screwy, admittedly
[21:50] <ubitux> BBB: appliable on master?
[21:50] <ubitux> ('have it in your branch?)
[21:50] <BBB> see ml
[21:50] <BBB> I'll push, sec
[21:51] <BBB> vp9-context-opts first patch
[21:51] <BBB> now can that fuzz of yours please run for longer than a minute without giving me new warnings? this is very depressing
[21:52] <BBB> it's like every line of code I write is screwy
[21:52] <llogan> ubitux: like this? http://slowmovideo.granjow.net/index.html
[21:52] <ubitux> llogan: yes :)
[21:52] <llogan> i played with it a few days ago. was kind of fun.
[21:52] <ubitux> we'll see ;)
[21:53] <ubitux> BBB: and btw, those were with only sample we aren't even supposed to be able to decode :x
[21:54] <ubitux> (the last 4 or so are based on the size change one)
[21:58] <BBB> well, it's supposed to decode fine, just reconstruction is not fine, right?
[21:58] <BBB> t
[21:58] <BBB> we shouldn't show any cmdline errors about decoding failures; bitstream parsing should be fine
[21:58] <BBB> (untested)
[22:00] <ubitux> ok
[22:00] <ubitux> anyway, let's start a new fuzzing session.
[22:01] <BBB> ok
[22:01] <ubitux> BBB: seems it last at least 1m this time ;)
[22:01] <BBB> I'm still mildly concerned
[22:04] <ubitux> it seems you'll have a bit more delay for the next one :)
[22:04] <BBB> \o/
[22:04] <BBB> safety at last
[22:04] <nevcairiel> now you jinxed it
[22:04] <BBB> can you apply the previous one while you're at it?
[22:05] <ubitux> you mean the fuzz10 fix?
[22:05] <BBB> yeah
[22:05] <ubitux> sure, i have it applied here while fuzzing
[22:06] <BBB> ok
[22:08] <cone-897> ffmpeg.git 03Ronald S. Bultje 07master:0c67864a37a5: vp9: don't allow retaining old segmentation maps after a size change.
[22:09] <ubitux> BBB: you passed about 100k fuzzed tests
[22:09] <ubitux> gonna try some random other source and parameters
[22:12] <BBB> not bad
[22:52] <BBB> ubitux: how far?
[22:52] <ubitux> still fine
[22:53] <ubitux> i got one crash but i'm not actually able to reproduce with the sample
[22:53] <ubitux> it's allocating a lot of memory so that might be a false positive
[22:55] <ubitux> i only get a ==1568== Warning: set address range perms: large range [0x13183080, 0x23b5649f) (undefined)
[22:55] <ubitux> with valgrind
[23:06] <BBB> ok new patches sent
[23:06] <BBB> those are my last ones
[23:06] <BBB> I have a local patch for intra pred simd which is half-done (I should really split it in 2 since some of it affects the c code also which should probably be separate)
[23:06] <BBB> but it's not yet finished so I'll do that later
[23:07] <BBB> after that I don't think I have any more big plans
[23:35] <g3gg0> @michaelni: you there?
[23:35] <michaelni> g3gg0, yes
[23:36] <g3gg0> hi there. i amcontacting you regarding your SoC task "RGB Colorspace"
[23:36] <g3gg0> Bayer RGB of course :)
[23:37] <g3gg0> i am a developer in the Magic Lantern project, a widely used firmware addon to canon DSLRs and we recently introduced a video container for canon raw video
[23:38] <michaelni> interresting
[23:39] <g3gg0> maybe thats a good starting point for you to directly read raw video files
[23:39] <g3gg0> the thread about the video plugin for cameras: http://www.magiclantern.fm/forum/index.php?topic=7122.0
[23:39] <michaelni> hmm, indeed, you should mail pross about this
[23:40] <g3gg0> the file format explanation: https://docs.google.com/spreadsheet/ccc?key=0AgQ2MOkAZTFHdHJraTVTOEpmNEIwTVlKd0dHVi1ULUE#gid=0
[23:40] <g3gg0> ok
[23:40] <michaelni> also dont hesitate to put me in CC if you like
[23:41] <g3gg0> sure
[23:41] <g3gg0> from your name i guess you are german, right?
[23:41] <g3gg0> same for pross`
[23:41] <g3gg0> ?
[23:41] Action: michaelni is from austria
[23:42] <BtbN> yay, the nvenc encoder is finished, now i have to find out if it works.
[23:42] <g3gg0> ok
[23:43] <michaelni> g3gg0, iam not sure peter speaks german
[23:46] <Compn> yes i think ffmpeg needs more camera raw support, maybe steal from dcraw project :)
[23:46] <Compn> pross knows about bayer :)
[23:49] <g3gg0> yeah, but also in dcraw there are some inaccuracies iirc
[23:49] <Compn> we all have bugs :)
[23:49] <g3gg0> definitely
[23:50] <g3gg0> about debayering, dcraw does quite a good job.
[23:50] <g3gg0> thats a domain on its own
[23:51] <g3gg0> i just asked because we have our own raw video file format that could be a superb demonstration workflow
[23:52] <g3gg0> .mlv --> ffmpeg --> .mpeg
[23:53] <Compn> sounds good, i didnt mean to bring up dcraw, its just on a very long todo list to be able to read all of those camera files :)
[23:53] <Compn> if your raw file de/muxer is easily added to ffmpeg, that would be nice
[23:54] <g3gg0> yeah. should be fairly simple
[00:00] --- Sun Feb  9 2014