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

[burek]

[00:09:43 CET] <durandal_1707> hmm looks like framepool issue
[00:13:40 CET] <jkqxz> Timothy_Gu:  Unclear.
[00:15:09 CET] <jkqxz> Pretty much all of what I've written is required there too, it would just gain the extra layer on top to fit into that framework.
[00:15:45 CET] <rcombs> seems it'll make the filtering stuff a little simpler, at least
[00:18:07 CET] <ubitux> > We're experiencing an issue where ffmpeg seg faults for very large "-filter_complex_script" input files (roughly 3MB).
[00:18:11 CET] <ubitux> meh
[00:18:22 CET] <durandal_1707> so how should I name filter that reads each line of file as new filtergraph?
[00:18:54 CET] <durandal_1707> ubitux: you are evil, responsible for enable hack
[00:19:43 CET] <ubitux> enable \o/
[00:19:46 CET] <ubitux> anyway, afk
[00:25:11 CET] <jkqxz> Should I be expecting that libav patch to land any time soon?  The discussion on the libav-devel list looked rather ambivalent.
[00:29:59 CET] <wm4> not sure
[00:54:10 CET] <Timothy_Gu> bob weaver lol
[01:01:05 CET] <kierank> atomnuker: a ptrdiff change isn't worth a v3
[01:01:58 CET] <atomnuker> kierank: I _know_
[01:02:28 CET] <atomnuker> but stuff gets buried in the ML so quickly
[01:02:59 CET] <kierank> just push it
[01:03:04 CET] <kierank> clearly nobody's going to review it
[01:04:23 CET] <atomnuker> it's a huge feature, comparitively, and I'm personally not okay with merging it until at least someone say it's okay (a small 'but' is acceptable)
[01:04:31 CET] <kierank> it's not a huge feature
[01:04:48 CET] <atomnuker> it is compared to say, a random bugfix somewhere
[01:55:43 CET] <cone-761> ffmpeg 03Michael Niedermayer 07master:05924e1440fd: avfilter/af_anequalizer: Fix memleak of args
[02:13:18 CET] <Timothy_Gu> ubitux: your x86_64-archlinux-gcc-tsan fate station is broken
[02:13:39 CET] <Timothy_Gu> "ccache cc is unable to create an executable file."
[02:14:16 CET] <Timothy_Gu> seems like its been broken since 2015-12-06: http://fatebeta.ffmpeg.org/history/x86_64-archlinux-gcc-tsan?begin=150
[02:18:26 CET] <jamrial> why is it not showing in the index?
[02:20:07 CET] <Timothy_Gu> because it's too broken
[02:21:02 CET] <Timothy_Gu> jamrial: i.e. not even arch and config information is recorded to the fate record before the configure failed
[02:21:15 CET] <Timothy_Gu> old fate behaves the same way
[06:06:14 CET] <Timothy_Gu> solution: use lua!!!
[06:15:43 CET] <Compn> json everywhere
[06:54:44 CET] <satinder> Hi , When I am compiling dranger tutorial 1 , I got an error : ‘PIX_FMT_RGB24’ undeclared
[06:54:57 CET] <satinder> anyopen can please help me 
[06:55:00 CET] <satinder> thanks 
[08:10:43 CET] <wm4> satinder: you got an ancient version of it
[08:16:52 CET] <satinder> wm4 : what is ancient version ??
[08:17:01 CET] <satinder> I don't know about that 
[08:17:05 CET] <satinder> please help 
[08:34:12 CET] <ubitux> Timothy_Gu: it's having this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67308
[08:34:17 CET] <ubitux> apparently.
[09:03:36 CET] <Timothy_Gu> ubitux: that's one nasty bug&
[09:04:13 CET] <Timothy_Gu> satinder: what "ancient" means is that the tutorial is written for a very old version of FFmpeg and does not work anymore
[09:10:33 CET] <satinder> ok
[09:11:03 CET] <satinder> Timothy_Gu : Can you help me how I can capture a rtsp stream 
[09:11:09 CET] <satinder> with ffmpeg api
[09:11:46 CET] <durandal_1707> Timothy_Gu: what bug?
[09:37:45 CET] <Timothy_Gu> durandal_1707: 23:34 <@ubitux> Timothy_Gu: it's having this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67308
[10:08:00 CET] <Timothy_Gu> is there an easy way to divide each word by 255 in SSE2?
[10:11:47 CET] <rcombs> you'd need to convert that into adds, multiplies, and shifts
[10:11:52 CET] <nevcairiel> sse2 doesnt have integer divison, so you could try to emulate it by using a "fast div255" hack, but that only works if you can guarantee a limited value range or use 32-bit intermediates
[10:14:18 CET] <nevcairiel> in general, x*257>>16, or (x+1+((x+1)>>8))>>8
[10:14:37 CET] <nevcairiel> first should be (x+1)*257
[10:15:47 CET] <rcombs> (x + 255) >> 8 may be suitable for your application
[14:00:28 CET] <BtbN> looks like someone has connection issues
[14:01:03 CET] <nevcairiel> its been quiet for over 10 minutes now, lets hope it stopped =p
[14:34:43 CET] <durandal_1707> any more comments for metadata filter?
[14:53:51 CET] <durandal_1707> who is responsible for ffmpeg youtube channel?
[14:54:37 CET] <BtbN> There is a ffmpeg youtube channel? An official one?
[14:55:24 CET] <Daemon404> ... why on earth would we need one
[14:56:02 CET] <nevcairiel> show off all the fancy avfilter effects
[14:56:03 CET] <BtbN> demos of filter effects or something, no idea. But i never heard of one
[14:57:15 CET] <wm4> "ffmpeg youtube channel" lol what
[15:03:48 CET] <Loriker> ..under which url is it?
[15:34:21 CET] <durandal_1707> Loriker: https://www.youtube.com/channel/UCSJ7ur8rS4Mg_72S0ZmIDaA
[15:36:45 CET] <Daemon404> g 42
[15:40:58 CET] <atomnuker> why does it only have fishes?
[15:41:36 CET] <RiCON> fishes aren't copyrighted?
[15:42:25 CET] <durandal_1707> it doesnt use hstack/vstack :(
[15:43:59 CET] <RiCON> pip example uses libvo_aacenc
[15:50:52 CET] <cone-484> ffmpeg 03Paul B Mahol 07master:35d9441f7b96: avfilter/vf_swaprect: add timeline support
[15:58:21 CET] <cone-484> ffmpeg 03Michael Niedermayer 07master:a25c5dbb5ee0: ffmpeg_opt: Fix memleaks in "manually set programs" loop
[15:58:29 CET] <roxlu> hey! Someone around who knows about mpeg-ts? I'm wondering what the logic behind calculating the PTS / PCR values is when muxing different streams ? (e.g. combining 4 ts streams)
[16:01:23 CET] <BtbN> voodoo magic.
[16:02:18 CET] <roxlu> Lol so it seems :) 
[16:02:26 CET] <roxlu> nah, the code is quite clear I think. 
[16:02:41 CET] <roxlu> I just don't know where to look yet
[16:03:45 CET] <roxlu> When I look at line 1222 here https://www.ffmpeg.org/doxygen/2.5/mpegtsenc_8c_source.html  it seems that the PTS/DTS from the source packets is simply used and increased with a "delay" offset
[16:04:46 CET] <roxlu> I'm only now sure what max_delay means here
[16:37:20 CET] <Timothy_Gu> nevcairiel, rcombs: thanks
[16:44:27 CET] <BBB> nevcairiel: ping
[17:00:06 CET] <BBB> nevcairiel: pokey poke
[17:00:22 CET] <durandal_1707> ping me
[17:01:31 CET] <BBB> durandal_1707: ping
[17:02:55 CET] <BBB> nevcairiel: so, explain to me how the fallback between hw and sw decoding works in vp9 (or maybe in general), because I dont get it
[17:03:16 CET] <BBB> nevcairiel: my understanding was that per-frame, wed call hwaccel->start_frame(), and it returns whether it supports this frame type or not
[17:03:28 CET] <durandal_1707> nice gsoc/outreachy project is writing A & V filter source to test multichannel setups
[17:03:45 CET] <BBB> nevcairiel: but there is no fallback between start_frame fail and sw dec fallback, at least none that I can see in vp9 on a per-frame (adaptive) basis
[17:04:02 CET] <wm4> durandal_1707: why would something like this be hardcoded
[17:04:56 CET] <durandal_1707> wm4: its hardcoded as video i have from dolby, and even files you generated are hardcoded
[17:05:26 CET] <wm4> yes but I generated them with a fancy filter graph... so why hardcode such a source
[17:06:11 CET] <durandal_1707> so it can be used by average joe, no need for fancy graphs
[17:07:16 CET] <wm4> average joe can you preproduced test files
[17:07:22 CET] <wm4> s/you/use/
[17:08:19 CET] <nevcairiel> BBB: thats not how it works, every time the frame format changes the decoder is supposed to call ff_get_format (or the thread variant with a similar name), which will then internally enable or disable hwaccel
[17:08:44 CET] <BBB> how?
[17:08:44 CET] <wm4> durandal_1707: that said, mechanisms to make it _easier_ to write such graphs would be good
[17:08:50 CET] <BBB> how do I know its enabled or disabled
[17:09:11 CET] <wm4> durandal_1707: for example, intuitively I'd just want to concatenate multiple sources (each playing for a while), for both video and audio
[17:09:16 CET] <nevcairiel> BBB: if avctx->hwaccel is set
[17:09:25 CET] <BBB> but what sets it?
[17:09:31 CET] <nevcairiel> ff_get_format
[17:09:40 CET] <BBB> aahhhaa
[17:09:45 CET] <BBB> ok Im learning so much here
[17:09:46 CET] <BBB> ty
[17:09:57 CET] <wm4> durandal_1707: in my script I had to do this very awkwardly by creating multiple temp files and concatenating them
[17:10:00 CET] <iive> if the returned format is hwaccelerated, you've gotten acceleration.
[17:10:11 CET] <durandal_1707> ubitux: hom much fast is enable approach for 3mb scripts
[17:10:34 CET] <ubitux> it's dumb and slow, but it shouldn't crash
[17:11:20 CET] <durandal_1707> it segv here too, i dont hat backtrace, just last line where it happens
[17:11:29 CET] <durandal_1707> s/hat/have
[17:12:39 CET] <durandal_1707> ubitux: edit file and duplicate all lines, repeat until crash happens
[17:14:17 CET] <durandal_1707> wm4: iirc there is script you used...
[17:14:31 CET] <Daemon404> s
[17:22:03 CET] <ubitux> durandal_1707: and where does it happen?
[17:25:51 CET] <durandal_1707> ubitux: i haven't saved output, sorry
[17:33:11 CET] <durandal_1707> wm4: what was not possible to do? you can call several aevalsrc,fade in and out them and after that amerge them
[17:44:42 CET] <j-b> Is Kyle around?
[17:46:14 CET] <kierank> seems not
[17:47:09 CET] <durandal_1707> j-b: you need something?
[17:49:48 CET] <j-b> durandal_1707: porn :)
[17:49:51 CET] <j-b> kierank: :)
[17:50:10 CET] <j-b> kierank: since you are now an expert, can you explain to me American Football?
[17:50:26 CET] <kierank> I don't watch the sport, I watch the picture
[17:50:52 CET] <kierank> the w9 feed came from moi last night
[17:57:04 CET] <durandal_1707> j-b: I'm watching you 0-0
[18:36:15 CET] <durandal_1707> wm4: ./ffmpeg -f lavfi -i anoisesrc=c=pink -lavfi [0:a]afade,afade=out:d=1:st=5[a],[0:a]afade=in:st=6,afade=out:st=11[b],[a][b]amerge
[19:05:43 CET] <BBB> nevcairiel: it would be useful, I believe, if there was a dummy hwaccel impl for relevant codecs that provides a sw implementation (possibly by looping back to the decoder itself) for hwaccel infrastructure testing
[19:05:47 CET] <BBB> nevcairiel: does that make sense?
[19:07:33 CET] <nevcairiel> sure,  but it would likely be very complex
[19:08:03 CET] <nevcairiel> for vp9 it would actually be the easiest since the hwaccel gets access to the entire bitstream
[19:08:08 CET] <nevcairiel> for h264 however, the hwaccel only gets slices
[19:08:16 CET] <nevcairiel> so you need to rebuild the entire state of the decoder from metadata
[19:09:52 CET] <BBB> hm&
[19:10:00 CET] <BBB> I guess vp9 only should be ok for my purposes
[19:10:10 CET] <BBB> testing hwaccel right now is kind of tricky for me
[19:10:56 CET] <BtbN> Doesn't ffmpeg have a root server from Hetzner somewhere? Those usualy have a vaapi capable GPU.
[19:15:31 CET] <Timothy_Gu> BtbN: yeah that's ffmpeg.org
[19:15:45 CET] <Timothy_Gu> not really good to do testing on there i suppose
[19:25:17 CET] <BBB> nevcairiel: can you test patches for me on your system?
[19:25:36 CET] <BBB> like, testing being see if allowing hwaccel+vp9+mt does not fail
[19:25:49 CET] <BBB> (assuming it currently sometimes does fail)
[19:25:56 CET] <durandal_1707> anyone needs new machine?
[19:25:57 CET] <nevcairiel> right now it massively fails
[19:26:23 CET] <nevcairiel> but i can test
[19:27:34 CET] <BBB> nevcairiel: http://pastebin.com/DfMGhrmb
[19:27:54 CET] <BBB> nevcairiel: if my understanding of everything is correct (highly doubtful), this should fix the fails
[19:28:23 CET] <nevcairiel> will this not just end in nothing ever getting executed
[19:28:34 CET] <BBB> nevcairiel: and then all related work to remove the disabling of mt if hwaccel is enabled or whatever (or vice versa, I dont know what the state of that is)
[19:29:39 CET] <nevcairiel> besides there are already hacks in place to simply skip calling finish_setup when hwaccel is enabled .. not for vp9 mind you because that didnt solve its problems
[19:29:41 CET] <BBB> nevcairiel: I think it should execute just fine, but it will do so entirely serially
[19:30:03 CET] <BBB> nevcairiel: it basically forces hwaccel to follow the single threaded codepath for everything
[19:30:20 CET] <BBB> I can explain further but you might not want to know
[19:31:10 CET] <nevcairiel> thats not vp9s problem though, i tried something like this
[19:31:30 CET] <nevcairiel> like I said, other codecs simply have a if (!hwaccel) branch before calling ff_thread_finish_setup to achieve the same goal
[19:31:49 CET] <BBB> I really want hw so I can test this normally
[19:32:02 CET] <nevcairiel> when you do this, you still have worker threads
[19:32:06 CET] <BBB> yes
[19:32:10 CET] <nevcairiel> and the way vp9 is written it inits every worker thread separately
[19:32:13 CET] <BBB> but they are synced in update_thread_context
[19:32:19 CET] <nevcairiel> not entirely, no
[19:32:29 CET] <nevcairiel> some of their data is updated independently
[19:32:29 CET] <BBB> what do you mean not entirely?
[19:32:54 CET] <BBB> wihch part would you like to be synced?
[19:32:56 CET] <nevcairiel> update_size allocates data when a worker thread runs for the first time
[19:33:06 CET] <BBB> yes
[19:33:24 CET] <nevcairiel> and similarly, update_size calls ff_thread_get_format again on every worker thread
[19:33:26 CET] <BBB> in the ff_get_format call?
[19:33:35 CET] <nevcairiel> potentially resetting the hwaccel on every thread
[19:33:39 CET] <nevcairiel> causing lots of problems
[19:34:06 CET] <BBB> so why dont other hwaccels dont have that issue?
[19:34:14 CET] <nevcairiel> because their init is smarter
[19:34:19 CET] <nevcairiel> they dont do that =p
[19:34:21 CET] <BBB> can we make vp9s init smarter?
[19:34:26 CET] <nevcairiel> probably
[19:34:36 CET] <nevcairiel> but i didnt bother because hwaccel-mt has zero advantages
[19:35:32 CET] <wm4> shouldn't it be pretty simple to feed only 1 worker thread with work and leave the others idle?
[19:36:22 CET] <nevcairiel> anyway the ff_thread_finish_setup thing isnt even called by vp9 in hwaccel mode, i made it skip all that :D
[19:36:42 CET] <BBB> hm...
[19:36:43 CET] <BBB> ok
[19:36:43 CET] <BBB> so
[19:36:56 CET] <BBB> wm4: its a lot of code that Id like to avoid
[19:37:06 CET] <BBB> wm4: Im thinking of shared codepaths being simpler to maintain, this code is already fairly hairy
[19:37:15 CET] <nevcairiel> the thing is, just fixing vp9  hwaccel to work in mt mode doesnt fix any of the underlying key problems
[19:37:19 CET] <BBB> nevcairiel: I dont see vdpau doing anything complex
[19:38:17 CET] <nevcairiel> i have no idea what vdpau has to do with anything we're talking about
[19:38:49 CET] <BBB> youre saying their init does complicated things to not init double
[19:38:58 CET] <BBB> or do you mean the decoder itself instead of the hwaccel?
[19:39:17 CET] <nevcairiel> the decoder
[19:39:38 CET] <nevcairiel> for codecs like h264 it really falls back to how the codec works itself
[19:39:48 CET] <nevcairiel> it inits this stuff when it loads a particular sps
[19:39:54 CET] <nevcairiel> and it only does that once, not on every thread
[19:40:05 CET] <BBB> so heres what I dont get then - we sync hwaccel and hwaccel_context between each thread
[19:40:15 CET] <BBB> so why does the second threads hwaccel thing its uninitialized?
[19:40:35 CET] <nevcairiel> because ff_thread_get_format is called again which destroys and re-creates it
[19:40:53 CET] <nevcairiel> one shall not call that function too often, only when things really change
[19:42:03 CET] <nevcairiel> but vp9 also uses the "things changed!" function to init its stuff
[19:42:14 CET] <BBB> so& you want me to split vp9.cs internal buffer allocation in two things: allocate buffers, and signal actual size change
[19:42:18 CET] <BBB> thats not hard at all
[19:42:22 CET] <BBB> right?
[19:42:44 CET] <nevcairiel> that would probably help
[19:42:52 CET] <nevcairiel> i never got past that problem, so no clue if it fixes all of it
[19:45:02 CET] <BBB> I dont need to call it on size change, right?
[19:45:08 CET] <BBB> (since vp9 supports scalable)
[19:45:11 CET] <nevcairiel> you do
[19:45:14 CET] <nevcairiel> screw scalable
[19:45:17 CET] <nevcairiel> dont support that crap
[19:45:18 CET] <nevcairiel> :P
[19:46:02 CET] <BBB> ...
[19:46:16 CET] <nevcairiel> it needs to be called on pixfmt or size changes, but ideally on nothing else
[19:46:36 CET] <BBB> so for vp9, only on pixfmt change
[19:46:38 CET] <BBB> in theory
[19:46:49 CET] <BBB> given that size change is allowed and should not cause a reinit
[19:46:50 CET] <BBB> :-p
[19:47:21 CET] <nevcairiel> if the all mighty vp9 gods would have included information what the maximum size in a given bitstream was, that might be true
[19:47:25 CET] <nevcairiel> but oh no, they forgot!
[19:47:58 CET] <nevcairiel> so you need to call that function and the user app can decide if it wants to re-init to create bigger surfaces
[19:49:27 CET] <BBB> hahaha
[19:49:28 CET] <BBB> ok
[19:49:28 CET] <BBB> fine
[19:49:53 CET] <nevcairiel> a smart app would only re-init if something actually changes
[19:49:57 CET] <nevcairiel> but alas not everything is smart
[19:50:01 CET] <nevcairiel> including ffmpeg.c
[19:50:03 CET] <nevcairiel> =p
[19:50:26 CET] <nevcairiel> but it helps finding excessive init spam, i guess
[19:53:06 CET] <nevcairiel> when i originally tried to split update_size a bit, my main problem was that I couldn't really differentiate between the very first init on the very first thread (ie. need to clal get_format), and just secondary inits on worker threads
[19:53:20 CET] <nevcairiel> i didnt want to add some weird tracking variable for that, so..
[19:56:15 CET] <BBB> nevcairiel: http://pastebin.com/xePKgVxJ
[19:56:18 CET] <BBB> nevcairiel: how about that?
[19:57:29 CET] <nevcairiel> that still reinits every thread because last_fmt isnt synced
[19:57:33 CET] <nevcairiel> although maybe it could be
[19:57:53 CET] <nevcairiel> oh you added that
[19:57:56 CET] <nevcairiel> i should finish reading
[19:58:04 CET] <BBB> :-p
[19:58:27 CET] <BBB> and then related stuff to remove the hwaccel/thread block in lavc/utils.c etc.
[20:03:45 CET] <nevcairiel> BBB: not worky
[20:03:54 CET] <BBB> not surprised
[20:03:57 CET] <BBB> anything in particular?
[20:04:05 CET] <BBB> like, does it still call get_format per thread?
[20:04:08 CET] <BBB> or something else?
[20:04:09 CET] <nevcairiel> did you test it at all?
[20:04:13 CET] <nevcairiel> sw decoding is broke too
[20:04:18 CET] <BBB> sw works for me
[20:04:25 CET] <BBB> so yes I did test that
[20:04:30 CET] <nevcairiel> [vp9 @ 006E67E0] video_get_buffer: image parameters invalid
[20:04:30 CET] <nevcairiel> [vp9 @ 006E67E0] get_buffer() failed
[20:04:30 CET] <nevcairiel> [vp9 @ 006E67E0] thread_get_buffer() failed
[20:04:30 CET] <nevcairiel> [vp9 @ 006E67E0] Not all references are available
[20:04:30 CET] <nevcairiel>     Last message repeated 97 times
[20:04:51 CET] <BBB> ok lemmecheck
[20:05:10 CET] <BBB> probably depends on the file...
[20:05:27 CET] <nevcairiel> works if i revert the patch
[20:05:29 CET] <nevcairiel> so.. :)
[20:08:28 CET] <BBB> I meant webm vs. ivf
[20:08:31 CET] <BBB> testing
[20:08:54 CET] <nevcairiel> this is a mkv
[20:09:04 CET] <nevcairiel> actually a webm
[20:09:08 CET] <nevcairiel> just named weirdly
[20:13:29 CET] <nevcairiel> its actually my tos encode from our old benchmark =p
[20:13:33 CET] <nevcairiel> (i dont have many vp9 files)
[20:13:43 CET] <BBB> fate?
[20:13:52 CET] <BBB> anyway Im testing more, sorry
[20:20:02 CET] <Timothy_Gu> durandal_1707: for filter slice threading, is the slice width always guaranteed to be multiple of 16?
[20:24:35 CET] <Timothy_Gu> writing asm is fun
[20:27:23 CET] <durandal_1707> Timothy_Gu: you are spliting widht or height?
[20:34:08 CET] <durandal_1707> if spliting height, it is multiple of 16
[20:44:48 CET] <BBB> nevcairiel: http://pastebin.com/a0VCykS8
[20:44:55 CET] <BBB> nevcairiel: that passes fate-vp9 with 1 and 2 threads here
[20:45:33 CET] <BBB> nevcairiel: it changes the meaning of last_fmt, the value of interest for hw now becomes gf_fmt (in case youre wondering)
[20:47:55 CET] <jkqxz> wm4:  Could you specify precisely a VAAPI memory map/unmap interface that you would like?
[20:49:46 CET] <Timothy_Gu> durandal_1707: im talking about the blend filter
[20:50:01 CET] <BBB> Timothy_Gu: the constants.c patches are fine
[20:50:14 CET] <Timothy_Gu> ok
[20:50:44 CET] <Timothy_Gu> what do you think about the cross-lib constants sharing problem though?
[20:50:54 CET] <Timothy_Gu> jamrial: ^^
[20:51:24 CET] <Timothy_Gu> should i duplicate the constants like log2tab?
[20:51:29 CET] <BBB> I dont have a good solution to it ATM
[20:51:40 CET] <BBB> its not a big problem, I mean were talking a few bytes at best, so I wouldnt bother solving it
[20:51:52 CET] <BBB> but it comes up every few months so if someone feels like fixing it, go for it
[20:52:06 CET] <jamrial> either make a constants.c specific for libavfilter, or just keep things as they are because yeah, it's a bunch of bytes max
[20:52:08 CET] <BBB> x86inc.asm has macros for visibile macros
[20:52:17 CET] <BBB> er, visible arrays
[20:52:24 CET] <BBB> and these ca be shared cross-lib with avpriv prefix
[20:52:28 CET] <BBB> that should be enough
[20:52:34 CET] <BBB> but again, low priority, few bytes not worth it
[20:53:44 CET] <Timothy_Gu> yeah
[20:54:34 CET] <wm4> jkqxz: maybe something like map(AVFrame *dest, AVFrame *vaapi_frame)?
[20:54:59 CET] <wm4> I just think it's unclean to overwrite the vaapi frame itself for this
[20:59:38 CET] <jkqxz> I want to make clear that the map/unmap is a raw operation and you should understand what is going on before using it.  The user should only be using the copy to/from surface functions unless they're doing something very tricky.
[21:00:29 CET] <jkqxz> Your dest frame is allocated by the user?   What does unmap look like, exactly the same?
[21:01:38 CET] <wm4> why provide these functions at all if they're so tricky?
[21:01:48 CET] <wm4> the user can implement them manually too
[21:02:00 CET] <wm4> and yes
[21:02:57 CET] <jkqxz> They are needed for write-on-frame type things which would go in lavf.  Though, I guess they could be static for now and only global when there is a real user.
[21:04:40 CET] <durandal_1707> huh there is atrac9
[21:19:03 CET] <BBB> nevcairiel: let me know if you have time to test and whether it works for the hwaccel case if you get to it, thnx
[21:26:34 CET] <llogan> who gets messages to opw at ffmpeg.org?
[21:27:03 CET] <nevcairiel> BBB: i have been toying with your old patch, and simply initializing s->last_fmt to say -1 fixes its problems too, at least on a first glance, and seems far less invasive than your new one
[21:27:32 CET] <BBB> I think the new one is cleaner in that it clearly splits the per-thread from the per-stream variables
[21:27:44 CET] <BBB> Im a little concerned about security issues with the old patch on corrupt stuff
[21:31:32 CET] <nevcairiel> seems to work on the first try
[21:32:04 CET] <nevcairiel> lets try with fate
[21:33:13 CET] <nevcairiel> fate isnt happy
[21:33:20 CET] <nevcairiel> different results for threads and no threads
[21:35:17 CET] <nevcairiel> doesnt seem quite deterministic
[21:36:52 CET] <BBB> with hwaccel?
[21:36:56 CET] <BBB> or w/o hwaccel also?
[21:36:57 CET] <nevcairiel> yes
[21:37:26 CET] <nevcairiel> with hwaccel only i think
[21:37:53 CET] <nevcairiel> but i can run it without a couple times to make sure
[21:37:58 CET] <BBB> is it possible sw_pix_fmt is not synced between threads?
[21:38:04 CET] <BBB> (avctx->sw_pix_fmt)
[21:38:12 CET] <nevcairiel> should be
[21:38:12 CET] <BBB> since thats not synced in updatE_thread_context in pthread_frame.c
[21:38:59 CET] <BBB> I wonder what else could be desynced
[21:39:10 CET] <BBB> is it only the second frame, or first also, for the 2-frame seqs?
[21:39:30 CET] <nevcairiel> its always the second failing on some of the fate tests
[21:39:39 CET] <nevcairiel> but if it wasnt synced at all, i would think it would fail everytime
[21:40:46 CET] <BBB> true
[21:40:52 CET] <BBB> but its quick to try I guess
[21:41:34 CET] <BBB> send me a laptop or so with vp9/dxva2 support?
[21:43:58 CET] <nevcairiel> syncing sw_pix_fmt didnt help
[21:44:09 CET] <durandal_1707> BBB: we have enough money to sponsor devs
[21:44:21 CET] <BBB> canihaveanewmacbookprowithhaswell?
[21:44:29 CET] <BBB> nevcairiel: hm& let me see
[21:44:36 CET] <nevcairiel> that doesnt even have vp9 =p
[21:44:59 CET] <BtbN> there is no (intel) hardware with native vp9 support yet
[21:45:03 CET] <BBB> nevcairiel: so & setup_finished is never called right?
[21:45:37 CET] <nevcairiel> all the blocks where vp9.c would call it should be skipped in hwaccel mode
[21:46:12 CET] <BBB> and it only breaks sometimes?
[21:46:13 CET] <BBB> so strange
[21:46:33 CET] <nevcairiel> i should hook up my debug dxva2 hook and see if it sends different commands
[21:46:48 CET] <nevcairiel> i've always wanted to make a  fate test out of that to ensure noone breaks that
[21:47:28 CET] <BBB> sounds good
[21:49:15 CET] <nevcairiel> building this hook has certainly been time well spent =p
[21:50:06 CET] <BBB> agreed
[21:50:28 CET] <BBB> I dont directly have any indications what would be different w/ and w/o threads, lets see wha tthe hook says
[21:51:03 CET] <nevcairiel> now i cant get it to break gah
[21:51:15 CET] <nevcairiel> the hook writes a lot of log so its slow, wonder if it breaks the breakage =p
[21:54:30 CET] <BBB> well ok so it makes sense that its a race then
[21:54:32 CET] <BBB> but of that...
[21:54:55 CET] <BBB> can you get it to break w/o hwaccel?
[21:55:03 CET] <BBB> and if not, could that help us break down what breaks?
[21:55:30 CET] <BBB> I wonder if its possible multiple threads enter decode at the same time anyway even though they shouldnt if you remove the call to setup_finished
[21:55:40 CET] <BBB> is there some way to check that there is no concurrency?
[21:58:31 CET] <nevcairiel> i wonder if its maybe the good old problem of uncontrolled concurrency between the decoder and the user code
[21:58:58 CET] <nevcairiel> like i keep saying, hwaccel+mt is a flawed concept =p
[21:59:18 CET] <BBB> well but no amount of shit can prevent that
[21:59:19 CET] <BBB> I mean
[21:59:39 CET] <BBB> not in a sane way at least
[21:59:43 CET] <BBB> Id like to, but its tons of code
[21:59:53 CET] <BBB> and Im affraid itll break more than it fixes
[22:00:09 CET] <nevcairiel> this is why i send the patch to just disallow it in the first place
[22:00:23 CET] <BBB> I know, but people complain
[22:00:31 CET] <BBB> and if that was an issue, it should break for all codecs
[22:00:33 CET] <BBB> which it doesn'yt
[22:00:37 CET] <BBB> youre saying this is vp9 specific
[22:00:40 CET] <nevcairiel> maybe it does break
[22:00:44 CET] <BBB> can you test?
[22:00:54 CET] <nevcairiel> i dont bother to regularly test threaded hwaccel
[22:02:25 CET] <nevcairiel> BBB: just did, it breaks a lot of h264 tests randomly as well
[22:02:30 CET] <Timothy_Gu> durandal_1707: yes, it's bit-exact for all the cases I tested
[22:02:35 CET] <BBB> hm...
[22:02:45 CET] <BBB> so you think its randomized access betw. threads?
[22:02:56 CET] <durandal_1707> Timothy_Gu: real world ones, not just synthetic?
[22:02:57 CET] <BBB> user/player and codec
[22:04:30 CET] <nevcairiel> BBB: i have no proof to what *exactly* is happening, but my hunch is that the problem is that the user code has a frame locked for readback on the "main" thread, while the worker threads try to use it as a reference for decoding, which results in breakage, and there is no straight forward way for the user code to properly sync with those worker threads
[22:04:51 CET] <BBB> even though its only reading and not writing?
[22:05:10 CET] <nevcairiel> well when its locked, even readonly, the GPU may not get full access anymore
[22:05:12 CET] <nevcairiel> idk
[22:05:28 CET] <BBB> ic
[22:05:35 CET] <nevcairiel> you can apparently hack around the problem by using a big lock around the entire frame buffer pool
[22:06:12 CET] <nevcairiel> ie. just not return a new frame from get_buffer while we have a locked frame, that then stalls the worker thread until you are done
[22:06:14 CET] <nevcairiel> but its kinda ugly
[22:06:20 CET] <wm4> how to deal with threading problems: have a single big lock around everything
[22:07:07 CET] <nevcairiel> BBB: anyway i think your patch is fine, it mostly works, and the breakage is probably related to this problem, so lets just leave it and make the warning when someone tries to use it even noisier
[22:07:47 CET] <BBB> but then its still broken :(
[22:07:58 CET] <BBB> so people wanting a good fallback will be screwed
[22:08:07 CET] <nevcairiel> i mean, just running "make fate-h264 HWACCEL=dxva2 THREADS=4" is also broken, so what can you do
[22:08:31 CET] <nevcairiel> BBB: thats why i wanted to get rid of that crap
[22:08:39 CET] <nevcairiel> but alas, we have annoying people around =p
[22:08:52 CET] <BBB> no no thats not my point
[22:08:57 CET] <BBB> this patch doesnt fix anything
[22:09:04 CET] <BBB> it may make the breakage slightly more obscure
[22:09:06 CET] <BBB> but its still broken
[22:09:20 CET] <BBB> is vdpau or vaapi or whatever also broken in this way?
[22:09:24 CET] <BBB> or is it dxva2 only?
[22:09:40 CET] <nevcairiel> at least vp9 wont be broken anymore, now its just the systematic design flaw in the system that remains =p
[22:09:43 CET] <nevcairiel> i dunno
[22:10:02 CET] <nevcairiel> i would wager they are equally affected, but i have no proof
[22:10:17 CET] <llogan> feel free to add ideas to https://trac.ffmpeg.org/wiki/SponsoringPrograms/ProjectIdeas . i don't want to simply copy old, ancient, crusty ones from the old GSoC and OPW/Outreachy pages.
[22:11:32 CET] <nevcairiel> BBB: poke wm4 to run it a couple times ;)
[22:11:36 CET] <BBB> wm4: poke
[22:12:07 CET] <nevcairiel> "make fate-h264 HWACCEL=vdpau THREADS=4 -k" or something
[22:12:08 CET] <jkqxz> I can do that for VAAPI.  What do you want?
[22:12:17 CET] <nevcairiel> we dont have a ffmpeg vaapi module
[22:12:28 CET] <jkqxz> We have a patch which adds one.
[22:12:39 CET] <nevcairiel> some of the tests will always fail, like cropping, which hwaccel doesnt do
[22:12:43 CET] <nevcairiel> but the majority should pass
[22:12:51 CET] <nevcairiel> well then replace vdpau with vaapi and give it a go =p
[22:12:52 CET] <jkqxz> Most of FATE passes.  I've never thught of trying threads.
[22:12:55 CET] <wm4> BBB: run what?
[22:13:11 CET] <BBB> make fate-h264 HWACCEL=vdpau THREADS=4 -k (and the equivalent for vp9)
[22:13:14 CET] <llogan> durandal_1707: are the "==" supposed to be there? showspectrum==
[22:13:22 CET] <BBB> wm4: make fate-h264 HWACCEL=vdpau THREADS=4 -k (and the equivalent for vp9)
[22:13:23 CET] <nevcairiel> BBB: no vp9 in vdpau
[22:13:31 CET] <nevcairiel> (yet)
[22:13:36 CET] <Timothy_Gu> durandal_1707: mandelbrot and testsrc
[22:13:43 CET] <wm4> hm stupidly need to compile ffmpeg first
[22:13:53 CET] <BBB> oh shit thats vaapi
[22:13:58 CET] <BBB> anyone have vaapi?
[22:14:22 CET] <nevcairiel> also, before you can try that, you need to remove the block of hwaccel+mt from avcodec/utils.c
[22:14:25 CET] <nevcairiel> i forgot that part :D
[22:15:10 CET] <nevcairiel> wm4: jkqxz: ^ its in libavcodec/utils.c setup_hwaccel (around line 1018)
[22:15:24 CET] <llogan> durandal_1707: trailing ' in showspectrumpic zample: out.jpg'
[22:17:28 CET] <wm4> h264-conformance-cvfc1_sony_c fails
[22:17:36 CET] <nevcairiel> that one always fails, that is cropping
[22:17:58 CET] <Timothy_Gu> durandal_1707: is there any good samples i can use to test it?
[22:18:10 CET] <BBB> interesting
[22:18:14 CET] <BBB> so it works fine for vdpau
[22:18:22 CET] <wm4> h264-reinit-small_420_9-to-small_420_8 also failed (a many more)
[22:18:31 CET] <BBB> nevcairiel: I think we need to fix this then
[22:18:41 CET] <BBB> its not ok for dxva2 only failing
[22:18:54 CET] <nevcairiel> BBB: git master is fine
[22:19:03 CET] <BBB> not w/ threading
[22:19:05 CET] Action: nevcairiel leaves before anyone can bring any more arguments
[22:19:16 CET] <BBB> as in, it doesnt provide the expected ideal end user experience
[22:19:30 CET] <BBB> ok fine leave, let me break everything and never notice :-p
[22:20:14 CET] <jkqxz> Everything which I expected to pass still passes.  I lose some of the baseline streams, and cvfc1_sony_c fails as always.
[22:20:36 CET] <durandal_1707> Timothy_Gu: http://samples.ffmpeg.org/benchmark/
[22:20:43 CET] <Timothy_Gu> ok
[22:21:03 CET] <BBB> jkqxz: the threading is interesting for fallbck purposes
[22:21:05 CET] <nevcairiel> BBB: suggestions welcome, but i wont volunteer much of my time to fix a mode i consider broken by design, sorry
[22:21:23 CET] <BBB> so if I want threading in the fallback, what would you suggest I try?
[22:21:29 CET] <llogan> i keep forgetting about testsrc2
[22:21:43 CET] <nevcairiel> BBB: re-open the decoder like everyone does, except vlc
[22:21:43 CET] <wm4> keep in mind that vlc won't solve its problem, because vp9 won't work
[22:21:57 CET] <wm4> (if we were to allow threads again)
[22:22:10 CET] <BBB> vp9 wont work"?
[22:22:26 CET] <nevcairiel> wm4: they ship some binaries with libav, they are used to vp9 not working
[22:22:29 CET] <wm4> hwaccel with vp9
[22:22:31 CET] <wm4> lol
[22:22:51 CET] <wm4> so there needs to be a fundamental solution to the problem, either in lavc or vlc
[22:23:27 CET] <wm4> we can't just sweep problems under the rug like the debian guy wants to
[22:23:33 CET] <nevcairiel> maybe whatever API vaapi and vdpau use is more thread-friendly and doesnt lock the surface while downloading the image
[22:23:54 CET] <nevcairiel> on the other hand, both vdpau and vaapi probably have a bunch of alternative APIs to do that, who knows if one of those wouldnt break
[22:24:02 CET] <wm4> well, vdpau has a readback function
[22:24:11 CET] <wm4> and vaapi... has multiple ways to do it
[22:24:17 CET] <nevcairiel> not being able to sync the user thread with the decode worker thread can be an issue in various ways
[22:24:19 CET] <wm4> one of them might be essentially atomic
[22:25:25 CET] <BBB> so you really want to sync them
[22:25:27 CET] <BBB> ...
[22:25:31 CET] <BBB> omg so much stuff
[22:26:04 CET] <nevcairiel> personally i'm happy with the situation as it is right now
[22:26:09 CET] <nevcairiel> i wouldnt use a fallback if there was  one
[22:26:10 CET] <BBB> Im not against that, and I agree its fundamentally probably the right solution
[22:26:17 CET] <BBB> huh?
[22:26:18 CET] <BBB> why not
[22:26:22 CET] <BBB> ffvp9 is sooooooo cute
[22:26:23 CET] <BBB> anyway
[22:26:32 CET] <nevcairiel> because my "fallback" can also fallback to entirely different decoders
[22:26:33 CET] <Timothy_Gu> durandal_1707: yeah it works fine
[22:26:50 CET] <nevcairiel> so if hwaccel fails, i start over and select the appropriate software decoder
[22:26:53 CET] <nevcairiel> which might be avcodec
[22:26:57 CET] <nevcairiel> but it might also be something else
[22:27:33 CET] <nevcairiel> ... which right now is only either avcodec or microsofts wmv/vc1 decoder, but its not impossible to consider more additions in the future
[22:27:34 CET] <wm4> I use only libavcodec, but I also have this situation
[22:27:57 CET] <wm4> there are enough hw decoders which are not implemented as hwaccel
[22:28:35 CET] <jkqxz> VAAPI is backed by DRM so you can access it through all sorts of silly ways.  The official way disallows read while mapped, but I'm not sure that we ever count as mapped in this case.
[22:29:10 CET] <jkqxz> Hmm.  Though I can hack it to map directly, which it doesn't currently do (back to the uncached memcpy() problem), and I expect it to then fail.
[22:30:04 CET] <durandal_1707> Timothy_Gu: than its ok to push it i guess
[22:30:48 CET] <jkqxz> Except now I'm stuck because FATE doesn't auto-convert the output frame for hashing and it's NV12 or nothing if I map directly.  Blah.
[22:34:59 CET] <Timothy_Gu> durandal_1707: cool
[22:35:31 CET] <cone-484> ffmpeg 03Timothy Gu 07master:253209ac4449: vf_blend: Add SSE2 optimization for multiply
[22:35:35 CET] <kierank> do I need a bump for pixel format addition?
[22:35:39 CET] <Daemon404> yes
[22:36:02 CET] <kierank> of avutil?
[22:37:26 CET] <nevcairiel> yes
[22:37:41 CET] <BBB> nevcairiel: allright, sent patch to ML, prpare for more flametrollfests
[22:38:05 CET] <nevcairiel> jkqxz: fate seems to deal with nv12 frames for me just fine, it converts to yuv420 and gives bitexact output to the sw decoder
[22:40:19 CET] <jkqxz> Your hwaccel helper outputs NV12 frames?
[22:40:42 CET] <nevcairiel> of course
[22:41:40 CET] <jkqxz> Odd.  That doesn't work for me, every hash is wrong if I do that.  I admit I didn't pursue exactly why, but outputting YUV420P from the hwaccel helper does work.
[22:42:10 CET] <wm4> is the output visually fine?
[22:43:38 CET] <jkqxz> Yes.  NV12 output is the normal mode, except when hacked to do FATE.
[22:43:58 CET] <Daemon404> cmp
[22:44:06 CET] <Daemon404> easiest way to tell...
[22:44:22 CET] <nevcairiel> I dunno, but the ffmpeg_dxva2.c hwaccel outputs NV12 frames, and fate passes with those
[22:44:36 CET] <nevcairiel> because its processing pipeline makes yuv420p out of that
[22:50:32 CET] <jkqxz> Right, I hacked it to output YUV420P from the hwaccel (quick C code to rearrange the bytes).  Now I get exactly the expected failures (cvfc1_sony_c, the two greyscale ones, lossess).
[22:50:52 CET] <omerjerk> hey I was looking at this code - https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/utils.c#L1785
[22:51:06 CET] <nevcairiel> its really kind of unfortunate that lossless fails just because the profile checks refuse
[22:51:08 CET] <omerjerk> As far as I understand, it only seeks to the nearest I-frame, right ?
[22:51:15 CET] <nevcairiel> should probably use HWACCEL=auto to avoid the failure there
[22:51:37 CET] <omerjerk> sorry, returns the nearest I-frame, right ?
[22:52:05 CET] <llogan> is there anything that libdcadec can do that the new native decoder can't?
[22:52:24 CET] <nevcairiel> llogan: no, its based on libdcadec afterall
[22:52:59 CET] <llogan> i knew that it was based on it, but i was just curious
[22:53:16 CET] <cone-484> ffmpeg 03Michael Niedermayer 07master:8e46c7c1e7f5: avfilter/af_agate: fix memleak of out frame
[22:53:28 CET] <nevcairiel> native one should even be quite a bunch faster
[22:53:34 CET] <nevcairiel> due to SIMD
[22:54:03 CET] <jkqxz> And now I have some "Assertion src->f->buf[0] failed at libavcodec/h264_picture.c:73" when running with threads.  Is that the prize I wanted?
[22:54:06 CET] <wm4> omerjerk: depends on the format
[22:54:17 CET] <omerjerk> I'm looking matroska
[22:54:21 CET] <omerjerk> *looking at
[22:54:24 CET] <llogan> nevcairiel: ok. thanks
[22:54:30 CET] <nevcairiel> jkqxz: not really, that shouldnt happen i dont think :D
[22:54:41 CET] <nevcairiel> unless your hwaccel forgot to set buf[0]
[22:54:46 CET] <wm4> for matroska it usually uses the file index and the matroska "keyframe" markers
[22:55:01 CET] <jkqxz> It fails with threads and not without!
[22:55:11 CET] <omerjerk> ohkay. I understand it thanks. 
[22:57:52 CET] <jkqxz> Oh, it needs more than 20 surfaces simultaneously
[22:58:27 CET] <nevcairiel> every thread needs one extra surface
[22:58:31 CET] <jkqxz> Push that up further and it passes.
[22:58:35 CET] <nevcairiel> which is another reason i dislike that
[22:59:33 CET] <wm4> heh
[22:59:53 CET] <wm4> jkqxz: I hope it didn't assert because it failed to alloc a surface
[22:59:53 CET] <jkqxz> Ok, that's useful to know.  I will copy "if (s->active_thread_type & FF_THREAD_FRAME) ctx->num_surfaces += s->thread_count;" from ffmpeg_dxva2.c...
[23:00:22 CET] <nevcairiel> your buffer allocation function should probably return an error instead of silentlly not returning a surface =p
[23:01:03 CET] <jkqxz> Yeah.  (It see the error and then returns zero from the function.  How helpful.)
[23:01:28 CET] <kierank> llogan: shall I do the outreachy stuff?
[23:01:55 CET] <llogan> kierank: sure, if you have the time. if you need help I can lend a hand now and then.
[23:06:23 CET] <jkqxz> Are you sure about that thread constraint?  mr3_tandberg_b seems to require at least 46 surfaces with THREADS=4.
[23:07:19 CET] <wm4> that sounds very wrong
[23:07:38 CET] <nevcairiel> so every thread needs like 10 extra surfaces? where would those all go? :;D
[23:07:45 CET] <jkqxz> Yeah.
[23:08:13 CET] <jkqxz> 45 usually fails.  46 just passed 100 times.
[23:10:29 CET] <omerjerk> hey so there is no read_seek2 implementation for matroska. 
[23:10:42 CET] <omerjerk> so I wanted to ask, how difficult it would be if plan to work on it?
[23:10:49 CET] <omerjerk> also, will it be useful ?
[23:10:58 CET] <nevcairiel> you should ask yourself if it will be useful
[23:10:59 CET] <omerjerk> And how is it different from just read_seek ?
[23:11:00 CET] <wm4> omerjerk: there's no need for it?
[23:11:19 CET] <nevcairiel> why would you suggest working on it if you dont know if its useful :D
[23:11:49 CET] <wm4> maybe he's using that "new" seek function that causes random trouble or so
[23:11:55 CET] <omerjerk> I think it should be useful because everywhere in the code we first check if that implementation is available or not.
[23:12:05 CET] <nevcairiel> it only causes trouble if you use it wrong, since its signature is different to the old one
[23:12:13 CET] <wm4> omerjerk: there are dozens of such formats
[23:12:17 CET] <nevcairiel> otherwise it just falls back to the old one
[23:12:24 CET] <jkqxz> Something strange happens with mr[345]_tandberg_[bc].  Everything else passes with 20 + thread count surfaces available, they run out.
[23:12:25 CET] <wm4> and why would more code be better than less code?
[23:12:38 CET] <nevcairiel> and one if check in the seek function isnt overhead we worry about
[23:12:47 CET] <wm4> jkqxz: mayba a leak?
[23:12:48 CET] <nevcairiel> seeking is not something that happens every few milliseconds
[23:12:58 CET] <omerjerk> okay. 
[23:14:46 CET] <jkqxz> Maybe this is baseline profile messing with me somehow.
[23:16:57 CET] <jkqxz> Blah, they're all foreman.  These people need more originality in test videos.
[23:17:03 CET] <nevcairiel> hehe
[23:17:28 CET] <nevcairiel> some of the hevc videos are random colored noise
[23:17:40 CET] <nevcairiel> one of those had a checksum difference
[23:17:50 CET] <nevcairiel> try to spot a difference in the image in random colored noise
[23:26:09 CET] <jkqxz> Ah.  The hwaccel decoder allocates surfaces to fill frame_num gaps.
[23:26:44 CET] <jkqxz> These streams have big gaps in them.
[23:27:03 CET] <nevcairiel> wouldnt that also happen with single threaded then
[23:29:04 CET] <jkqxz> Yes, but it works because it never tries to allocate a frame which it actually wants to use before freeing the redundant ones in single-threaded.
[23:31:19 CET] <jkqxz> (The log is full of "wtf disaster!" errors, but the output is correct.)
[23:48:06 CET] <omerjerk> wm4: I actually started with the problem when I use the -se flag in ffmpeg. 
[23:48:20 CET] <omerjerk> I tested with a mkv file. 
[23:48:50 CET] <omerjerk> Even if I pass it 10 seconds, it only seeks to ~7.2 seconds. 
[23:49:06 CET] <omerjerk> I'm assuming, it is seeking to the nearest keyframe. 
[23:49:23 CET] <omerjerk> am I right ?
[23:49:57 CET] <omerjerk> that's what the code looks to me at least. 
[23:50:44 CET] <nevcairiel> of course it does, it cant seek to anything else
[23:50:52 CET] <nevcairiel> you wouldnt be able to start decoding at anything but a keyframe
[23:52:23 CET] <omerjerk> okay
[23:58:54 CET] <kierank> Timothy_Gu: you should write cfhd asm :)
[23:59:06 CET] <kierank> you'd get huge speed boosts
[00:00:00 CET] --- Tue Feb  9 2016