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

[burek]

[00:00] <fatpony> done :)
[00:00] <fatpony> i don't understand why there is only one linux tool that is able to do that, closed-source what's more
[00:02] <ubitux> it seems we're going to propose such task for the coming GSoC
[00:02] <ubitux> in case you're interested
[00:05] <fatpony> i'll probably be too lazy to participate
[00:05] <ubitux> you might have to wait for the feature for a while then ;)
[00:05] <fatpony> i'll cowardly wait for someone to add the feature heh
[00:06] <fatpony> yeah my plan exactly
[00:07] <llogan> fatpony: you can get paid
[00:07] <saste> fatpony, you can pay someone
[00:07] <fatpony> lol
[00:07] <ubitux> :)
[00:07] <fatpony> i'm sure it would be interesting to work on ffmpeg
[00:08] <llogan> i need to make a better intro for the gsoc page... i feel that's the weakest part so far. someone kick me if i forget.
[00:08] <fatpony> but i've already got a job and i like it when all i have to write are scripts to automate, not features to existing projects
[00:09] Action: JEEBsv kind of would like to try GSoC this year as well, with ffmpeg
[00:09] <fatpony> i haven't even seen that gsoc page
[00:09] <saste> JEEB, as mentor?
[00:09] <JEEBsv> as a student I guess :)
[00:10] <saste> mmh ok
[00:10] <ubitux> JEEBsv: what would you like to work on?
[00:10] <fatpony> oh gsoc is for students, that's what i thought
[00:10] <fatpony> i'll no longer be a student this summer
[00:10] <fatpony> well almost
[00:10] <JEEBsv> ubitux: not fully sure yet. I did libavcodec encoding last year
[00:11] <JEEBsv> I wanna get one patchset in first, which I've been meaning to go through and update to current APIs tho
[00:11] <JEEBsv> a guy made a patchset for EarthSoft DV
[00:12] <JEEBsv> I still have some clips in that format so I kind of would like to see that get in one day
[00:12] <JEEBsv> (unrelated to GSoC, wanted to do that for a long time now)
[00:12] <fatpony> ubitux: i guess there's nothing stopping me from developping that bistream filter by myself in my spare time ... i was told it wasn't probably too complicated
[00:13] <JEEBsv> fatpony: yeah -- there are specs available now
[00:13] <JEEBsv> and parsing the normal DTS core should already be pretty much done somewhere in libavformat/-codec
[00:15] <ubitux> fatpony: go for it
[00:15] <ubitux> fatpony: you should say it in the ticket if you do so
[00:15] <ubitux> in case some ninja from the shadow is already doing it secretly
[00:15] <fatpony> oh right
[00:16] <fatpony> i haven't begun yet
[00:16] <fatpony> it could take weeks before i actually begin heh
[00:17] <fatpony> on an unrelated note, what is avconv exactly? just a fork from the ffmpeg encoder? who is working on it?
[00:20] <fatpony> hmm ok thanks
[00:20] <llogan> maybe the fork link should point to ffmpeg/libav situation. the SO link is mostly concerned with the shitty user-confusing messages
[00:21] <fatpony> it does point to the reply llogan if that's what you're asking
[00:21] <fatpony> oh right there's a link in it
[00:21] <llogan> i don't know what i'm asking. they are both good.
[00:23] <Compn> i like ubitux's big post on it :)
[00:23] <ubitux> this stackoverflow references it, and is more neutral
[00:23] <ubitux> so i believe it's better
[00:23] <ubitux> also, it focus on the main issue
[00:23] <ubitux> the ffmpeg deprecated lie
[00:24] <ubitux> please keep this link
[00:24] <llogan> also...bizarro superman
[00:25] <relaxed> Not to split hairs, but the "ffmpeg is deprecated" was referring to the ffmpeg binary in libav.
[00:33] <llogan> relaxed: don't get me started
[00:33] <ubitux> :)
[00:50] <llogan> JEEBsv: if you think of an idea you'd like to work on (or if you like any in the ideas page) please let us know. organization apps open march 18 and deadline is march 29.
[00:50] <llogan> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013
[00:50] <ubitux> what are the organization apps?
[00:51] Action: ubitux should read a bit about the gsoc process...
[00:52] <llogan> Mentoring organizations can begin submitting applications to Google.
[00:52] <llogan> on 18 march
[01:05] <cone-732> ffmpeg.git 03Michael Niedermayer 07release/1.2:2ed7f5a6700b: Changelog: update version
[01:05] <cone-732> ffmpeg.git 03Michael Niedermayer 07release/1.2:17911d0a96a8: release_notes: update
[01:05] <cone-732> ffmpeg.git 03Fabrizio Gennari 07release/1.2:e820e3a2591a: mem: Fix usage of memalign() on DJGPP.
[01:44] <cone-732> ffmpeg.git 03Clément BSsch 07fatal: ambiguous argument 'refs/tags/n1.2': unknown revision or path not in the working tree.
[01:44] <cone-732> Use '--' to separate paths from revisions
[01:44] <cone-732> refs/tags/n1.2:HEAD: lavf/avio: fix two extreemly unreasonble typos.
[01:46] <ubitux> michaelni: did you report this bug to thresh?
[01:49] <michaelni> thats a good question
[01:49] <michaelni> i dont remember
[01:49] <michaelni> i think i did mention it to someone from vlc somewhere but iam not sure
[01:54] <ubitux> how to reproduce?
[01:56] <michaelni> ubitux, the bug ? push a tag (but not to ffmpeg main git please ;) )
[01:58] <ubitux> i was just asking for the report i'm going to do to him :p
[01:58] <ubitux> "report" = whine in pv on irc
[02:17] <ubitux> michaelni: every 3 monthS?
[02:17] <ubitux> (i'm not a native speaker, that's a real question)
[02:25] <llogan> "months" is better.
[02:33] <michaelni> fixed locally
[02:33] <ubitux> (both are allowed?)
[02:33] <ubitux> michaelni: about the patch itself, you're doing the releases, so i guess the patch is ok
[02:35] <cone-732> ffmpeg.git 03Clément BSsch 07master:db670e536632: lavfi/ebur128: add framelog option.
[02:38] <michaelni> ubitux, yes sure but iam not sure its optimally worded
[02:39] <michaelni> for example "FFmpeg makes a new major release" sounds a bit odd to me but that was approximately how it was worded before
[02:40] <ubitux> ok, i can't really tell
[02:44] <michaelni> no ? it sounds ok to you that ffmpeg does something ?
[02:44] <michaelni> i mean it transcodes files ok
[02:44] <ubitux> it also makes life
[02:44] <michaelni> ./ffmpeg -make "new release"
[02:45] <ubitux> maybe "The FFmpeg project"
[02:45] <ubitux> or make the major release the subject of the sentence
[02:45] <ubitux> "A major release is made every 3 months ..."
[02:46] <ubitux> it's not in your habit to wonder that much about such thing :)
[02:46] <ubitux> (it's not a reproach)
[02:47] <michaelni> no ... indeed
[02:59] <cone-732> ffmpeg.git 03Clément BSsch 07master:1edbeb353222: lavfi/ebur128: check histogram allocations.
[03:05] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:caff888183ac: avutil/frame: add AVBufferRef for qp table
[03:05] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:a0813e7f00ff: h263dec: export qp_table
[03:05] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:ff9adf57250f: mjpegdec: export qp table
[03:05] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:fa80967a7343: mpeg1/2: export qp table
[03:05] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:0bcea7b5754e: vf_pp: use new API to access qp table
[03:10] <ubitux> is there anyone working on porting lavfi device to the new api?
[03:10] <ubitux> nevcairiel?
[03:11] <michaelni> btw someone should port vf_spp
[03:12] <ubitux> i think mateo` was interested in it at some point but lost interest
[03:12] <ubitux> (maybe)
[03:13] <michaelni> spp is cool, it makes old low bitrate videos look alot better
[03:13] <michaelni> that is 320x240 realmedia and such ...
[03:14] <michaelni> that reminds me, we dont export qps from real video yet
[03:25] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:feac79ce53e6: rv10: export qp table
[03:25] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:46728338b0c3: rv34: export qp table
[03:30] <ubitux> got some little wtf here
[03:30] <ubitux> amovie,ebur128,volume  this works
[03:31] <ubitux> between amovie and ebur128 there is a special link with max/min samples
[03:31] <ubitux> now if do:
[03:31] <ubitux> amovie,ebur128
[03:31] <ubitux> it doesn't work anymore:
[03:31] <ubitux> the first buffersink read return an error
[03:32] <ubitux> because the fifo is empty
[03:33] <michaelni> sounds like you should ask cigaes
[03:33] <ubitux> i wonder how adding a filter at the end influences the link between amovie and ebur128
[03:33] <ubitux> yeah i guess
[03:33] <ubitux> but he's most likely sleeping now
[03:33] <ubitux> so i'll continue to hit my head for a few hours
[03:54] <ubitux> actually that's not volume which solve the problem, that's the auto-inserted resampler
[03:54] <ubitux> this problem sounds fun.
[04:20] <BBB> michaelni: also ping re: my draw_edge_16bpp removal
[04:48] <cone-732> ffmpeg.git 03Ronald S. Bultje 07master:8a523cfa8b92: dsputil: remove non-8bpp draw_edge.
[05:15] <ubitux> michaelni: your lib version info on download page just got useful :)
[05:15] <ubitux> thanks a lot for this
[06:18] <ubitux> yay i think i fixed the problem
[06:19] Action: ubitux mailing nicolas, and sleep
[06:19] <ubitux> 'night
[07:44] <wm4> matroska alac extra data handling seems to have a potential integer overflow
[08:17] <highgod> Hi,all, I want to ask a question.Do video decoders can input any prameters? thanks
[12:55] <michaelni> wm4 can you elaborate, where is that overflow ?
[12:56] <wm4> michaelni: it checks for track->codec_priv.size < INT_MAX-12
[12:56] <wm4> and then does:   extradata_size = 12 + track->codec_priv.size;  extradata = av_mallocz(extradata_size + FF_INPUT_BUFFER_PADDING_SIZE);
[12:56] <wm4> looks like this could overflow
[12:57] <wm4> just search for alac in matroskadec.c
[13:28] <nevcairiel> it could overflow, but a file with such a big codec private would be noticed before that :D
[13:32] <nevcairiel> av_mallocz takes a size_t as arg, which should be unsigned, but i'm not sure if it would be smart enough to convert to unsigned before doing the addition =p
[13:34] <cone-635> ffmpeg.git 03Can Wu 07master:81cf53e13309: mpegts: add support for stream_type 0x42, which is CAVS
[13:34] <cone-635> ffmpeg.git 03Kostya Shishkov 07master:b164d66e35d3: ape: make version-dependent decoding functions called via pointers
[13:34] <cone-635> ffmpeg.git 03Michael Niedermayer 07master:231795270b67: Merge commit 'b164d66e35d349de414e2f0d7365a147aba8a620'
[13:40] <michaelni> wm4, it overflows, becomes negative, gets cast to (unsigned) size_t and is then bigger then int_max, which fails a check in malloc which returns null which is checked for
[13:41] <michaelni> ill change the code so its nicer checking for this
[13:43] <cone-635> ffmpeg.git 03Kostya Shishkov 07master:9652d4fcfc9c: ape: provide two additional bytes in buffer for old MAC versions
[13:43] <cone-635> ffmpeg.git 03Michael Niedermayer 07master:5be70f58260e: Merge commit '9652d4fcfc9c07a726b35efc4ac644d9751b36d7'
[13:48] <cone-635> ffmpeg.git 03Kostya Shishkov 07master:c42e26251302: add support for Monkey's Audio versions from 3.93
[13:48] <cone-635> ffmpeg.git 03Michael Niedermayer 07master:2265bb93ffc4: Merge remote-tracking branch 'qatar/master'
[13:50] <wm4> michaelni: you added a field to AVFrame, shouldn't that have been done with a minor version bump?
[13:58] <wm4> michaelni: also I do not understand the point of av_frame_get_qp_table() - if there are public fields as well
[14:03] <durandal_1707> it is there because position can change
[14:11] <wm4> also, for some reason the qscale table I get is offset by 1 macro block in X dir and 2 macro blocks in Y dir (it doesn't happen if I compile with pre-TEP ffmpeg)
[14:11] <wm4> I don't really care about this stuff, though
[14:21] <cone-635> ffmpeg.git 03Michael Niedermayer 07master:70c0ae915d51: matroskadec: avoid integer overflow
[14:44] <cone-635> ffmpeg.git 03Michael Niedermayer 07master:64308941d404: mpegvideo: Fix exported qp table offest
[14:45] <michaelni> wm4, thx should be fixed
[14:48] <wm4> michaelni: appears to work
[15:07] <nevcairiel> is it just me, or is videolan git getting really slow lately, i'm getting like 4kb/s on a clone now
[15:12] <nevcairiel> now it died completely
[15:12] <nevcairiel> wasnt even a complete checkout, just a month old clone which wants to pull new stuff
[15:19] <nevcairiel> j-b: poke someone to make your git usable again :)
[15:20] <j-b> I dl at 2MiB/s
[15:25] <nevcairiel> then you need better peering to my provider, clearly! :)
[15:29] <nevcairiel> ooh it somehow finished
[15:29] Action: nevcairiel gets to work
[15:30] <kierank> you should try cloning ffmpeg/libav or anything on github in asia
[16:20] <cone-635> ffmpeg.git 03Michael Niedermayer 07master:cd5f50a25532: avfilter: avoid direct access to AVFrame.channels
[16:25] <nevcairiel> something is wrong with the lavfi compat layer, my app is crashing :(
[16:25] <nevcairiel> shall i investigate or just rewrite to avframe
[16:25] Action: nevcairiel ponders
[16:27] <wm4> using ref-counted AVFrame was simple
[16:28] <michaelni> nevcairiel, other applications might benefit from a bugfix of the compat layer 
[16:30] <nevcairiel> my guess is that its preserving the data even though i told it not to
[16:30] <nevcairiel> or well didnt give it permission
[16:31] <wm4> you mean it keeps a reference to a non-refcounted frame?
[16:33] <nevcairiel> yea
[16:33] <nevcairiel> av_buffersrc_add_ref has a bunch of compat code, but it never checks if it has the preserv permission
[16:34] <nevcairiel> lets see if i can quickly hack a memcopy in there to prove
[16:34] <durandal_1707> why keep compat code?
[16:36] <wm4> because removing it would break every single ffmpeg using program
[16:37] <wm4> (although ffmpeg keeps doing that anyway...)
[16:37] <nevcairiel> but in this case it owuld be without a grace period
[16:50] <nevcairiel> ok instructing it to copy instead fixes the crash and also seems to not leak any memory
[16:52] <wm4> shouldn't it just create a reference? (which copies if the AVFrame is not refcounted)
[16:52] <nevcairiel> i wonder, shouldn't it need to increase the refcount on the lavfi frame as well when it continues using it internally?
[16:53] <nevcairiel> wm4: the problem is that in the compat code the input is AVFilterBufferRef which gets converted to AVFrame
[16:54] <nevcairiel> i know too little how reference management in the AVFilterBufferRef worked to really fix this properly
[16:55] <wm4> ah so it attempts to keep it by-ref...
[16:56] <wm4> shouldn't it mark the AVFrame readonly somewhere?
[16:56] <nevcairiel> that it does if the input lacks the write permission
[16:56] Action: wm4 better shuts up now
[16:57] <nevcairiel> but that doesnt stop it from keeping it internally if a filter wants that
[16:57] <nevcairiel> like yadif in my case
[17:02] <nevcairiel> maybe i should just yell at anton and be done with it
[17:03] <wm4> the more I look at this code, the more I'm glad that the old buffer perm stuff etc. is gone
[17:04] <nevcairiel> it was really very poor
[17:04] <durandal_1707> amovie is converted to refcounted frames?
[17:04] <durandal_1707> eg. lavfi filter examples like showspectrum does not leak memory?
[17:04] <nevcairiel> all internals of lavfi are converted, they wouldnt work anymore otherwise
[17:05] <nevcairiel> the problem is that lavd is not converted fully
[17:05] <nevcairiel> which is where it leaks right now
[17:05] Action: ubitux not working on it
[17:05] <durandal_1707> it's stalling my source filter from 2000
[17:05] <nevcairiel> nicolas sent a patch to the ML days ago, got some feedback, and never got back to it
[17:07] <durandal_1707> i shamelessly pinged it
[17:08] <JEEBsv> ubitux: btw I'm pretty sure that one PM you sent me last night or so wasn't meant for me ^^;
[17:08] <durandal_1707> it was about ?
[17:08] <ubitux> bondage and stuff most likely
[17:08] <ubitux> JEEBsv: sorry about that :)
[17:09] <JEEBsv> no problem
[17:10] <durandal_1707> so where are performance comparaisons?
[17:11] <wm4> michaelni: libavcodec still doesn't mark frames writable that could be writable (i.e. non-ref frames), it's a low priority issue, but still
[17:12] <ubitux> are they really safely writable?
[17:13] <BBB-work> does anyone have opinions about making libavutil components configurable (i.e. --disable-everything could disable xtea unless one of the demuxers/encoders needs it)
[17:13] <wm4> perhaps, it worked fine when I made the ffplay/ffmpeg code do it
[17:15] <ubitux> BBB-work: a --disable-all was introduced a while ago to not break --disable-everything; iirc there was some concerns about what "everything" means
[17:15] <ubitux> i can't tell if xtea shoud theorically be included or not in that everything
[17:17] <BBB-work> ubitux, I don't care much about all vs everything; my point is, libavutil componentization (and being able to disable components if they're not needed in your specific build)
[17:18] <ubitux> maybe --disable-all was solving that exact problem already, that's why i mentioned it
[17:19] <ubitux> 'might save you some configure messing
[17:20] <BBB-work> it doesn't, libavutil is not componentized
[17:20] <BBB-work> all OBJS are unconditionally compiled
[17:20] <BBB-work> check http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/ffmpeg_generated.gypi?revision=172476&view=markup
[17:20] <BBB-work> the problem is all kind of files are build (and possibly symbols included in the binary, have to check) which we don't want there
[17:20] <BBB-work> note how dirac.c is there
[17:20] <BBB-work> I mean, wtf right? :)
[17:20] <ubitux> oh ok
[17:21] <ubitux> maybe because it's considered part of the api
[17:21] <ubitux> (not dirac, i'm talking about the xtea etc)
[17:21] <BBB-work> but what I'm more concerned about is stuff like mux.c, rmsipr.c, subtitles.c in libavformat/ and a whole bunch of stuff in libavutil
[17:21] <BBB-work> I already cleaned out most of libavcodec
[17:22] <BBB-work> I guess dirac.c is included because of ogg_demuxer
[17:22] <BBB-work> weird
[17:22] <ubitux> disabling subtitles.c if all the text subtitles are disabled may be possible
[17:22] <ubitux> can't tell for the rest
[17:22] <BBB-work> that would be useful
[17:22] <BBB-work> now, as for libavutil, I agree in a default build they should be there b/c they're part of api
[17:23] <BBB-work> but for a custom build (like in --disable-all/everything), I'd like it to be possible to not include it
[17:23] <nevcairiel> its still public api, it should not be disabled just because a decoder doesn't need some functions, thats way too unintuitive
[17:23] <ubitux> afaik any build (--disble-all or --disable-everything based) doesn't drop any of the features exported in the public headers
[17:24] <ubitux> and dropping some headers randomly in some configuration is problematic
[17:24] <BBB-work> I don't care about the headers
[17:24] <nevcairiel> explicit options to disable parts of avutil would be OK i guess, but not logic that excludes functions that are simply not used by anything
[17:24] <BBB-work> just about the symbols and source code
[17:24] <BBB-work> I want smaller build time and (if that makes a difference) smaller binary
[17:24] <ubitux> one solution is to replace the code with a av_log unsupported or something
[17:25] <ubitux> but the interface should still be there
[17:25] <BBB-work> I can make it custom options
[17:25] <BBB-work> that's fine
[17:56] <iive> BBB-work: how big is your libavutils?
[17:58] <BBB-work> iive, I believe it's 200kb after stripping?
[17:58] <BBB-work> if I can shave off half of that, that would be a massive gain for us
[17:58] <durandal_1707> 156kb here
[17:59] <BBB-work> 100kb (or 75kb) is worth some trouble to me
[17:59] <iive> avutil was supposed to contain small functions. not pixfmt and riff/fourcc databases...
[17:59] <BBB-work> well avutil contains a lot more than just small functions, and a large part of it is not at all generic or broadly used across all demuxers and codecs
[17:59] <iive> maybe it would make sense splitting it in two.
[17:59] <BBB-work> no
[18:00] <BBB-work> you're approaching the problem from the diego perspective
[18:00] <BBB-work> back when I touched dsputil for the first time, diego insisted we split dsputil in two
[18:00] <BBB-work> that would solve all problems
[18:00] <BBB-work> to me, it means you don't truly understand the problem; a split just splits the problem in two
[18:00] <BBB-work> that is, instead of 1 problem, I know have 2 problems
[18:00] <BBB-work> s/know/now/
[18:01] <BBB-work> to solve the problem, you need to analyze it, and figure out what is needed for specific use cases you're interested in; then, implement that
[18:01] <BBB-work> that's called problem solving (vs. problem splitting)
[18:02] <BBB-work> in my case, the problem is that there's all this stuff being built that I don't need. splitting it in two along any dimension likely doesn't solve that, because both will be needed, and now both will contain I do need and other stuff which I don't need
[18:02] <BBB-work> look at avcore, it was just problem duplication
[18:02] <iive> I'm trying to understand what is your problem.
[18:04] <durandal_1707> want only code that is used by single decoder and everything else not used removed
[18:04] <iive> Well, using static building would help that automatic, but would duplicate code in all places where it is used.
[18:05] <iive> manually marking every function that is used by such and such decoder would be possible, but need some table of usage... either as ifdef-ery or in configure.
[18:06] <BBB-work> iive, right, so I'm proposing I do that in configure
[18:07] <iive> two stage compilation, or chocking out unused functions after compilation... may be possible but tricky
[18:08] <iive> chocking/knocking
[18:08] <BBB-work> well, it's true that a good linker removes unused functions (we actually use that in chrome), but that still adds up to build time
[18:08] <BBB-work> build time is actually a significant expense when you're talking about a massive project like chrome
[18:09] <BBB-work> and although it's certainly true that removing xtea.c from compilation won't directly fix that problem, the point is that there's millions of xtea.c's around in chrome's source tree; and we need to get rid of most of them, so each and every single bit helps
[18:13] <iive> imho, manual approach would impose too much burden on future maintainer ship. Especially when it is a matter of functions that are the size of 1 or 2 pages.
[18:15] <iive> there are how many? 55 separate modules? about 1/4 of all codecs.
[18:23] <BBB-work> iive, but we already do that in configure
[18:23] <BBB-work> and it's easy to test this stuff in scritsp
[18:23] <BBB-work> scripts*
[18:27] <iive> well... I'm not sure if it makes sense to increase the configure complexity with 1/4 to deal with 200KB. btw, do you have idea how many bytes you'll eliminate? half? 1/2? 1/3? 1/4?
[18:27] <BBB-work> iive, good question, don't know yet
[18:28] <BBB-work> iive, but for comparison, in libavcodec, killing dsputil and mpegvideo gained me roughly 2/3rd of a MB (in a binary that was originally almost 3MB)
[18:28] <BBB-work> so there certainly is great gains to be had
[18:30] <iive> engineering is all about trade offs.
[18:31] <iive> if compiler can do the elimination, then so be it.
[18:31] <wm4> why not make sure the code is decoupled enough, and then do the final, messy bits with custom patches outside of the official ffmpeg tree?
[18:33] <BBB-work> we're going in circles now; I'll follow nevcariel's suggestion and we can take it from there
[18:34] <BBB-work> wm4, we (chrome) prefer to not have to carry a large maintenance burden
[18:34] <BBB-work> it's confusing both for us (chrome) as well as for us (ffmpeg)
[18:37] <iive> yes, nevcariel's suggestion looks like a good trade off.
[18:38] <BBB-work> (hopefully after that I can answer your "how much space do we save" question with real data)
[19:07] <burek> I think I have to open a ticket but I don't even know witch button to push. Could you give me some advices.
[19:07] <burek> that's a quote from the forum :)
[19:07] <burek> of course, I won't suggest anything :)
[19:08] <burek> ffmpeg is already perfect the way it is :)
[19:09] <durandal_1707> that is contradiction
[19:09] <burek> really? :) which part exactly? ^^
[19:12] <cone-635> ffmpeg.git 03James Darnley 07master:3d751b1ef661: yadif: correct strides in filter_edges_16bit
[19:12] <Compn> burek : did you see that one bug got fixed?
[19:12] <Compn> i wasnt able to locate the change (or that hash)
[19:12] <durandal_1707> what one bug?
[19:12] <burek> yes :) great :) although, I thought there was no bug at all :)
[19:13] <cone-635> ffmpeg.git 03Paul B Mahol 07master:a9b424879f10: lavc & lavf: replace deprecated av_log* functions
[19:14] <durandal_1707> burek: you wrong
[19:15] <durandal_1707> burek: if you want some specific bug to be reopened just point it to me
[19:19] <durandal_1707> there are at least 2 regressions reported on trac since refcount merge
[19:20] <burek> durandal_1707 ok :) im just trying to be a bit funny and kinda ironic :)
[19:21] <burek> i've got a feeling tickets are being closed as fast as they can, for unknown reason, hence my ironic comments :)
[19:23] <durandal_1707> valid tickets should not be closed, invalid ones should be closed with valid explanation
[19:24] <burek> yes, i agree, i'm not against that, i'm just against declaring a lot of tickets as invalid, even though they might contain enough information to get the debuging started
[19:25] <burek> also, if left open, someone might take a look at it and maybe even fix it, so they dont hurt if they stay open
[19:25] <durandal_1707> please point to such bug report(s)
[19:25] <burek> and some kind of auto-close could be setup so that all the tickets, not updated for like 6-12 months, would get auto-closed or so
[19:26] <burek> well, you'll get a good headstart if you search for example for the tickets closed by cehoyos
[19:27] <durandal_1707> i think one can't search/filter by person that closed ticket ...
[19:27] <durandal_1707> i would need to waste time reading timeline like I'm historian
[19:27] <burek> well, i pointed that out several times, it would really be annoying for everybody if i do it again
[19:28] <durandal_1707> i really doubt that
[19:29] <ubitux> durandal_1707: i think burek is refering to #2358 
[19:30] <ubitux> and maybe #2357
[19:30] <durandal_1707> http://ffmpeg.org/trac/ffmpeg/timeline?from=03%2F15%2F2013&daysback=30&authors=cehoyos&ticket=on&update=Update
[19:32] <burek> it boils down that I copy issues from forum, where people post logs and sometimes find out some possible bugs, but when i repost it as a bug report, sooner or later it gets closed, imho purely out of arrogance.. i might be wrong, but that's my feeling about it..
[19:35] <durandal_1707> ubitux: one of them have been fixed, and new bug should be reported for unrelated issue
[19:35] <durandal_1707> another one is plain invalid, but was closed without proper explanation
[19:44] <durandal_1707> if nobody wants to work on #1424 i will close it
[20:02] <durandal_1707> should #1783 be closed?
[20:03] <nevcairiel> BBB-work: i'm having an odd case of unaligned stack with mingw-gcc, any idea what could cause that? i thought gcc/yasm would always align the stack properly, or does it need to be told to do so on a per-function basis? 
[20:05] <saste> durandal_1707, I think so, unless someone wants to rename time.h -> avtime.h
[20:06] <saste> but given that the reporter found a solution, and that the proper solution consists into using sane include paths, I think it could be closed
[20:11] <BBB-work> nevcairiel, is this with threading enabled?
[20:12] <BBB-work> nevcairiel, so the problem on windows is that if the app is not gcc compiled, you need to tell gcc to align the stack on function entry from "outside" the gcc "jail"
[20:12] <BBB-work> nevcairiel, all public api functions do that
[20:12] <BBB-work> nevcairiel, we might've forgotten to mark one
[20:12] <nevcairiel> i see
[20:12] <nevcairiel> how does that mark look?
[20:12] <nevcairiel> its specifically on lavfi functions, which are new now
[20:13] <nevcairiel> easy to forget
[20:13] <BBB-work> int attribute_align_arg avcodec_open(AVCodecContext *avctx, AVCodec *codec)
[20:13] <BBB-work> e.g.
[20:13] <BBB-work> it's the attribute_align_arg
[20:13] <BBB-work> the prototype doesn't need it
[20:13] <BBB-work> just the actual function implementation
[20:14] <nevcairiel> let me check if that helps, thanks for the tip
[20:14] <BBB-work> np
[20:14] <saste> durandal_1707, when closing tickets please add a line explaining why, so we avoid flames
[20:18] <durandal_1707> saste: what explanation? we can't just rename random stuff like Libav can
[20:20] <nevcairiel> BBB-work: so far it seems to fix it, thanks :)
[20:20] <BBB-work> \o/
[20:20] <nevcairiel> no lavfi functions had it yet, guess yadif is the first yasm code i'm trying to run there
[20:22] <BBB-work> maybe yes
[20:23] <nevcairiel> if function X has the attribute, and Y calls X, i assume Y doesn't need the flag anymore?
[20:27] <BBB-work> the very toplevel functions need the call
[20:27] <BBB-work> i.e. the public api entry functions
[20:27] <BBB-work> all of them
[20:27] <nevcairiel> yeah there is just a few public functions which call another public function
[20:27] <BBB-work> things like avcodec_decode_video, avformat_read_frame, avfilter_do_something
[20:27] <nevcairiel> just wondering if it still needs it then
[20:27] <BBB-work> they probably both need it then
[20:27] <nevcairiel> doesnt hurt i guess
[20:27] <BBB-work> since the internals could be entered through both, right?
[20:27] <BBB-work> think of it as a jail entry
[20:28] <BBB-work> whichever entrace you take, make sure there was at least one such guard to keep unaligned dangers out
[20:28] <BBB-work> don't do it? shit will hit the fan :)
[20:29] <nevcairiel> there is stuff like av_buffersink_get_frame(ctx, frame) which internally calls av_buffersink_get_frame_falgs(ctx, frame, 0), so it just adds one parameter and calls the other function, so if that other function has the guard, it always passes through it
[20:29] <nevcairiel> if i understand this right now
[20:31] <BBB-work> sure then you only need it on one
[20:32] <BBB-work> just like if you have avcodec_decode_video1 calling video2 calling video3 calling video4 calling avcodec_decode_videoN
[20:32] <BBB-work> only videoN needs it
[20:32] <durandal_1707> so old tracker: roundup died?
[20:32] <nevcairiel> yeah. thanks, i'll send a patch to fix my immediate problem and then look through the other apis and add it some places :)
[20:34] <BBB-work> ty
[20:45] <llogan> durandal_1707: shit. i was planning on trying to mirror it...
[20:48] <cone-635> ffmpeg.git 03Nicolas George 07master:b90912be6802: lavd/lavfi: upgrade to AVFrame.
[20:50] <nevcairiel> ah neat, that should cut down on the memory leaks in valgrind
[20:53] <ubitux> hell yeah
[20:59] <llogan> durandal_1707: do you have a backup mentor ofr APNG?
[20:59] <llogan> *for
[21:01] <durandal_1707> llogan: yes, alter me
[21:04] <llogan> http://upload.wikimedia.org/wikipedia/en/thumb/0/05/Altered_Beast_cover.jpg/220px-Altered_Beast_cover.jpg
[21:10] <cone-635> ffmpeg.git 03ArnoB 07master:361319d0f494: dpxenc: fix data offset
[21:11] <llogan> looks like a new ffmbc is out
[23:07] <jojva> If out of curiosity you want to take a look at the MVC decoder I'm implementing, here's my fork : https://github.com/jojva/FFmpeg
[23:09] <ubitux> jojva: do you plan to participate in GSoC?
[23:10] <ubitux> iirc we added a task for this in the wiki, not sure it's still relevant if you're working on it
[23:10] <jojva> I'm taking a look at gsoc. When it is, etc.
[23:11] <jojva> Wasn't it refused in 2012 ?
[23:11] <jojva> rejected*
[23:12] <ubitux> yeah we got refused last year; we hope to get in this time though
[23:13] <jojva> Anyway, this is still relevant, as I don't know how far I will bring it.
[23:14] <jojva> But it can give ideas to my followers
[23:20] <michaelni> about hevc gsoc, theres a WIP decoder, a gsoc task should improve on that
[23:20] <smarter> michaelni: we got P/B-frames working very recently :)
[23:21] <michaelni> cool, do you want to mentor such a gsoc task?
[23:21] <smarter> I won't be available for that this summer unfortunately
[23:21] <michaelni> :(
[23:21] <smarter> but I hope to get the decoder upstream into libav and ffmpeg before that
[23:22] <JEEB> hmm, I guess I'll have to rebuild
[23:22] <JEEB> the last I tried HM10-encoded Bframes failed
[23:23] <smarter> note that frames are output in decoding order currently
[23:23] Action: smarter should figure out how to fix that correctly
[23:24] <jojva> It should be similar to h264
[23:25] <smarter> yup, but diving into h264.c is never easy :p
[23:25] <jojva> It's easy : just a matter of poc... ^^
[23:36] <BBB-work> smarter, I can help with that part (I'm pretty familiar with h264)
[23:36] <jojva> Am I right that the most important goal for 2013 gsoc is hevc ?
[23:37] Action: BBB-work not involved in gsoc
[23:37] <llogan> BBB-work: would you like to be a mentor?
[23:37] <michaelni> jojva, i dont think theres a "most important goal"
[23:37] <BBB-work> llogan, sorry, but no, I'll skip this year
[23:38] <llogan> ok. i just had to ask though...
[23:38] <BBB-work> I'll quote smarter, I'll have some other things to do :)
[23:38] <smarter> BBB-work: great
[23:45] <BBB-work> smarter, if you need help with coding->display order, ask me (or michaelni will probably know also) where the magic code is in h264 and what it does
[23:48] <smarter> alright, I'll ask soon
[23:49] <smarter> by the way, is there any reason why there's no x86-optimized version of get_cabac_bypass ?
[23:50] <smarter> I guess it's because it's not much used in h264, there's a lot more of bypass-coded symbols in hevc
[23:50] <jojva> BBB-work : I have a question about h264. When each picture is an independent field, where in the code are the top and bottom fields "merged" to create the full frame ?
[23:52] <smarter> I'm also wondering if it would help performance to have a function that gets n bypass-coded bytes at once
[23:53] <smarter> s/bytes/bits/
[00:00] --- Sat Mar 16 2013