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

[burek]

[00:00] <BBB> ubitux: what is that memset supposed to fix?
[00:01] <ubitux> filtering_video.c as well it seems...
[00:01] <ubitux> BBB: uninitialized read
[00:01] <BBB> in h264?
[00:01] <ubitux> no no
[00:01] <ubitux> showspectrum
[00:01] <ubitux> video filter
[00:01] <BBB> hm... I really don't think the memset is the right fix
[00:01] <ubitux> it's the last commit i pushed
[00:01] <BBB> it's a workaround for something else
[00:01] <BBB> or for h264, you're working around a bug in valgrind
[00:02] <ubitux> it's a source filter
[00:02] <ubitux> i need a writable black video buffer
[00:02] <ubitux> at first
[00:02] <BBB> hm...
[00:02] <BBB> ok if it's a source ir's something else
[00:02] <ubitux> i don't know about h264
[00:02] <BBB> just make sure to not introduce hacks like that in lavc or generic functions
[00:02] <BBB> I know it fixes valgrind warnings, but valgrind is factually wrong here, and it makes code slower
[00:02] <ubitux> i wouldn't do that without a review
[00:09] <ubitux> michaelni: mmh is that worth doing the change?
[00:09] <ubitux> wait what broke here..
[00:09] <ubitux>     Change ffmpeg to call the new API function instead of the
[00:09] <ubitux>     function in the old API with the same name.
[00:09] <ubitux> oh... i see..
[00:11] <ubitux> michaelni: i'm going to push a patch in a moment to add to the merge commit
[00:11] <ubitux> (the doc examples thing)
[00:17] <ubitux> michaelni: av_frame_alloc() and its local get_frame_defaults() differ from avcodec_alloc_frame()/avcodec_get_frame_defaults()
[00:17] <ubitux> i think we need to port our changes from lavc to lavu
[00:17] <ubitux> (and why aren't they deprecated btw?)
[00:19] <ubitux>     av_frame_set_best_effort_timestamp(frame, AV_NOPTS_VALUE);
[00:19] <ubitux>     av_frame_set_pkt_duration         (frame, 0);
[00:19] <ubitux>     av_frame_set_pkt_pos              (frame, -1);
[00:19] <ubitux>     av_frame_set_pkt_size             (frame, -1);
[00:19] <ubitux> i think this is needed
[00:19] <michaelni> ubitux, dont hesitate to port them
[00:20] <ubitux> and eventually frame->extended_data = NULL;
[00:20] <ubitux> yes but i'm not sure of the consequences since i don't know why they were added in the first place
[00:21] <michaelni> the defaults above look safe to use as defaults
[00:22] <ubitux> i wonder how we are supposed to reset a AVFrame now without an exported get_frame_defaults
[00:23] <ubitux> this si a bit schyzophrenic
[00:23] <j-b> is Robert Kruger around?
[00:24] <ubitux> michaelni: also, we have a note in avcodec_get_frame_defaults() about the extended_data thing; what should we do about it?
[00:26] <michaelni> ubitux, dunno
[00:27] <ubitux> i have no idea what it's about :)
[00:27] <ubitux> [libav-devel] [PATCH 5/6] lavr: add libsoxr resampler
[00:27] <ubitux> lol
[00:27] <ubitux> this is getting ridiculous
[00:28] <michaelni> ubitux, the comment just means that extended_data should be explicity freed and not impliciuty be a set_defaults function
[00:29] <michaelni> its unsafe because the check of content == the structs own address
[00:29] <michaelni> if a struct is moved an then defaulted something rather bad can happen IIRC
[00:33] <ubitux> ok
[00:37] <ubitux> michaelni: added 2 commits
[00:37] <ubitux> (in my local branch)
[00:40] <ubitux> michaelni: that revert looks strange :p
[00:40] <ubitux> actually, the original commit looks badly picked
[00:42] <michaelni> well only thing it did for me was break a file
[00:45] <BBB> michaelni: any preference where I put ff_init_scantable_permutation and ff_init_scantable? they are currently stuck in dsputil but should perhaps be somewhere more generic
[00:47] <ubitux> michaelni: i mean the commit message is wrong
[00:47] <ubitux> the real commit was aec50f79e7460340a148a3096fe212d67edc2c64
[00:47] <ubitux> which is harmless
[00:48] <ubitux> michaelni: it looks like kind of a code remove from cc5dd632cecc5114717d0b90f8c2be162b1c6ee8
[00:49] <michaelni> ubitux, pushed your 2 commits
[00:49] <ubitux> which doesn't look good
[00:50] <saste> j-b: not on irc i think
[00:51] <michaelni> ubitux, is there some needed check lost ?
[00:51] <michaelni> BBB, dunno where to put it, pick what makes sense to you
[00:52] <michaelni> ubitux, saste id like to start squashing and then pushing
[00:52] <ubitux> michaelni: it seems to
[00:52] <ubitux> at least that change doesn't look trivial
[00:52] <ubitux> and if you remove that code, please fix the commit message
[00:53] <michaelni> the code was added by Cigaes after the merge and i removed it as it broke that file
[00:53] <ubitux> oh, that's why the commit is broken ok
[00:54] <ubitux> forget it then
[00:54] <ubitux> michaelni: anyway yes sure, feel free to squash
[00:54] <ubitux> (just don't do it for the two last hue patches)
[00:54] <ubitux> and feel free to update my proposed commit description
[00:55] Action: ubitux is reading for the next round
[00:55] <ubitux> ready*
[00:55] <michaelni> hmm 102 commits 
[00:55] <ubitux> :D
[00:55] <michaelni> it feels wrong to sqush all that
[00:56] <ubitux> the original commit was wrong
[00:56] <michaelni> yes
[00:56] <ubitux> there is not much to do about it unless you want a broken state
[00:56] <ubitux> let's not make git bisect more complicated than it already is..
[00:56] <ubitux> so squash them, and make sure the description is good enough
[00:57] <ubitux> mark as much info as you can in it
[00:57] <michaelni> Iam not good at commit messages
[00:58] <ubitux> i've pasted you a template :))
[00:58] <ubitux> just copy/paste and add stuff
[00:58] <ubitux> i can read again after if you want
[00:58] <michaelni> copy & paste i can, add is harder
[00:59] <michaelni> which hue commits should be left out ?
[00:59] <michaelni> left seperate
[01:00] <michaelni> hue: add an optimized direct path
[01:00] <michaelni> and reindent ?
[01:00] <michaelni> ubitux, ?
[01:00] <ubitux> yes
[01:00] <michaelni> ok
[01:00] <ubitux> optimized path and reindent left aside
[01:00] <ubitux> michaelni: you can just trash them if it's problematic
[01:00] <ubitux> i can push them on top again later
[01:26] <cone-370> ffmpeg.git 03Nicolas George 07master:d1b456b0a80a: lavu/frame: copy the channels field.
[01:26] <cone-370> ffmpeg.git 03Clément BSsch 07master:586ae70ba78e: port FFmpeg lavc frame specificities to lavu functions.
[01:37] <michaelni> ubitux, http://pastie.org/private/8tze0nsmradbomsbhn2txq (this is all copy & pasted) some commits not squashed like rawdec changed 
[01:38] <Daemon404> thats a lot of stuff!
[01:38] <ubitux> michaelni: my commit descriptions are not relevant anymore
[01:38] <ubitux> you can drop all these commit messages imo
[01:38] <michaelni> ok, will drop the whole list of commit messages
[02:03] <cone-370> ffmpeg.git 03Anton Khirnov 07master:7e350379f87e: lavfi: switch to AVFrame.
[02:03] <cone-370> ffmpeg.git 03Michael Niedermayer 07master:a05a44e205d6: Merge commit '7e350379f87e7f74420b4813170fe808e2313911'
[02:03] <cone-370> ffmpeg.git 03Nicolas George 07master:6184fa2067cc: rawdec: work with refcounted frames.
[02:03] <cone-370> ffmpeg.git 03Nicolas George 07master:9cc02101ff6d: lavc/rawdec: set field order on decoded frame.
[02:03] <cone-370> ffmpeg.git 03Nicolas George 07master:4e7c61b7a722: ffmpeg: do not give away our reference to the frame.
[02:03] <cone-370> ffmpeg.git 03Michael Niedermayer 07master:b1b506bc5609: fate: disable sub2video
[02:03] <cone-370> ffmpeg.git 03Clément BSsch 07master:5e4bc96415e1: doc: fix examples.
[02:03] <ubitux> nice.
[02:04] <ubitux> michaelni: poke me whenever there are some large amount of changes to do in the following commits 
[02:05] <michaelni> ubitux, ok, btw you need to push your 2 hue commits 
[02:05] <ubitux> ok
[02:05] <ubitux> will do
[02:06] <ubitux> i have a little quick-patch todo list pending about stuff i came accross while doing this work
[02:06] <ubitux> will push on master in the next minutes/hours
[02:07] <cone-370> ffmpeg.git 03Clément BSsch 07master:e53061154f42: lavu/frame: fix not/note typo in doxy.
[02:10] <ubitux> michaelni: buffersink.c broken
[02:10] <ubitux> (not compiled anymore?)
[02:11] <cone-370> ffmpeg.git 03Anton Khirnov 07master:6e7b50b42701: mpegvideo_enc: drop support for reusing the input motion vectors.
[02:11] <cone-370> ffmpeg.git 03Michael Niedermayer 07master:4a62f477ea84: Merge commit '6e7b50b4270116ded8b874d76cb7c5b1a0341827'
[02:13] <cone-370> ffmpeg.git 03Clément BSsch 07master:3da54858d36c: lavfi/hue: add an optimized direct path.
[02:13] <cone-370> ffmpeg.git 03Clément BSsch 07master:f0a5f71074d9: lavfi/hue: reindent.
[02:13] <michaelni> ubitux, i think nicolas disabled them
[02:14] <michaelni> "lavfi: disable buffersinks from the fork." <-- this i think
[02:14] <ubitux> did you look at the file?
[02:15] <ubitux> Cigaes: ping when you have a moment
[02:15] <michaelni> ubitux, i just now looked ...
[02:19] <michaelni> there are also some filters left that use deprecated .min_perms
[02:19] <ubitux> ok
[02:19] <ubitux> going to look at them
[02:19] <michaelni> and rej_perms
[02:19] <ubitux> mmh
[02:22] <ubitux> i wonder if that's why we have less references
[02:22] <ubitux> the ref count might be higher in libav because of more "needs_writable" all over
[02:23] <ubitux> going to look into this
[02:23] <cone-370> ffmpeg.git 03Carl Eugen Hoyos 07master:3f78f0904bfa: Revert "build: disable iconv by default."
[02:23] <cone-370> ffmpeg.git 03Michael Niedermayer 07master:07ab8d3369b2: Merge remote-tracking branch 'cehoyos/master'
[02:32] <ubitux> michaelni: http://b.pkh.me/0001-lavfi-remove-remaining-forgotten-min-rej-perms.patch
[02:32] <ubitux> comments?
[02:33] <ubitux> doc/filter_design.txt will need some updates again btw
[02:35] <cone-370> ffmpeg.git 03Michael Niedermayer 07master:806a66fd08a3: mpegts: clear avprograms only for removed programs
[02:37] <michaelni> ubitux, LGTM, at least not worse than before
[02:38] <cone-370> ffmpeg.git 03Clément BSsch 07master:96e4b00d62ac: lavfi: remove remaining forgotten min/rej perms.
[02:48] <ubitux> michaelni: shouldn't we introduce a new version in git/master:Changelog?
[02:52] <michaelni> ubitux, yes
[02:52] <michaelni> want to do it or shoudl i ?
[02:53] <ubitux> i'd like to push vf curves actually
[02:53] <ubitux> so i can do it while adding the entry
[02:53] <michaelni> ok
[02:54] <ubitux> a lavfi bump might have been wise btw
[02:57] <cone-370> ffmpeg.git 03Ronald S. Bultje 07master:d5efa84f13d3: vp3: embed idct_permutation array directly in VP3DecoderContext.
[02:57] <cone-370> ffmpeg.git 03Michael Niedermayer 07master:108434a30c70: sink_buffer: remove unused variables
[02:58] <michaelni> ubitux, yes, feel free to bumo
[02:58] <michaelni> bumP
[02:58] <ubitux> minor?
[02:58] <michaelni> yes
[03:01] <cone-370> ffmpeg.git 03Clément BSsch 07master:3d813e7ec373: lavfi: bump minor version after the first round of evil changes.
[03:01] <cone-370> ffmpeg.git 03Clément BSsch 07master:65fc80f0121d: lavfi: add curves filter.
[03:33] <ubitux> http://stackoverflow.com/questions/9477115/who-can-tell-me-the-difference-and-relation-between-ffmpeg-libav-and-avconv/9477756#9477756  can someone on stackoverlay tell the guy he broke every links in the text while adding the picture?
[09:56] <cone-91> ffmpeg.git 03Carl Eugen Hoyos 07release/1.2:0b198e38c52c: Revert "build: disable iconv by default."
[09:56] <cone-91> ffmpeg.git 03Michael Niedermayer 07release/1.2:0ec869527c13: mpegts: clear avprograms only for removed programs
[10:08] <cone-91> ffmpeg.git 03Michael Niedermayer 07release/1.1:d84c51904cad: mpegts: clear avprograms only for removed programs
[10:56] <cone-91> ffmpeg.git 03Xi Wang 07master:969e8d35b5b4: lavfi/pad: avoid buffer overflow in buffer_needs_copy()
[11:14] <cone-91> ffmpeg.git 03Fabrizio Gennari 07master:91b747ac7821: mem: Fix usage of memalign() on DJGPP.
[11:14] <cehoyos> michaelni: Thank you!
[11:27] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:f963c77856d2: avfilter: avoid direct access to "frame"->channels
[11:31] <saste> michaelni, why is PRINT_LIB_INFO(avresample,...) commented in cmdutils?
[11:38] <michaelni> hmm dont remember maybe it was a quick fix for compilation failure and i forgot to put a proper ifdef
[11:39] <saste> michaelni, the #ifdef should be automatically added by PRINT_LIB_INFO
[11:40] <saste> will test and send a patch if it works
[12:28] <cehoyos> saste: I honestly don't want to start new flames but isn't "a complete overhaul of boolean docs is probably overkill" exactly my point? And what makes stats different from the other boolean options?
[12:29] <saste> cehoyos, it's enabled by default
[12:29] <saste> so you need to know that you have to prefix it with "no" in order to disable it
[12:29] <saste> the other boolean option enabled by default is stdin, and we mention "nostdin" in the docs
[12:32] <cehoyos> Thank you for clarifying! Patch ok imo.
[12:33] <saste> cehoyos, allright, i'll push it soon then (and close the ticket)
[12:40] <cehoyos> In case anybody is using GStreamer, please consider to friendly push this patch: https://bugzilla.gnome.org/show_bug.cgi?id=694937
[12:45] <saste> does someone know why gstreamer choosed to drop ffmpeg in favor of libav?
[12:45] <saste> i mean, there are technical reason or is just politics?
[12:48] <michaelni> saste, IIRC i asked 2 gstreamer developers but never got a reply
[13:16] <ubitux> hey.
[13:17] <saste> ubitux, the day after the mergestorm
[13:17] <ubitux> it's not done afaik
[13:17] <ubitux> i mean not complete
[13:17] <saste> ubitux, i know
[13:18] <saste> all the libavcodec part still missing
[13:18] <ubitux> saste: btw, news on eval?
[13:18] <saste> as for lavfi, anything missing?
[13:18] <ubitux> not that i know of
[13:18] <ubitux> testing maybe
[13:18] <saste> ubitux, i was waiting for the sea to get calm
[13:18] <ubitux> saste: i thought about the limited is const thing
[13:19] <ubitux> if it doesn't trigger the const in overlay that's not important since there is currently no optimized path
[13:19] <ubitux> (the slowdown will only be more eval calls)
[13:19] <ubitux> for volume though, it will allow to enable the optims
[13:19] <saste> ubitux, what about the evalonce thing?
[13:19] <ubitux> in most cases
[13:20] <ubitux> yes sure, it's fine with me as well
[13:29] <Cigaes> saste: for lavfi, the buffersrc flags are missing, but not for long.
[13:29] <saste> Cigaes, let me know how i can help in case
[13:31] <ubitux> Cigaes: do you plan to do something about lavfi/buffersink.c?
[13:31] <Cigaes> saste: I am almost done.
[13:32] <Cigaes> ubitux: probably just replace it by sink_buffer.c; I have to check and optimize the differences.
[13:32] <ubitux> there are some merge conflicts in it
[13:32] <ubitux> that's why i'm asking :p
[13:40] <saste> ubitux, i don't like programs which ask questions
[13:41] <ubitux> that's a suggestive question ;)
[13:42] <saste> ubitux, do you mind if i push the patch in its actual form?
[13:42] <saste> then you can propose further tweaks
[13:42] <michaelni> btw Ticket1031 is back i think since the lavfi merge
[13:43] <ubitux> saste: sure whatever, that's completely trivial
[13:44] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:dae76e8c4730: lavc/utils: fix typo and reword message in case of too low bitrate
[13:44] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:606efe18be0b: lavfi/unsharp: add missing option flags
[13:44] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:daf6ea5d4e82: cmdutils: fix stylenits
[13:44] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:475c090af248: cmdutils: make print_all_libs_info() show libavresample version
[13:44] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:63edd2f98994: cmdutils: remove duplicated check on CONFIG_POSTPROC
[13:44] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:a2a848406f05: cmdutils: clarify log message, in case of option routed to both codec and mux/demux layer
[13:44] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:f185a040b0d5: doc/ffplay,ffmpeg: mention the corresponding negated option for -stats
[13:47] <cone-91> ffmpeg.git 03Nicolas George 07master:f9b34b8bf967: ffmpeg: port sub2video to AVFrame.
[13:54] <cone-91> ffmpeg.git 03Nicolas George 07master:cb2bd91413af: ffmpeg: add the -canvas_size option.
[14:04] <cehoyos> saste: Didn't you actually fix 2326 ? And isn't 2332 wont_fix following your argumentation?
[14:22] <saste> cehoyos, yes, possible
[14:30] <ubitux> Cigaes: any reason not to have this push thing the default?
[14:30] <nevcairiel> michaelni: whats the word on merging the lavc patch, anything we can help with again?
[14:37] <Cigaes> ubitux: what push thing?
[14:38] <ubitux> the push flag
[14:38] <ubitux> in buffersrc
[14:38] <ubitux> for compat with the fork i guess?
[14:40] <Cigaes> ubitux: there would be no problem in having the flag semantic reversed and the wrapper functions for the fork's API use the NO_PUSH version.
[14:40] <Cigaes> But it was introduced that way last summer.
[14:40] <Cigaes> I do not know if it makes a real difference in the general case.
[14:42] <ubitux> also, i'm not sure why NO_COPY and KEEP_REF should not be the same thing
[14:42] <ubitux> and actually, where they are useful at all
[14:42] <ubitux> intuitively, NO_COPY would mean just not to call av_frame_copy()
[14:43] <ubitux> which is... what keep_ref does?
[14:43] <Cigaes> ubitux: initially, NO_COPY meant to copy the actual frame data planes.
[14:43] <Cigaes> With refcounted frames, this becomes hardly necessary and should be discouraged IMHO.
[14:44] <Cigaes> (I consider the move to an uniform system of frames good in principle; I am not yet familiar enough with Anton's implementation to know if he fumbled it or not.)
[14:44] <ubitux> right, so i misunderstood the purpose of KEEP_REF then
[14:44] <Cigaes> KEEP_REF means to increment the reference count (or copy the frame planes if it is not refcounted).
[14:45] <Cigaes> Shall I make the doxy clearer?
[14:45] Action: wm4 hoped this permissions stuff would vanish
[14:45] <nevcairiel> the permission system more or less did vanish
[14:46] <nevcairiel> avframes are now either writably or not, or ref counted or not
[14:46] <nevcairiel> writable*
[14:46] <nevcairiel> (not ref counted means you cannot keep the buffer for later)
[14:47] <ubitux> Cigaes: i think i'm just confused by various things, notably because the KEEP_REF thing looks like it can be emulated with a simple av_frame_clone()
[14:48] <ubitux> and so i don't understand the purpose of having the duplicated feature in buffersrc under a flag name
[14:49] <ubitux> if the user want a copy, he can just av_buffersrc_add_frame(av_frame_clone(f))
[14:49] <ubitux> or i'm missing something?
[14:49] <Cigaes> ubitux: you are right, the KEEP_REF stuff is just convenience; just like the add/write_frame pair in the fork's API.
[14:50] <ubitux> ok well i guess i'm going to read the patches properly then
[14:51] <Cigaes> Since it is so commonly useful (look at all the avfilter_buffer_ref(ref, ~0) before the merge), I believe it is a good thing to have them properly done (including malloc failure checks!).
[14:51] <michaelni> Cigaes, your 2 patches seem to fix some number of frame regressions from yesterday so iam in favor of these 2 being commited
[14:51] <michaelni> minor regressions that is (+-1 frame stuff)
[14:52] <Cigaes> michaelni: "frame regressions": you mean the -vfames / -aframes stuff? I expected as much.
[14:52] <michaelni> yes
[14:52] <ubitux> Cigaes: ok ok
[14:52] <michaelni> i mean its more similar to pre merge with the 2 patches
[14:52] <Cigaes> (Groumpf, the H264-ES demuxer introduce a one frame latency :( )
[14:53] <Cigaes> I will leave ubitux time to finish reading them before pushing.
[14:53] <ubitux> no no it's ok
[14:53] <ubitux> don't mind me, i'm just lost becase of various things
[14:53] <nevcairiel> raw demuxers kind ahve to, because it needs to find the start of the next frame, instead of fiding the end of the current
[14:53] <ubitux> it will be simpler if i look at the final result :)
[14:55] <ubitux> Cigaes: btw, i don't know if it's related, but yesterday we realized that filters (with ffmpeg at least, with a simple -vf cmd line) get about 3 refcount in there frame->buf in the fork, while we had only one (maybe not the case anymore though)
[14:55] <michaelni> nevcairiel, if you want to help theres lots of stuff (buffer pools in lavfi where lost, some min/rej_perm left in lavfi, ticket1031 is a regerssion or you can start porting decoders to the new api in lavc, iam still working at resolving conflicts)
[14:55] <ubitux> Cigaes: and having only one allowed some direct path in filters, which was... nice.
[14:56] <ubitux> it might be interesting to have a look after everything is merged properly
[14:57] <Cigaes> ubitux: yes, I read that in the backlog of my IRC client; that will be interesting indeed.
[14:58] <Cigaes> ubitux: I am currently playing with latencies, you can take some time to spot the bugs I left in my patches before they become public.
[14:58] <ubitux> michaelni: no there is no more min/rej_perm left
[14:58] <michaelni> ubitux, ohh great :)
[14:58] <ubitux> unless i'm missing some?
[14:58] <ubitux> the only one left is in doc/filter_design.txt
[14:58] <nevcairiel> easy enough to grep for
[14:58] <ubitux> but i guess that's not critic right now
[15:00] Action: ubitux wonders if the filter_frame/request_frame can be simplified at some point
[15:00] <Cigaes> I intend to update filter_design.txt once everything is settled and I am familiar enough with the new stuff.
[15:00] <Cigaes> ubitux: what kind of simplification do you have in mind?
[15:01] <ubitux> Cigaes: well, i don't know if it's theorically possible, but i find kind of convoluted the fact that filter who doesn't want to raise a frame every time needs to implement two path (filter_frame and request_frame) with internal state to keep sync between them
[15:01] <ubitux> (and this is the simplest case)
[15:02] <ubitux> while the filter could just notify with a EAGAIN when no frame are ready
[15:03] <ubitux> this leads to code not easy to follow (select, yadif, ...)
[15:03] <Cigaes> Yes, I see the point. There is also the EOF handling stuff that is not completely satisfactory.
[15:06] <ubitux> also, i think the ff_null_get_{audio,video}_buffer things are not relevant anymore since a while
[15:06] <ubitux> unless i'm missing something
[15:06] <ubitux> at least they look misused all over (partly of my fault)
[15:07] <ubitux> but i'm waiting for the merge to end before doing such thing
[15:08] <Cigaes> ubitux: I suspect vf_pad and/or vf_crop still need to be able to tweak the buffers.
[15:08] <Cigaes> Completely unrelated: is there a downside to "-flags +low_delay"?
[15:09] <ubitux> i'm not saying the get buffer callback should be removed
[15:09] <ubitux> but a lot of filters seem to define it to this ff_null thing
[15:09] <ubitux> and some other arent
[15:09] <ubitux> without any apparent logic
[15:09] <ubitux> but maybe that's because i'm completely clueless again
[15:11] <Cigaes> ubitux: the default get_video_buffer (the one used if it is not set on the pad) is to allocate a new buffer.
[15:11] <Cigaes> The null_get_video_buffer is to forward the request to the first output of the filter.
[15:12] <Cigaes> Unless I am mistaken, that means that a filter that works 1-to-1 in place, like drawtext or delogo, should use null_get_video_buffer,
[15:12] <Cigaes> and a filter that works by copying, like scale, needs the default one.
[15:13] <Cigaes> (I will think on it some more, and if I am right, I should add it to filter_design.txt.)
[15:13] <ubitux> ok :)
[15:14] <ubitux> michaelni: so you said we can start porting decoders?
[15:14] <Cigaes> But the null name is very ill chosen. "forward" or something would be much clearer.
[15:19] <michaelni> ubitux, sure all that exist in ffmpeg but not libav
[15:22] <wm4> what is swr's equivalent of avresample_close()?
[15:28] <saste> wm4: swr_free?
[15:28] <wm4> saste: no, that frees
[15:30] <ubitux> wm4: you don't need to close
[15:30] <ubitux> iirc
[15:33] <ubitux> michaelni: is there a WIP branch on which i can work on?
[15:34] <Cigaes> wm4: just look at uninit() and the EOF case in af_aresample.c.
[15:34] <ubitux> Cigaes: i think he wants to handle parameter changes
[15:34] Action: Cigaes just sent a trivial patch on nutenc.
[15:35] <ubitux> (and flushing data while doing so)
[15:35] <ubitux> but iirc swr can handle it itself
[15:35] <ubitux> well i'm not a swr expert so i don't know
[15:36] <Cigaes> ubitux: shall I push the buffersrc stuff?
[15:36] <ubitux> Cigaes: yes sure
[15:36] <wm4> now I need avresample_available()
[15:36] <ubitux> 14:53:15 < Cigaes> I will leave ubitux time to finish reading them before pushing.
[15:36] <ubitux> 14:53:22 <@ubitux> no no it's ok
[15:36] <ubitux> 14:53:36 <@ubitux> don't mind me, i'm just lost becase of various things
[15:37] <ubitux> wm4: { return 0; } ?
[15:37] <wm4> ok
[15:38] <ubitux> wm4: compare the two workflows in the doxy
[15:38] <cone-91> ffmpeg.git 03Nicolas George 07master:b0012de420f2: lavfi/buffersrc: implement flags.
[15:38] <cone-91> ffmpeg.git 03Nicolas George 07master:fb14e37dd0b6: ffmpeg: re-enable use of buffersrc flags.
[15:38] <ubitux> wm4: http://pastie.org/6442401
[15:41] <wm4> yes that's helpful
[15:49] <michaelni> ubitux, https://github.com/michaelni/FFmpeg/tree/lavc-merge-mess but there are still 187 conflicts left to be resolved from >300 
[15:49] <ubitux> ok
[15:50] <ubitux> i'm starting to work on this in 10 min
[15:57] <michaelni> fixed conflicts in headers so individual files can be compile tested
[16:00] <ubitux> nice ok
[16:03] <Cigaes> I cleaned up buffersink a bit. Now I will try to make it binary-compatible with the fork's.
[16:04] <ubitux> great :)
[16:06] <ubitux> michaelni: ok i'm taking (hopefully) easy one to get comfortable with the process, so maybe gif, fraps, and ansi conflicts
[16:12] <michaelni> ubitux, also see ffmpeg.org/~michael/murge its a tiny script into whichs stdin you can paste some conflicts and that nicely shows colored diffs for it 
[16:13] <ubitux> kawaii
[16:13] <ubitux> thx :)
[16:18] <ubitux> "Source and destination overlap in memcpy"
[16:18] <ubitux> mmh this is not good.. (valgrind fate)
[16:18] <ubitux> and some memleak
[16:19] <clkao> win 6
[16:21] <michaelni> memcpy(a,a) or a,b witdh a!= b?
[16:21] <ubitux> didn't look yet
[16:21] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20130310134201&slot=x86_64-archlinux-gcc-valgrindundef
[16:21] <ubitux> i'm looking at this
[16:21] <ubitux> memcpy(0x64dd3a0, 0x64dd3a0, 6)
[16:21] <ubitux> so memcpy(a,a)
[16:23] <ubitux> it's because of a av_copy_packet
[16:35] <nevcairiel> there, i finished my tasks and can join some fixings as well, i'll checkout the branch and get a broad overview first, let you know what i pick =p
[16:37] <cehoyos> nevcairiel: You cannot share your sample for ticket #2186 ?
[16:37] <nevcairiel> oh right i wanted to upload that
[16:37] <cehoyos> Thank you!
[16:39] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:35135a3989df: lavfi/smartblur: add support to named options
[16:45] <nevcairiel> i'll take 4xm.c to start, seems mildly complex, but shrug
[17:02] Action: ubitux wonder if he actually picked easy one
[17:02] <nevcairiel> i'm getting a headache trying to understand how reget_buffer is supposed to work
[17:03] <burek> would it be ok if we could take out the common docs sections for ffmpeg/ffplay into separate texi files? for example, "Stream specifiers", "Generic options" and such?
[17:03] <burek> because right now we have duplicate docs
[17:05] <burek> just like this thing: @include avtools-common-opts.texi
[17:05] <burek> which includes a common options text for all of ffmpeg, ffplay and ffprobe
[17:06] <burek> i mean, I could do that, i'm just asking if it's a good idea to do so
[17:18] <nevcairiel> 012v.c next for me
[17:18] <saste> burek, what's duplicated in the docs?
[17:20] <Cigaes> saste or ubitux : I know you are all busy porting lavc to refcounted frames, but I would appreciate if you took a few seconds to look at the five patches I sent concerinig sink_buffer / buffersink; three of them are very simple.
[17:21] <saste> Cigaes, i'll do (since I'm not helping with the port and i feel guilty for that)
[17:23] <Cigaes> Thanks.
[17:24] Action: ubitux doesn't feel much guilty, so he will give saste a chance to make himself feels good
[17:32] <nevcairiel> 8bps and 8svx next for me
[17:33] <nevcairiel> nvm 8bps, its apparently fien as is :p
[17:34] <nevcairiel> hm or not
[17:36] <michaelni> nevcairiel, about 4xm, are you sure you donzt need reget_buffer there ?
[17:36] <nevcairiel> i was wondering this, and i read through the whole decoder, the original frame is never read
[17:37] <nevcairiel> only written to
[17:37] <nevcairiel> (and completely overwritten, as far as i could see)
[17:40] <nevcairiel> I'm not 100% convinced however, needs testing once i can throw a file at it for visual confirmation
[17:42] <michaelni> nevcairiel, code == 3 && f->version >= 2 in decode_p_block would skip i think
[17:43] <nevcairiel> hm indeed that doesn't do anything. I'll check it out, need to understand how reget buffer is ideally used with the new system now
[17:44] <nevcairiel> just using reget buffer on the AVFrame provided to the decode call shouldnt do anything
[17:48] <ubitux> michaelni: are you working on lavc/utils?
[17:48] <ubitux> so we can start testing with limited builds
[17:48] <ubitux> right now i can only test the compile of the codec
[17:49] <saste> Cigaes, can you mark the patches that you already commited on list?
[17:49] <Cigaes> saste: the ones that need review are these:
[17:49] <Cigaes> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140274.html
[17:49] <Cigaes> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140276.html
[17:49] <Cigaes> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140275.html
[17:49] <Cigaes> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140279.html
[17:49] <Cigaes> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140283.html
[17:51] <saste> Cigaes, please mark the already pushed patches on list
[17:54] <ubitux> Cigaes: [PATCH] lavfi/buffersink: implement av_buffersink_get_samples().  you should check av_audio_fifo_read() in this one
[17:55] <ubitux> the buffersink rename patch and the merge-broken remove patches are ok
[17:55] <Cigaes> saste: there was only a pair; I just sent a mail.
[17:55] <ubitux> just make sure there are no weird dep lying around though
[17:55] <ubitux> (or various other references to the old file)
[17:57] <saste> ahhh the antonsink/ffsink mess again!
[17:57] <ubitux> -    .uninit    = vsink_uninit,
[17:57] <ubitux> +    .uninit    = uninit,
[17:57] <Cigaes> ubitux: the unchecked av_audio_fifo_read() was copied directly from libav. Since this is a compat API, matching them bug-for-bug should be correct. Also, I am pretty sure it can not fail.
[17:57] <ubitux> ok..
[17:57] <ubitux> you could keep the symbol names here
[17:57] <ubitux> it helps debug sometimes
[17:57] <ubitux> anyway, all of this are just minor nits
[17:58] <ubitux> don't consider them blocking in any way
[17:58] <Cigaes> ubitux: I did not understand your "no weird dep" remark.
[17:58] <Cigaes> ubitux: changing the names was to reduce the diff.
[17:58] <nevcairiel> michaelni: i re-did the patch with reget buffer and pushed to https://github.com/Nevcairiel/FFmpeg/tree/lavc-merge if you want to look at it again, there is also 3 other decoders ready
[17:58] <ubitux> Cigaes: sometimes in Makefile there are some object deps, that might not be the case here
[17:58] <ubitux> Cigaes: ok don't mind it then
[17:59] <Cigaes> ubitux: Ah... the sinks are enabled unconditionnally, so I guess this is good.
[18:00] <ubitux> yeah that was just a potential reference; i was also thinking to doxy ref or something, like it happens often
[18:00] <ubitux> (and is generally forgotten while renaming/moving)
[18:01] <Cigaes> I have to go away for ~1h, I will check the log afterwards.
[18:01] <ubitux> i've no more comment myself
[18:01] <michaelni> nevcairiel, merged & pushed
[18:02] <ubitux> michaelni: ansi is available, only build tested, and it's based on Anton changes, no additionnal thinking
[18:03] <ubitux> michaelni: want me to squash the two?
[18:03] <ubitux> like you guys did :p
[18:04] <ubitux> or at least like you did
[18:06] <ubitux> pushed a merged change
[18:06] <michaelni> ubitux, just pushed your 2 commits
[18:07] <ubitux> ah, ok haha
[18:07] <nevcairiel> i'll take aura and aasc, if noone has called dibs yet
[18:08] Action: ubitux will continue on fraps and gif
[18:14] <nevcairiel> next, alsdec.c
[18:15] <nevcairiel> audio decoders are always so easy, they hardly have any frame management <.<
[18:16] Action: ubitux takes note for later
[18:21] <nevcairiel> pushed another batch to github
[18:24] <nevcairiel> next: avuidec, bfi, bintext
[18:38] <saste>     *dst = *src;  if (src->extended_data == src->data)  dst->extended_data = dst->data;
[18:39] <saste> ^^ in av_frame_move_ref()
[18:39] <saste> what's the point of the assignment?
[18:39] <nevcairiel> that seems fine,  because ->data is an array, and dst->extended_data is a **
[18:39] <nevcairiel> so it needs to point to the array in the current structure
[18:40] <nevcairiel> the whole extended_data design is rather confusing
[18:43] <nevcairiel> anyhow, next: brender_pix, cinepak, cljr, cavsdec
[18:46] Action: ubitux feels so slow in comparison to the filters
[18:46] <ubitux> :D
[18:46] <nevcairiel> going from the top was a good choise, plenty easy ones there :p
[18:46] <nevcairiel> choice*
[18:46] <ubitux> :)
[18:46] Action: ubitux is trying to get a clue about the threaded release process in fraps
[18:49] <nevcairiel> fraps should be pretty straight forward
[18:49] <nevcairiel> its just intra frames
[18:49] <ubitux> yes but i'm wondering about the conditionnal release buffer (pix fmt change)
[18:49] <nevcairiel> oh that
[18:50] <nevcairiel> wait, doesnt the threaded decoder just skip the "repeat" frames instead of re-sending the previous one? that shouldnt even apply in ffmpegs variant
[18:50] <ubitux> i have no idea
[18:51] Action: ubitux is completely new to the get_buffer thing
[18:51] <nevcairiel> libavs variant is single-threaded, it re-sends the previous frame if the bitstream has a "repeat previous" flag
[18:51] <nevcairiel> however, the threaded decoder doesnt do that because of complexity issues
[18:51] <nevcairiel> so the whole pixfmt change check shouldnt be required
[18:52] <ubitux> yeah i removed it
[18:52] <ubitux> but i can't test
[18:53] <ubitux> also wtf @ sudden error: implicit declaration of function NULL_IF_CONFIG_SMALL 
[18:53] <saste> that's defined in libavutil
[18:53] <saste>  it's actually a macro
[18:53] <ubitux> yes but why did it suddenly moved?
[19:00] <michaelni> ubitux, i have utils.c compiling locally but i need a few more parts before a minimal test can be done
[19:01] <ubitux> ok
[19:03] <nevcairiel> ok pizza break, pushed a bunch more to github
[19:04] <cone-91> ffmpeg.git 03Nicolas George 07master:fa41f7ecd6e0: lavfi/sink_buffer: move stuff to reduce the diff.
[19:04] <cone-91> ffmpeg.git 03Nicolas George 07master:3add5dc88e8b: lavfi: remove buffersink.c.
[19:04] <cone-91> ffmpeg.git 03Nicolas George 07master:03b87fe5e35d: lavfi: rename sink_buffer.c into buffersink.c.
[19:04] <cone-91> ffmpeg.git 03Nicolas George 07master:b71db3f38eaf: lavfi/buffersrc: do not dereference NULL frame.
[19:12] <Cigaes> ubitux: "i've no more comment myself", was that a ok for "implement av_buffersink_get_samples()."?
[19:13] <saste> Cigaes, i'm having a look at it right now
[19:13] <saste> it's taking time because i'm trying to get acquainted with the new API
[19:14] <Cigaes> No problem. It has a few confusing aspects indeed.
[19:17] <michaelni> ubitux, minimal build works (tested with huffyuv + ffplay)
[19:17] <ubitux> Cigaes: it looks ok from my PoV, but i looked very fast
[19:17] <ubitux> michaelni: cool, thx
[19:21] <ubitux> so, is it ok to change avctx->pix_fmt (sometimes), and call ff_thread_get_buffer() without any unref or magic stuff?
[19:24] <nevcairiel> i believe so, its just important when you have reference frames
[19:24] <nevcairiel> to ensure they are the same pixfmt
[19:26] <ubitux> ok
[19:26] <ubitux> cool then
[19:28] <michaelni> nevcairiel, rebased and pushed your commits
[19:28] <michaelni> 122 conflicts left
[19:38] <ubitux> pfiou finally able to test fate-ansi
[19:38] <ubitux> (and it works)
[19:38] <ubitux> + valgrind happy
[19:42] <cone-91> ffmpeg.git 03Nicolas George 07master:de54a96aa8f5: lavfi/buffersink: implement av_buffersink_get_samples().
[19:44] <ubitux> am i the only one to have to fix all the NULL_IF_CONFIG_SMALL thing?
[19:45] <ubitux> or there is a header broken somewhere?
[19:48] <nevcairiel> i havent encounterd any such issues
[19:49] <ubitux> nevcairiel: make libavcodec/gif.o  does this work for you?
[19:50] <nevcairiel> yes
[19:50] <ubitux> ok so i fucked up something
[20:02] <Cigaes> Another round of cosmetics on buffersink posted on the ML, but there is no rush since I must be leaving for today.
[20:02] <Cigaes> Good luck with the merge and thanks.
[20:02] <ubitux> you can commit cosmetics right away i believe :p
[20:03] <ubitux> thanks for your work on buffer sink/src :)
[20:08] <cehoyos> ubitux: Usually the error means you have a problem with the build falgs
[20:08] <cehoyos> flags (HAVE_CONFIG_H)
[20:11] <ubitux> it's ok i've just messed up something between diff
[20:14] <nevcairiel> hm getting fate running is still a bit complicated, need to figure out a working configure or mess around in config.h myself =p
[20:15] <ubitux> yes it's a pain to select all the necessary deps :p
[20:17] <nevcairiel> apparently --disable-decoders --disable-encoders --enable-decoder=fourxm doesn't really disable all decoders
[20:21] <ubitux> any idea what is the point of AV_GET_BUFFER_FLAG_REF since the decoder can just av_frame_ref()?
[20:22] <nevcairiel> the flag is actually not even used in the default implementation of get_buffer2, but i assume its just to give the flexibility to inform that callback that its a more persistent buffer is being allocated
[20:23] <nevcairiel> i wondered about it myself, and looked for the implementation, it just ignores it, but yeah, i guess it just has informative purposes
[20:23] <nevcairiel> whenever you keep a frame, you need to ref it anyway
[20:52] <wm4> is there a simple way to know what's the output size of a filter graph (using "buffersink" like ffplay), or do I have to manually traverse the pad data structures of the sink filter?
[20:54] <ubitux> i see code like: init(){ s->frame = av_frame_alloc(); } and decode(){ av_frame_unref(s->frame); /* change avctx parameters */ ff_get_buffer(avctx, &s->frame); }
[20:54] <ubitux> why not a simple reget?
[20:54] <ubitux> (to avoid a copy of the content?)
[20:55] <nevcairiel> not sure reget supports changing stuff like the pixfmt or dimensions
[20:55] <nevcairiel> if thats whats being changed there
[20:55] <ubitux> wait, but you said you believed it worked with the threaded version
[20:56] <nevcairiel> reget cant be used threaded
[20:56] <ubitux> ah right, it was a get
[20:56] <nevcairiel> hm
[20:56] <nevcairiel> my 4xm output changed in fate
[20:56] <nevcairiel> :(
[20:56] <ubitux> and not on a local one, i see
[20:57] <ubitux> ok i think i start to get a bit the process
[21:02] <michaelni> 100 conflicts left
[21:18] <michaelni> nevcairiel, what did change with 4xm ? 
[21:18] <nevcairiel> 4xm is more weird than i expected, it seems to use the two most recent frames to reconstruct the old ones, that explains why the code broke :d
[21:18] <nevcairiel> but i fixed it
[21:18] <michaelni> :)
[21:18] <nevcairiel> fate test now works
[21:18] <michaelni> \o/
[21:18] <nevcairiel> i wonder how the libav version could ever work
[21:18] <nevcairiel> but shrug
[21:19] <nevcairiel> sheer luck probably
[21:20] <nevcairiel> ok on to test the others i commited earlier
[21:23] <ubitux> does the pict_type have any effect on post processing the frame data or its references?
[21:27] <nevcairiel> dont think so
[21:30] <ubitux> mmh the gif decoder has a bug
[21:31] <ubitux> or might be...
[21:32] Action: ubitux wonders if it's useful/correct to set the pts/duration/etc of the frame
[21:35] <wm4> ubitux: actually I spotted some gifs that were decoded incorrectly, but it's been some time and I have no sample
[21:36] <ubitux> michaelni: i've pushed gifdec and fraps, still not tested, but build ok
[21:36] <BBB> nevcairiel: a lot of things aren't tested by fate, just be aware by that - so "why does it work" is often not answered by fate
[21:36] <BBB> nevcairiel: case in point, svq3 b-frames
[21:36] <BBB> which was kind of hilarious
[21:37] <ubitux> wm4: large changes got in "recently"
[21:37] <wm4> I mean animated gifs
[21:37] <wm4> so even before TEP there might have been bugs
[21:39] <ubitux> ok
[21:40] <ubitux> i was refering to the decoder changes, notably the animated ones
[21:40] <ubitux> someone (a certain dave iirc?) reported various broken gif
[21:40] <ubitux> i think paul fixed them and added fate tests
[21:40] <cehoyos> Yes, I believe gif was fixed
[21:41] <ubitux> wm4: if you still have some broken samples, they are of course welcome
[21:41] <ubitux> ok so anyway, what decoders should i pick now..
[21:42] <ubitux> anyone on cyuv?
[21:42] <ubitux> michaelni? nevcairiel?
[21:42] <nevcairiel> i was looking at cyuv, but the damn thing is crashin when running
[21:43] <ubitux> ok
[21:43] <michaelni> mpeg1/2 fate working
[21:44] Action: ubitux resolving conflicts on dsicinav
[21:44] <ubitux> (no one on this one?)
[21:46] <nevcairiel> not me
[21:47] <ubitux> ok, pushed
[21:48] Action: ubitux looking at scm
[21:48] <ubitux> smc*
[21:48] <nevcairiel> hrm gdb isnt being in a helpful mood today
[21:50] <nevcairiel> cyuv is such a short decoder, why cant gdb just work with me here
[21:53] <ubitux> smc pushed
[21:55] <ubitux> anyone on iff?
[21:55] <nevcairiel> i did that one
[21:55] <ubitux> oh ok
[21:55] <ubitux> seems michael didn't push it yet
[21:55] <nevcairiel> maybe i didnt
[21:55] Action: nevcairiel checks
[21:56] <nevcairiel> i'm beginning to think my crash is a compilation problem
[21:56] <ubitux> zmbv, anyone?
[21:56] <nevcairiel> i better clean and start over
[22:00] <michaelni> nevcairiel, merged & pushed
[22:01] Action: ubitux on zmbv
[22:08] <ubitux> michaelni: you can merge my branch anytime btw
[22:09] <ubitux> i plan to do more advanced testing on gif and fraps at the end
[22:09] <nevcairiel> fraps needs the pthread code to be fixed first
[22:10] <ubitux> nevcairiel: yes :)
[22:10] Action: ubitux on rpza
[22:11] <michaelni> nevcairiel, i have pthreads converted but theres an assertian failre still
[22:12] Action: ubitux on vble
[22:15] <nevcairiel> i cant figure out why some decoders decide to crash in some internal buffer pool management in avutil, and some that don't do anything different simply work <.<
[22:18] Action: ubitux on xxan
[22:19] Action: ubitux on targa
[22:19] <michaelni> ubitux, merged & pushed
[22:20] <ubitux> thx
[22:25] Action: ubitux on vmnc
[22:26] Action: ubitux on utvideo
[22:28] Action: ubitux on tscc
[22:29] <nevcairiel> screw this, now i build everything with full debugging and without optimizations, and it doesnt crash anymore
[22:29] <nevcairiel> this is killing me
[22:30] <JEEB> yeah, that sucks
[22:30] <nevcairiel> if anyone can, can you run fate-cyuv and see if it works ? :d
[22:30] <nevcairiel> with my debug build it now passes =P
[22:33] <ubitux> i'll do some testing when all the conflicts are resolved
[22:33] <ubitux> (simpler for compilation)
[22:33] <ubitux> otherwise it's a real pain
[22:34] <ubitux> nevcairiel: maybe something in the internals has a problem so..
[22:34] <ubitux> you'd better wait to see if other codecs have the same issues
[22:34] <nevcairiel> apparently cavs does as well
[22:35] <nevcairiel> it also worked with my debug build now
[22:36] Action: ubitux on ulti
[22:37] Action: ubitux on ffv1dec
[22:39] <ubitux> michaelni: you can merge
[22:39] <michaelni> pthreads.c builds
[22:39] Action: ubitux on dnxhddec
[22:40] <michaelni> and mpeg1/2 vsynth fate still works with THREADS=4
[22:44] <michaelni> ubitux, merged & pushed
[22:47] Action: ubitux on v210dec
[22:53] Action: ubitux on vp3
[22:54] <nevcairiel> seems like you got the hang of it
[22:55] <ubitux> these were easy
[22:55] <ubitux> vp3 is not trivial at all thought
[22:55] <ubitux> i might get stucked in it for a while
[22:55] <ubitux> michaelni: you can merge again
[22:55] <ubitux> my branch won't be updated for a while i think :p
[22:55] <nevcairiel> i think i figured my problem out, mixing win32 intrinsics and gcc might have not been the best choice
[22:56] <nevcairiel> thats what i get for working in mingw :p
[22:56] <ubitux> haha
[22:56] <nevcairiel> curious that libav fate didnt find any issues though
[22:57] Action: nevcairiel wonders if they have any native-windows fate, or only wine
[22:57] <ubitux> maybe their build is all broken and disable all asm sometimes
[22:57] <nevcairiel> ha it worked
[22:58] Action: ubitux note that this is still the case in some parts since months (1year+?) and they still didn't realize it
[23:00] <burek> saste, well i mentioned what's duplicated
[23:00] <burek> if you take a look at the html docs you'll just confirm it
[23:03] <michaelni> ubitux, meregd & pushed
[23:03] Action: michaelni is working on snow
[23:07] <ubitux> michaelni: if you merge http://lists.libav.org/pipermail/libav-devel/2013-March/044493.html and http://lists.libav.org/pipermail/libav-devel/2013-March/044492.html, make sure you revert http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=a3554bb45737d1c55daa9dfa516069b2fd157cd6 and http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=9e1914dfbafb59b424a7c06cfdd324a85c33ef44
[23:07] <ubitux> (yes this is trivial, but just in case..)
[23:08] <nevcairiel> ok now that it stopped crashing and i submitted a fix to anton, i can finally resume
[23:09] <ubitux> :)
[23:29] <nevcairiel> pushed a bunch more decoders
[23:49] <michaelni> nevcairiel, merged & pushed
[23:49] <wm4> ubitux: lol, have you seen "[MPlayer-dev-eng] [PATCH] demuxer info codepage"
[23:49] <wm4> ubitux: I wonder if that's a problem with libavformat, or if mplayer's internal audio demuxer actually reads ID3...
[23:49] <michaelni> snow pushed too, still sizeof(AVFrame) dependant though
[23:56] <ubitux> wm4: ergl
[23:56] <ubitux> fun.
[00:00] --- Mon Mar 11 2013