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

[burek]

[00:29] <wm4> there are no FATE tests for seeking, right?
[00:43] <ubitux> wm4: fate/seek.mak?
[00:48] <wm4> ok
[00:51] <wm4> that doesn't seem to test decoding
[00:51] <wm4> i.e. whether the packets are valid?
[00:52] <wm4> or maybe the packet size is always good enough for this purpose?
[01:14] <cone-967> ffmpeg.git 03Michael Niedermayer 07release/1.1:c6f59b95c529: h264: avoid calling get_format() multiple times
[01:14] <cone-967> ffmpeg.git 03Michael Niedermayer 07release/1.1:56b6909b395e: movenc: hotfix, dont store fiel for h264 / mpeg4-asp / dnxhd
[01:14] <cone-967> ffmpeg.git 03Diego Biurrun 07release/1.1:7acfa7758c7f: configure: Make warnings from -Wreturn-type fatal errors
[01:25] <cone-967> ffmpeg.git 03Diego Biurrun 07release/1.1:1ca25bc38775: libopencore-amrnb: cosmetics: Group all encoder-related code together
[01:25] <cone-967> ffmpeg.git 03Diego Biurrun 07release/1.1:e492818d8925: libopencore-amr: Conditionally compile decoder and encoder bits
[01:25] <cone-967> ffmpeg.git 03Diego Biurrun 07release/1.1:a23d6ea1e443: libopencore-amrwb: Make AMR-WB ifdeffery more precise
[01:25] <cone-967> ffmpeg.git 03Diego Biurrun 07release/1.1:6c62098827d3: build: The libopencore-amrnb encoder depends on audio_frame_queue
[01:25] <cone-967> ffmpeg.git 03Luca Barbato 07release/1.1:b9a287f23700: build: make audio_frame_queue a stand-alone component
[01:25] <cone-967> ffmpeg.git 03Matti Hamalainen 07release/1.1:d61c6ebccfde: svq3: unbreak decoding
[01:25] <cone-967> ffmpeg.git 03Michael Niedermayer 07release/1.1:0f5a0a415510: Merge remote-tracking branch 'qatar/release/9' into release/1.1
[01:35] <cone-967> ffmpeg.git 03Hendrik Leppkes 07release/1.1:e14564b9262d: lavfi/kerndeint: use av_pix_fmt_desc_get instead of directly accessing the table
[01:35] <cone-967> ffmpeg.git 03Michael Niedermayer 07release/1.1:f5955d9f6f9f: targa: Fix y check in advance_line
[01:35] <cone-967> ffmpeg.git 03Michael Niedermayer 07release/1.1:1ea5bbc5940d: sanm: add forgotten check for decoded_size in old_codec37()
[01:35] <cone-967> ffmpeg.git 03Michael Niedermayer 07release/1.1:1400f1a1e46d: sanm: Use the correct height variable in the decoded_size checks
[01:35] <cone-967> ffmpeg.git 03Michael Niedermayer 07release/1.1:f6687bbb6464: pngdec/filter: dont access out of array elements at the end
[01:35] <cone-967> ffmpeg.git 03Michael Niedermayer 07release/1.1:75211f2b8cfb: tiff: Check buffer allocation and pointer increment more carefully in shorts2str() and double2str()
[01:36] <cone-967> ffmpeg.git 03Michael Niedermayer 07release/1.1:811a504c6bc2: shorten: dont leave invalid channel counts in the context.
[01:36] <cone-967> ffmpeg.git 03Michael Niedermayer 07release/1.1:7c40a0449b47: swr: check channel layouts before using them.
[01:50] <BBB> michaelni: ok, fixed for that one crash at least
[01:50] <BBB> michaelni: it's hard for me to run complete fate, but if you find more crashers, let me know and I'll fix them too
[01:50] <BBB> michaelni: seems to work for me now
[03:01] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:a3a97129e79d: mpegvideo: make ff_print_debug_info independant of mpegvideo
[03:01] <cone-967> ffmpeg.git 03Michael Niedermayer 07master:d41efc1f267c: h264: put visualization and debug support back
[03:41] <BBB> michaelni: where do I find svq3_watermark.mov?
[03:51] <Compn> should be listed in allsamples.txt
[03:51] <Compn> http://samples.ffmpeg.org/mov/watermark/svq3_watermark.mov
[03:51] <Compn> BBB : ^^
[03:53] <BBB> ty
[03:53] <BBB> I don't know how allsamples.txt works
[03:56] <michaelni> http://samples.ffmpeg.org/allsamples.txt should list all samples so one can easily grep in it
[03:59] <Compn> ehe
[03:59] <Compn> BBB : you dont have a copy of the samples repo on your hd ?
[03:59] <Compn> michaelni : how many tests do you run on the samples? i mean, how did you find out svq3_watermark.mov had a problem? :)
[04:00] <BBB> Compn: how much HD space do you think I have?
[04:00] <BBB> I have a little laptop that is easily portable at home, that's all
[04:00] <Compn> BBB : last i checked it was only ~60gb
[04:00] <Compn> 64G     unified/
[04:01] <BBB> my hd generally is full of pictures, music and stuff
[04:01] <BBB> you know, I have kids and stuff, I have ... baggage, as they'd say
[04:01] <Compn> no problem :)
[04:01] <Compn> ssd arent there yet with the size
[04:01] <BBB> I'll just download them as needed
[04:05] <BBB> hm right the 8x8 only clears one half of the block data
[04:05] <BBB> let me try to fix that
[04:07] <BBB> ok, that's fixed now, now idct8_add4 seems broken also
[04:07] <BBB> blegh
[04:11] <BBB> ok h264 fixed
[04:11] <BBB> will test svq3 in a bit, may well be fixed by the same thing
[04:12] <BBB> yeah looks mostly the same to me now
[04:12] <BBB> michaelni: care to test again?
[04:22] <BBB> oh nm the crcs are different
[04:22] <BBB> lemmecheck
[05:45] <highgod>  Hi, I want to ask a question. When will the next ffmpeg release version be published? where can I get the time schedule about ffmpeg release version be published? thanks
[05:50] <Compn> no idea :)
[05:51] <Compn> maybe michaelni knows release schedule
[05:51] <Compn> usually after a bunch of bugs are fixed, and new bugs are merged in
[05:59] <highgod> @Compn:thanks, does ffmpeg will publish a version on march? I have read the comments, and I have some quesions, and I have sent the email.
[06:04] <BBB> michaelni: nice bug you detected there in svq3_watermark.mov
[06:04] <BBB> congrats on that
[06:27] <highgod> michaelni:do you know when the next ffmpeg release version be published?
[06:27] <highgod> Thanks
[10:10] <ubitux> highgod: please fix your mailer and reply below each comment
[10:10] <ubitux> currently you're duplicating the whole mail, without quoting, so the previous mail is mixed with your answer
[10:10] <ubitux> it's unreadable
[10:52] <durandal_1707> ubitux: should i sent new blend patch or just commit?
[10:53] <ubitux> saste is more familiar than me with the multiple input thing
[10:53] <ubitux> you may want to ask him before
[10:53] <ubitux> or maybe Nicolas
[12:05] <michaelni> highgod, a new major release every 3 month (more or less) minor releases randomly
[12:16] <cone-841> ffmpeg.git 03Paul B Mahol 07master:f2d200d460ab: lavfi/overlay: yuv444p & yuva444p support
[12:16] <cone-841> ffmpeg.git 03Paul B Mahol 07master:03b711d95e28: tmv: initialize unused pallete entries with 0
[12:21] <highgod> Thanks
[12:21] <highgod> @ubitux:I got it. thanks
[12:24] <cone-841> ffmpeg.git 03Vicente Jimenez Aguilar 07master:202b5f6deb65: doc: Fix some obsolete references to av* tools as ff* tools
[12:24] <cone-841> ffmpeg.git 03Michael Niedermayer 07master:4e469842b525: Merge commit '202b5f6deb65e405b07b9b5c20f97c8cb925cf49'
[12:36] <cone-841> ffmpeg.git 03Daniel Kang 07master:7a03145ed7cb: x86: dsputil: int --> ptrdiff_t for ff_put_pixels16_mmxext line_size param
[12:36] <cone-841> ffmpeg.git 03Michael Niedermayer 07master:cf10616cc0db: Merge commit '7a03145ed7cb4f1ce794b5126559dd6f38029243'
[12:41] <highgod> @ubitux:should I just write the replies under the comments of the orignal mail?
[12:54] <mateo`> hello, i'm trying to fix the frame duplication issue i have with interlaced jpeg2000 patch. Since the decoder output a single frame for 2 video packets, is there a proper way to correct the pts/dts of the decoded frame so that ffmpeg won't duplicate frames ? (-vsync 0 does the trick)
[12:55] <michaelni> mateo`, sounds like something sets wrong timestamps
[12:55] <michaelni> did you look at the demuxer timestamps ? and the framerate choosen ?
[12:56] <mateo`> yes pkt_pts and pkt_dts seems ok within the decoder
[12:58] <mateo`> i tried to devide by 2 the pkt_pts and pkt_dts within the decoder when it outputs a full frame but it does nothing
[12:58] <mateo`> (maybe i'm not supossed to do that in the decoder)
[12:59] <cone-841> ffmpeg.git 03Daniel Kang 07master:9acd23d655b5: x86: dsputil: Fix h263 loop filter link error in some configurations
[12:59] <cone-841> ffmpeg.git 03Michael Niedermayer 07master:fa09ad5c9e68: Merge remote-tracking branch 'qatar/master'
[12:59] <cone-841> ffmpeg.git 03Michael Niedermayer 07master:b9237aa7b090: x86/h263_loopfilter: Fix author attribution after code has been moved/splited around
[15:12] <cone-841> ffmpeg.git 03Michael Niedermayer 07master:b97d61f924ee: avfilter/ff_merge_formats: only merge if doing so does not loose chroma or alpha
[15:16] <Compn> this bug looks invalid, AWS problem not ours ... https://ffmpeg.org/trac/ffmpeg/ticket/1486
[15:26] <Compn> yay i closed a bug :)
[15:31] <durandal_1707> nooooooooooooooooooooooooooooooooooooo
[16:02] <ubitux> durandal_1707 ?
[16:21] <cone-841> ffmpeg.git 03Ronald S. Bultje 07master:a1f1ca96b426: svq3: fix decoding residual blocks of b-frames.
[16:43] <cone-841> ffmpeg.git 03Ronald S. Bultje 07master:1acd7d594c15: h264: integrate clear_blocks calls with IDCT.
[16:50] <Compn> ubitux : i think he was making a joke about me closing a bug
[16:51] <ubitux> oh. my bad.
[17:02] <wm4> why does linking to libav* add -SDLmain?
[17:03] <durandal_1707> because of sdl in lavd?
[17:03] <wm4> but why -SDLmain?
[17:03] <wm4> this is completely retarded
[17:04] <wm4> I wonder why you'd ever need -lSDLmain at all
[17:04] <wm4> it's a crap hack
[17:04] <wm4> I almost feel like adding a horrible hack to configure to filter it out
[17:04] <durandal_1707> i don't see it anywhere
[17:05] <durandal_1707> perhaps that is what pkgconfig returns
[17:05] <wm4> yes, it is
[17:05] <wm4> hm maybe it's recursively added from the SDL .pc
[17:05] <cone-841> ffmpeg.git 03Michael Niedermayer 07master:633f9974790e: bmp: check available space when reading palette
[17:06] <wm4> indeed it is
[17:06] <wm4> got to report this as SDL bug
[17:06] <wm4> because... seriously.
[17:08] <durandal_1707> i don't have that here with old SDL (one from FreeBSD ports though)
[17:11] <wm4> I get it with 1.2.15
[17:11] <wm4> but well, it's a windows-only thing
[17:11] <wm4> so it won't happen with a unix native libsdl
[17:11] <wm4> just mingw packages
[17:12] <durandal_1707> same version here
[17:12] <durandal_1707> how would you describe lavfi in few words?
[17:13] <wm4> "new ways of hiding semi-useful functionality under awkward APIs"
[17:15] <durandal_1707> that is too much words, i need 5 max
[17:21] <Compn> lol
[17:22] <Compn> durandal_1707 : powerful filters with confusing syntax
[17:22] <Compn> :D
[17:22] <Compn> sorry,  i am too honest :)
[17:22] <Compn> i love the filters :)
[17:22] <Compn> i dont want to spend 20 minutes to figure how to write the right command line tho
[17:23] <Compn> the examples are good, i want more of them.
[17:23] <wm4> even Compn (mplayer and mencoder veteran) thinks the syntax is confusing
[17:24] <Compn> by confusing i mean, most people only know 8th grade math (and probably lower than that) so creating equations is difficult 
[17:25] <Compn> the filters are complex, so they need to have the ability to provide details like that. but most users wont be able to use them as-is
[17:25] <Compn> without some kind of frontend, script, examples, etc
[17:26] <Compn> i never understood custom matrices in mpeg encoding either... 
[17:26] Action: Compn not the smartest
[17:28] <wm4> it just means it's not userfriendly
[17:31] <Compn> j-b : is there someone working on the g2m decoder? 
[17:31] <Compn> j-b : kostya updated his blog http://codecs.multimedia.cx
[17:45] <durandal_1707> what about those cinepak patches?
[17:51] <divVerent> Compn: what annoys me most about the filters is how the tags work
[17:51] <divVerent> as long as your filters are a single chain, you can use comma to avoid most tag use
[17:52] <divVerent> but it is quite annoying that to insert a filter into the middle of e.g. [in] foo [mid]; [mid] [in2] bar [out]
[17:52] <divVerent> you suddenly have to RENAME a tag
[17:53] <divVerent> and e.g. turn it into [in] foo [new]; [new] added [mid]; [mid] [in2] bar [out]
[17:53] <divVerent> this is especially bad if you want to programmatically edit filter chains
[17:53] <divVerent> of course, in this case, comma syntax helps too ([in foo, added [mid]; [mid] [in2] bar [out]
[17:53] <divVerent> )
[17:53] <divVerent> but that can't be used in the general case
[17:54] <divVerent> so to add a filter before [tag], you need to rename existing OUTPUT uses of [tag] to [newtag], then add [newtag] addedfilter [tag]... the "rename" part here is annoying
[17:56] <divVerent> however, having said that this syntax sucks... I have no constructive idea about doing it better :(
[17:56] <ubitux> it looks like you are complaining in a situation where you have a variable foo and when wanting to add a similar variable you need to rename it to foo0 and add foo1
[17:56] <ubitux> :))
[17:56] <durandal_1707> using single line for just this is wrong
[17:56] <divVerent> ubitux: in C this issue is simple to solve :P
[17:57] <divVerent> just add functioncall(...) around the expression
[17:57] <divVerent> but C syntax doesn't help us for filters, as a function can only have one return value there
[17:57] <divVerent> I wonder if a Haskell-style "let" would actually help :P
[17:58] <durandal_1707> script reader
[17:59] <wm4> and then there's this idea to use Lua to build the filtergraph
[17:59] <divVerent> https://gist.github.com/4987734
[17:59] <divVerent> actually, the concept of Haskell's "let" would help
[17:59] <divVerent> wm4: does Lua fix the issue, is the question
[18:00] <divVerent> basically, the idea of this "let" use is to have a way to insert filters at a point by JUST inserting text
[18:00] <durandal_1707> wm4: using single line to describe filtergraph is silly
[18:00] <wm4> divVerent: it seems vsynth is doing fine with using Python for building graphs
[18:00] <divVerent> durandal_1707: that is mostly the issue
[18:00] <divVerent> wm4: wonder if it has the same issue, for dynamically generated graphs
[18:00] <divVerent> or mkanually edited graphs
[18:01] <durandal_1707> where are devs when you need them
[18:02] <divVerent> haha, C/Perl-like syntax WOULD help a great deal already
[18:02] <divVerent> https://gist.github.com/4987753
[18:02] <BBB-work> michaelni, opinions on https://github.com/rbultje/ffmpeg/commit/be3d3b499bd241b7d6f7d9b4b6d91cb2dce5f5fe ?
[18:02] <divVerent> i.e. clear distinction between input and output args
[18:02] <divVerent> in C done by &, in perl done by creating the variables using "my", ...
[18:02] <divVerent> this way, the filter insertion can be done by pure text operations
[18:02] <divVerent> which is basically my goal
[18:02] <wm4> well, Lua and python can return tuples
[18:03] <divVerent> right, but we still need a way to easily programmatically build a filter graph
[18:03] <divVerent> e.g. to add the subtitle renderer only if subtitles are present
[18:03] <Compn> durandal_1707 : well the patch author just said the code for rejecting strips could be moved to detecting incomplete blocks... i think someone said we shouldnt make a regression by not playing some files due to his patch
[18:03] <Compn> durandal_1707 : so it would be nice if his patch doesnt affect the playing of (possibly broken) files
[18:03] <saste> divVerent, lua scripting will be possibly a gsoc task i'd like to mentor
[18:04] <Compn> will the patch author do that or will someone else have to is the question
[18:04] <saste> otherwise i'll tackle it myself as soon as i'll have some time (not before a few months)
[18:04] <Compn> saste : should i start writing gsoc 2013 page ?
[18:04] <saste> Compn, wait for llogan
[18:04] <divVerent> wm4: BTW, actually found now that my "ffstuff" can't handle my test case :P
[18:04] <saste> he asked mike if we should use multimediawiki.cx
[18:04] <divVerent> or... it can? why did it work at all then
[18:04] <BBB-work> actually let's send that to the ml
[18:05] <Compn> saste : thats what we've always used ....
[18:05] <divVerent> AH, because one tag is defined later :P
[18:05] <saste> if we use trac we should make sure that can't be hacked by a random user
[18:05] <divVerent> that's the sole reason why it even works+
[18:05] <Compn> trying to avoid conflict or something ?
[18:05] <cone-841> ffmpeg.git 03Michael Niedermayer 07master:a34418c28e0a: tiff: check bppcount
[18:05] <BBB-work> if you want to see h264 w/o mpegvideo and dsputil, that three patches finish it
[18:05] <divVerent> because in ffmpeg filter graphs, it's hard to detect by text checks whether a tag is an input or an output
[18:05] <saste> Compn, i don't know if mike is still actively maintaining the wiki
[18:06] <saste> if he's not, he could be non responsive for granting access to new contributors
[18:06] <Compn> oh
[18:06] <saste> so i'd say let's wait a day or two
[18:06] <Compn> who needs new wiki contribs ? :P
[18:06] <Compn> students claim on the ml, devels change it on wiki
[18:06] <Compn> but ok
[18:06] <merbanan> BBB-work: did you really untie the Gordian knot ?
[18:07] <saste> Compn, i don't know who has access to the (multimedia.cx) wiki
[18:07] <Compn> merbanan : he also fixed svq3 breaking too :)
[18:07] <saste> also we don't want to depend on it if mike is not maintaining it
[18:07] <Compn> saste : http://wiki.multimedia.cx/index.php?title=Special:Listusers
[18:07] <Compn> hehe
[18:07] <Compn> yeah i got it
[18:08] <saste> e.g. in case of attacks or spamming
[18:08] <Compn> somewhat trolling
[18:08] <BBB-work> merbanan, it doesn't compile yet if you actually make dsputil files selectable, but it's close
[18:08] <saste> that's why we should wait his reply
[18:08] <BBB-work> merbanan, what's left is the constants in dsputil_mmx (pw_N)
[18:08] <Compn> BBB-work : did you run benchmarks on it ?
[18:09] <Compn> oh i guess that doesnt change too much, nm
[18:10] <michaelni> BBB-work, lots of ifdefs in be3d3b499bd241b7d6f7d9b4b6d91cb2dce5f5fe
[18:11] <michaelni> not really pretty
[18:11] <michaelni> does it have some users / usecase ?
[18:12] <ubitux> i guess the reason is to have a config without the dspcontext need
[18:16] <BBB-work> michaelni, chrome would use it
[18:16] <BBB-work> michaelni, note how it removes dspcontext from h264
[18:16] <BBB-work> michaelni, that's a major size reduction
[18:17] <BBB-work> merbanan, and secondly, the zigzag scan table permutators; thirdly, hpeldsp is still in there (used by vp3); fourthly, all the rectangular fullpel mc functions are currently in dsputil, but shared between chromamc (bilin), h264/mpeg4qpel, vp8mc, hpeldsp; all this needs to be made more generic for it to be truly finished
[18:17] <BBB-work> merbanan, but it's almost there
[18:18] <BBB-work> michaelni, might be worth doing the same for mpegvideo-derived codecs also; a lot of cases, you don't want er, you just want to error out
[18:19] <nevcairiel> why would you want to error out instead of trying to mask an error? too risky that there are other bad errors in there?
[18:21] <BBB-work> showing a corrupt frame only makes sense if the transport mechanism somehow allows that to have any meaning
[18:21] <BBB-work> e.g. multi-slice frame, one slice corrupt: all is fine
[18:21] <BBB-work> single-slice frame, one slice corrupt: yeahright
[18:21] <BBB-work> vp8 same with partitions
[18:21] <nevcairiel> doent er also cover single macroblock corruptions?
[18:21] <BBB-work> over tcp, if the file is corrupt, it means the source was corrupt, so you want to error out if you're chrome
[18:22] <BBB-work> over udp, the stream commonly becomes corrupt because of natural transport issues
[18:22] <BBB-work> so it all depends on the use case
[18:22] <BBB-work> for chrome, we don't want er; error means error out
[18:22] <nevcairiel> not that ffmpegs ER is the best in the world anyway, my GPUs hardware decoder does a better job at covering things up in some clips =p
[18:23] <BBB-work> plus er is slow, introduces extra security risks (more code to cover), is not as well tested, doesn't support >8bpp, I'm not even sure it supports non-420
[18:23] <BBB-work> isn't integrated with ffvp8
[18:23] <BBB-work> there's tons of issues with it
[18:23] <BBB-work> we'd prefer to not use it
[18:23] <michaelni> is there a big disadvantage over making ER optional while leaving most things in h264.c so there are few ifdefs?
[18:24] <BBB-work> no, that should be fine
[18:24] <BBB-work> I just did the ifdef route so I know I fixed all users
[18:24] <BBB-work> but I can just add if (CONFIG_ER) around the relevant calling blocks and leave the assignments that don't require er symbols in place
[18:24] <BBB-work> I don't care about 100bytes of unused ERContext memory in H264Context
[18:25] <michaelni> if(CONFIG_ER) sounds alot better than ifdefs
[18:25] <BBB-work> sure, can adapt
[18:25] <BBB-work> we might need to make ER explicitely settable in configure than
[18:25] <BBB-work> since currently, --disable-everything --enable-decoder=h264 will disable er
[18:25] <BBB-work> with no way to enable it other than --enable-decoder=vc1 or so
[18:26] <BBB-work> which isn't quite ideal
[18:26] <nevcairiel> cant you make it enabled by default if a decoder is selected which uses it, unless overriden at command line?
[18:26] <BBB-work> I don't know enough about configure to know how to do that
[18:27] <ubitux> with the _select vars maybe
[18:27] <michaelni> about lack of >8bpp support, it also lacks support for interlaced concealment, i suspect these are why the GPU is better, our error concealmentz was actually quite good in the cases that it supports when i last compared to other decoders but thats long ago
[18:28] <michaelni> interlace, >8bpp support should of course be added ...
[18:28] <nevcairiel> my clip was 420 8bpp
[18:28] <nevcairiel> looks like a slice was failing
[18:29] <nevcairiel> ffmpeg overwrote the previous reference frame with a flat color more or less, while the gpu decoder just seemed to try to interpolate some motion vectors on top of it, which looked OKish because there wasnt much movement
[18:29] <ubitux> (btw, it would be nice to fix all the uninitialized read issues recently introduced...)
[18:29] <ubitux> libav might have not realized it because their valgrind+undef is broken
[18:30] <michaelni> nevcairiel, probably makes sense to open a ticket with sample file and screenshoot
[18:30] <nevcairiel> i'll put it on my list of things todo for a rainy day
[18:31] <nevcairiel> at least i still know which sample it was
[18:33] <michaelni> nevcairiel, also try with threads 1, could be a thread issue
[18:34] <michaelni> on that rainy day thart is
[18:34] <nevcairiel> i suppose
[18:34] <nevcairiel> i'll try to remember this
[18:34] <nevcairiel> lately i'm happy to have time to sleep
[18:37] <BBB-work> it's certainly true er is broken wiht threading
[18:38] <BBB-work> mpeg-er has ff_thread_await_progress() indicators
[18:38] <BBB-work> h264-er doesn't, they're explicitely marked as FIXME
[18:38] <BBB-work> lack of a fate test means I couldn't be sure it worked or not so I just left it out
[18:38] <BBB-work> (i.e. yes we need a h264-er test)
[18:39] <nevcairiel> just out of curiosity, does the spec outline how missing slices for example should be handled?
[18:41] <BBB-work> no
[18:41] <BBB-work> hm does implement something for it, I believe
[18:41] <BBB-work> but you're not required to follow that, from what I understand
[18:41] <BBB-work> jm, not hm
[18:41] <BBB-work> lol
[18:43] <durandal_1707> stupid spammer
[18:43] <BBB-work> I also wonder if I should make ercontext embed dspcontext, so the caller doesn't have to set it anymore
[18:45] <durandal_1707> how to permanently remove files uploaded to trac?
[18:46] <durandal_1707> saste: gonna comment on blend filter?
[18:47] <saste> durandal_1707, yes in a few hours, please wait
[18:59] <michaelni> slavon888 	Smartmil8 	smartmil888 at gmail.com
[18:59] <michaelni> IP address: 	93.84.19.159
[19:05] <michaelni> BBB-work, for frame threading with EC not only does the EC code need to wait for its references to be available subsequent frames also need to wait as soon as a slice is missing or damaged, i think they dont currently
[19:06] <saste> i'm going to implement an annoying feature in overlay
[19:06] <michaelni> slice threading should work with EC though 
[19:08] <durandal_1707> saste: what that means?
[19:11] <saste> durandal_1707, that people will suffer because of that
[19:11] <durandal_1707> saste: what feature?
[19:11] <saste> durandal_1707, surprise, but you can easily guess what
[19:12] <durandal_1707> i lost my pil
[19:12] <saste> no more teasers
[19:13] <BBB-work> michaelni, no they do (at least for mpeg1/2)
[19:13] <BBB-work> michaelni, for h264 they probably don't, you may be right
[19:20] <cone-841> ffmpeg.git 03Paul B Mahol 07master:76415a942051: configure: fix libavfilter pkgconfig description
[19:21] <michaelni> mpeg1/2 do only slice threads
[19:23] <michaelni> also theres the problem that a error in MB x,y can produce the first detectable error a row or more later
[19:23] <michaelni> (not in mpeg2 which is a special case here)
[19:25] <BBB-work> maybe it's mpeg4
[19:25] <BBB-work> it's the one covered by the -error fate test
[19:26] <BBB-work> I don't know which mpeg it is, they all look so much alike (and are - honestly - all equally useless)
[19:31] <michaelni> yes, seems mpeg4 has a simple check
[20:37] <saste> ubitux, durandal_1707: how hard would be to make showspectrum output a frame only when it is completely filled?
[20:38] <saste> this should allow to compose a global spectrum image
[20:54] <durandal_1707> saste: aren't you lavfi expert?
[20:55] <durandal_1707> saste: fix your connection
[20:55] <durandal_1707> by calling ff_filter_frame only once
[20:56] <durandal_1707> lol
[20:57] <saste> damn
[20:59] <durandal_1707> saste: got any of my replies?
[21:01] <saste> i got: by calling ff_filter_frame only once
[21:02] <saste> i tried to look at the code, and changing the logic for outputting just one filled frame doesn't look trivial
[21:02] <saste> that's why i asked
[21:03] <nevcairiel> michaelni: i took two screenshots of the EC behaviour on this clip http://screenshotcomparison.com/comparison/8966 .. while you can see that there is something wrong in the GPU decoded image, its by far not as obvious (and even less so when the image is moving) .. and the second one is even worse: http://screenshotcomparison.com/comparison/8968
[21:03] <nevcairiel> its single threaded, so not related to threading in this case
[21:04] <durandal_1707> saste: why it is not trivial?
[21:06] <nevcairiel> a user actually asked me once for this particular clip if avcodec was broken, because he couldnt see the corruption with the gpu decoder, and thought it might be a software issue =p
[21:06] <nevcairiel> i will upload the clip and open a ticket, i guess
[21:07] <saste> durandal_1707, why? because of the caching logic, which is not immediate to grasp
[21:14] <ubitux> between two timeouts, feel free to tell him "no" to answer his question
[21:15] <ubitux> damn it's not answering the question
[21:15] <ubitux> then "hard at 5%"
[21:16] <durandal_1707> ^ what that last one means?
[21:16] <ubitux> it means it's not hard
[21:17] <durandal_1707> than do it before saste comes ;)
[22:04] <cone-841> ffmpeg.git 03Michael Niedermayer 07master:ce153eef8ffd: vc1dec: dont decode slices when the slice header failed to decode.
[22:22] <durandal_1707> saste: fixed connection?
[22:23] <saste> durandal_1707, don't know, it doesn't depend on me
[22:23] <saste> let's see if it lasts
[22:24] <durandal_1707> saste: what caching logic you see in showspectrum?
[22:25] <saste> durandal_1707, in showwaves i send the frame only when I fill the frame
[22:25] <durandal_1707> so?
[22:25] <saste> with showspectrum it is different, since the frame is updated at each audio frame, right?
[22:25] <saste> so it is different
[22:26] <durandal_1707> i dont think updating frame is good idea (even you could store frame data in another buffer)
[22:26] <durandal_1707> generally see what sox does
[22:27] <saste> durandal_1707, sox is not meant for audio visualization
[22:27] <saste> i want that feature mostly to be able to generate a single image containing the audio spectrum
[22:29] <durandal_1707> saste: sox does just that
[22:30] <durandal_1707> for some duration - can be whole file
[22:30] <saste> durandal_1707, will you implement that feature of should I look at it?
[22:30] <durandal_1707> but lavfi do not know what is duration of file yet, but this does not stop you to implement it
[22:31] <durandal_1707> saste: i plan to work on exr and filters (blend, stereo3d, noise, etc ...)
[22:32] <saste> durandal_1707, i don't mind, as long as I can script it and use tile and scale if necessary
[22:32] <saste> my problem is that don't want overlapping frames
[22:32] <durandal_1707> you return frame at EOF
[22:35] <durandal_1707> saste: those doxygen issues you mentioned are present in geq/overlay too
[22:35] <durandal_1707> i just copy-pasted it
[22:36] <saste> durandal_1707, i know
[22:36] <durandal_1707> saste: can av_image_copy() copy only one plane?
[22:37] <saste> durandal_1707, av_image_copy_plane
[22:37] <durandal_1707> nice
[22:39] <saste> durandal_1707,  i was sleeping when reviewing your overlay patch
[22:40] <saste> working on a fix right now
[22:40] <durandal_1707> saste: i had conversation on issue with michaelni
[22:40] <durandal_1707> there are two solution: elegant and less elegant one
[22:40] <saste> an ugly fix
[22:41] <saste> yes I'm working on the less elegant/simpler
[22:41] <durandal_1707> elegant is very simple
[22:41] <durandal_1707> and makes filter simpler
[22:42] <saste> durandal_1707, how?
[22:42] <saste> does it involve scaling?
[22:42] <durandal_1707> what you mean with more explicit check for inputs dimensions?
[22:42] <durandal_1707> saste: no, using single pix fmt list
[22:42] <saste> i meant a more explicit *error message*
[22:42] <saste> like the one in concat
[22:43] <saste> durandal_1707, i don't understand about overlay
[22:43] <saste> what I'm doing now is to select the "format", either yuv420, yuv444, rgb
[22:44] <saste> it is a generalization of the rgb option
[22:44] <durandal_1707> removing slow rgba code handling different rgbs in inputs
[22:45] <durandal_1707> i see no point to allow inputs to be of different pix fmts
[22:45] <saste> durandal_1707, the overlay is usually alpha
[22:45] <saste> why do you need to add alpha to the main input?
[22:47] <durandal_1707> than API have limitations
[22:48] <durandal_1707> there should be way to force inputs to have same subsampling and etc
[22:48] <durandal_1707> but anyway rgba handling is funny
[22:48] <saste> how?
[22:49] <durandal_1707> converting both inputs to same one would be faster than conversion code in filter
[22:49] <durandal_1707> because you would do just memcpy in filter
[22:50] <durandal_1707> saste: also why if i give single images as inputs to blend filter i get nothing in output?
[22:50] <durandal_1707> looks like there is of by 1 error somewhere
[22:51] <durandal_1707> eg, using 2 images for inputs give 1 output frame
[22:51] <saste> durandal_1707, two images for *both* inputs?
[22:51] <saste> or two images in total?
[22:52] <saste> also I see no synchronization mechanism in your code
[22:52] <durandal_1707> two images in total = 0
[22:52] <saste> that's what makes overlay more complex
[22:52] <durandal_1707> saste: why would i need to add one (same code in overlay)?
[22:52] <durandal_1707> i used alphamerge, and it does not have this issue
[22:53] <saste> alphamerge is supposed to be used on synched inputs
[22:53] <saste> but i don't mind, that can be done on top of your patch
[22:53] <saste> ideally the synching code should be shared
[22:53] <durandal_1707> so i just add setpts?
[22:54] <saste> durandal_1707, i suppose you have this situation
[22:54] <saste> 1, 1, EOF, 2
[22:54] <saste> 1, EOF, 2
[22:54] <saste> or something like that
[22:55] <saste> when the first EOF is found, it exists
[22:55] <saste> *exits
[22:55] <saste> so you have no chance to blend the two frames
[22:55] <durandal_1707> could be
[22:56] <durandal_1707> so if EOF is found on first input but not on second i just return EAGAIN?
[22:56] <saste> setpts can't help in your case since it depends on how frames are cached on the filtergraph
[22:56] <saste> durandal_1707, the complete logic is in overlay, so that should be ideally the model to follow
[22:57] <saste> see if nicolas wants to help, since he proposed to write common utilities for input synching
[22:59] Action: llogan should have picked a less generic name
[23:16] <cone-841> ffmpeg.git 03Michael Niedermayer 07master:a5153b1d1692: shorten: Fix signedness of comparission
[23:39] <wm4> how do you force a video codec with ffplay?
[23:41] <saste> wm4: -vcodec?
[23:41] <wm4> Unrecognized option 'vcodec'
[23:41] <wm4> Failed to set value 'h264' for option 'vcodec'
[23:41] <wm4> I tried that first
[23:46] <michaelni> wm4 -codec:v h264
[23:53] <wm4> runtime CPU detection is enabled by default, right?
[23:54] <BBB-work> not for libpostproc I think
[23:55] <BBB-work> then again, libpostproc...
[23:55] <wm4> yeah, nobody cares about libpostproc
[23:55] <wm4> and isn't it full of 2001 code anyway?
[23:58] <saste> wm4, how old is your ffplay?
[23:58] <wm4> saste: oh, that's the distro version, probably a bit older
[23:59] <saste> -vcodec should work, i fixed it some months ago
[23:59] <wm4> yeah, it works with the git version
[00:00] --- Wed Feb 20 2013