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

[burek]

[00:00] <nevcairiel> should revisit this after the merge and try to make them all dynamically allocated
[00:00] <nevcairiel> pushed another decoder, but thats it for today, work tomorrow <.<
[00:01] <Daemon404> http://fate.ffmpeg.org/log.cgi?time=20130310224513&log=compile&slot=tilepro-linux-gnu
[00:01] <Daemon404> doesnt beak on libav
[00:05] <Daemon404> o hay there it is
[00:10] <burek> saste, for example, take -stats option, it's common for both ffplay and ffmpeg and it's located in both doc files as a distinctive option
[00:10] <burek> i.e. it's duplicate
[00:10] <michaelni> nevcairiel, merged, pushed and thanks alot
[00:10] <burek> also, pix_fmt
[00:10] <burek> -f, -i
[00:33] <ubitux> vp3 might be ok, but it will require some testing, i'm not familiar at all with this stuff..
[00:33] <ubitux> the copy_fields got dropped
[00:33] <ubitux> but we had 2 local modifications to them
[00:34] <ubitux> i'm not sure if these changes are still relevant
[00:50] <ubitux> michaelni: i've pushed the vp3, but second eyes are very welcome (see commit description)
[00:51] Action: ubitux working on vcr1
[00:54] Action: ubitux working on v210x
[00:54] <BBB> first stab at hpel patches back at ml
[00:55] <BBB> probably already outdated because of all that breakage everyone is doing
[00:55] <BBB> but at least I can say I tried it
[00:55] <BBB> for each decoder I've verified --disable-everything --enable-decoder=X works
[00:55] <BBB> I can push a tree if that helps
[00:56] <BBB> with this tree, chrome is mpegvideo- and dsputil-free
[00:57] <Daemon404> orite, BBB, so there's a bug filed about that hwaccel issue with chrome, and their reply is "needs an h264 expert"
[00:57] <Daemon404> isnt that you at google?
[00:57] Action: Daemon404 runs
[00:57] <BBB> I thought I worked on this thing called vpsomething
[00:57] <BBB> also how is "their"?
[00:57] <BBB> in "their" reply
[00:57] <BBB> how/who
[00:57] <Daemon404> sec
[00:57] <Daemon404> ome chromium devs
[00:58] <Daemon404> someoen named fischman
[00:58] <BBB> ami
[00:58] <Daemon404> "rohi..."
[00:58] <BBB> what is the bug?
[00:58] <Daemon404> and posciak
[00:58] <BBB> link?
[00:58] <Daemon404> https://code.google.com/p/chromium/issues/detail?id=164053
[00:58] <Daemon404> turns out one of our users reported it before
[00:59] <Daemon404> i think.
[00:59] <Daemon404> the descriptions form teh devs are frutratingly vague
[00:59] <BBB> you have a lumpy?
[01:00] <Daemon404> tahts not accurate
[01:00] <Daemon404> it happens on all sorts of things
[01:00] <Daemon404> including my laptop
[01:00] <Daemon404> wide range of windows machines
[01:01] <ubitux> BBB: you should send your patches with -M :p
[01:01] <Daemon404> ~response 17 is kind of useful
[01:02] <ubitux> saste: so can you work on the eval thing this week so i can push my volume normalization in maximum one week? :)
[01:02] <ubitux> (hi)
[01:02] <Daemon404> meh its liek a mish mash of bugs there
[01:03] <BBB> Daemon404: file a new bug
[01:03] <BBB> Daemon404: this bug is about a lumpy issue with vpapi in field mode
[01:04] <BBB> lumpy=chromebook/chromeos
[01:04] <BBB> if you have a windows issue, it's likely a different issue and deserves a new bug
[01:04] <Daemon404> right
[01:04] <BBB> the status seems pretty clear to me: please test with current devchannel release
[01:04] <BBB> if it persists, please open a new bug so we can analyze, and tell us which video (i.e. supply a link) and all relevant hardware info so we can try to reproduce
[01:04] <Daemon404> ive already told the guys to use that
[01:05] <Daemon404> im not putting dev channel on my personal machines
[01:05] <BBB> they haven't done it yet :)
[01:05] <BBB> so there's nothing we can do
[01:05] <BBB> we believe the issue is fixed in devchannel
[01:05] <BBB> (is what I'm reading from the bugreport)
[01:05] <Daemon404> i can see that
[01:05] <Daemon404> i hadnt checked the bug recently
[01:05] Action: ubitux on wavpack
[01:06] <BBB> ubitux: you're starting to sound dangerously much like diego
[01:06] <Daemon404> what are you guys even grinding?
[01:06] <BBB> I'm not
[01:06] <BBB> but he told me to use -M
[01:06] <Daemon404> directed at ubitux 
[01:06] <BBB> I remember diego telling me 100s of times to do something like that
[01:06] <Daemon404> well
[01:06] <Daemon404> -M is extremely useful
[01:06] <Daemon404> for moving files
[01:06] <BBB> import the patch and re-gen your own patches using -M
[01:07] <Daemon404> or just send it with -M as a courtesy
[01:07] <BBB> I even offer to export my tree to github
[01:07] <Daemon404> to make reviewing easier?
[01:07] <Daemon404> i mean initially
[01:07] <BBB> https://github.com/rbultje/ffmpeg/commits/wmv2dsp
[01:08] <Daemon404> i also wonder if it isnt just useful to dump alpha completely
[01:08] <Daemon404> or superh
[01:09] <ubitux> BBB: this was mainly for patch 19, because it's a 3537 vs 3486 lines, and it's hard to tell at first glance what changed; but of course if it's available in a public repo it's fine
[01:10] <ubitux> that patchset is not going to ease the current merge work we're on
[01:10] <BBB> Daemon404: I agree!
[01:10] <ubitux> you might need to rebase...
[01:10] <BBB> ubitux: I'll rebase, that's fine
[01:10] <BBB> I've rebased this before, it sucks but it's doable
[01:11] <BBB> let me know when you guys are done and I'll rebase it
[01:11] <ubitux> i don't know how much filters are left
[01:11] <ubitux> not that much where conflicts fix are required
[01:11] <Daemon404> ubitux, what are you guys doing with all the codecs right now?
[01:12] <ubitux> but then there are all our codecs
[01:12] <Daemon404> e.g. wavpack/v21
[01:12] <Daemon404> 0
[01:12] <ubitux> fixing conflicts
[01:12] <Daemon404> o
[01:12] <ubitux> a lot are trivial
[01:12] <ubitux> some aren't at all :p
[01:12] <ubitux> see https://github.com/michaelni/FFmpeg/commits/lavc-merge-mess
[01:13] <Daemon404> those aren't "conflicts" in the strict definition of teh word
[01:13] <Daemon404> look more like failures
[01:14] <Daemon404> https://github.com/michaelni/FFmpeg/commit/c9fa7cc95562b29e29c92d1fb5db1a06f069a78b
[01:14] <Daemon404> like that
[01:14] <ubitux> look at resolve conflicts commits
[01:14] <Daemon404> ah
[01:15] <ubitux> but yes there are different issues
[01:15] <ubitux> fix the conflicts, fix the builds, change our codecs
[01:16] Action: ubitux on pngdec
[01:18] <Daemon404> i suspect a long trail of bugs to linger
[01:18] <Daemon404> im surprosely waiting to upgrade ffmpeg at work
[01:18] <Daemon404> purposely*
[01:18] <ubitux> well
[01:19] <ubitux> in a sense
[01:19] <ubitux> that's an extra review on top of libav work
[01:19] <ubitux> nevcairiel already spotted a problem..
[01:19] <Daemon404> i mean bugs for random merge weirdness
[01:19] <ubitux> and michaelni might be hiding some ;)
[01:19] <Daemon404> liek double lines
[01:19] <Daemon404> and such
[01:19] <wm4> libav is also having bugs
[01:19] <wm4> so it's not just the merges
[01:19] <Daemon404> well yeah
[01:20] <Daemon404> it hosed my fate server
[01:20] <Daemon404> =p
[01:20] <Daemon404> (native mingw)
[01:20] <michaelni> ubitux, the vp3 stuff is probably ok if it works (but maybe BBB wants to take a look too)
[01:27] <ubitux> ok
[01:27] <ubitux> BBB: if you have a moment to have a look to https://github.com/ubitux/FFmpeg/commit/042299d7 ... :)
[01:28] <ubitux> it needs testing anyway
[01:28] <Daemon404> wouldnt an absolute diff be easiest
[01:28] <Daemon404> i.e. before/after merge+conflicts
[01:31] <ubitux> not sure if you can change the view easily with github
[01:32] <ubitux> the thing is, the changes from Anton are relatively large
[01:32] <ubitux> this is indeed just a limited view of the change scope
[01:33] <Daemon404> oic
[01:34] <ubitux> https://github.com/ubitux/FFmpeg/commit/759001c5#L215L130  careful if you have a slow machine
[01:35] <Daemon404> github's bloated js can make any machine slow
[01:36] <ubitux> the commit size doesn't help either..
[01:36] <Daemon404> i can view a text file of it file
[01:36] <Daemon404> add .patch to the end of the url
[01:36] <Daemon404> fine*
[01:36] <ubitux> github makes it slow to punish developers for doing such commits
[01:46] Action: ubitux on qpeg
[01:47] <wm4> was there a decision yet how to handle qscale_table?
[01:52] <michaelni> wm4, my intent is to fix qscale_table so it stays available to the end user app but probably that will be in the future when the dust has settled 
[01:52] <wm4> ok
[01:53] <michaelni> dirac updated
[01:53] <michaelni> also crystalhd needs someone with the hardware to look at and update it i just fixed it so it compiles
[01:53] <ubitux> michaelni: i may need your help for qpeg soon, because of a0db7424
[02:04] <ubitux> mmh it seems qpeg from libav is still using a AVFrame field in the context
[02:04] <ubitux> (no previously allocated)
[02:04] <ubitux> i wonder if that's ok
[02:08] <michaelni> in an ideal world not ok
[02:09] <michaelni> atm there are higher priority things to fix
[02:09] <michaelni> though
[02:10] <ubitux> michaelni: i'm just trying to understand to get your change on top of libav
[02:11] <saste> michaelni, I'll apply for gsoc tomorrow
[02:12] <michaelni> saste, thanks though iam now not sure from whan to when the time is to apply maybe its actually to early
[02:13] <michaelni> ubitux, all use of sizeof(AVFrame) is an ABI issue outside libavutil
[02:14] Action: michaelni just got svq1 working
[02:16] <ubitux> michaelni: you commit i'm refering seems to be doing a memcpy(a,a) in some situation
[02:16] <ubitux> (in case !refdata in the intra func)
[02:16] <ubitux> inter*
[02:17] <BBB> ubitux: it seems to me someone changed the way data is copied between instances in threading
[02:17] <BBB> ubitux: I didn't review it, I don't know how it works, so I can't tell if this is good or not
[02:18] <BBB> ubitux: likely, if make THREADS=[2-16] fate-vp3 works, it's ok
[02:18] <ubitux> ok, i'll try that
[02:18] <ubitux> thank you
[02:18] <michaelni> ubitux, about memcpy(a,b), simply adding a if(a!=b) is probably ok
[02:31] <ubitux> michaelni: i've pushed a compilation fix with some notes so we don't forget what's left in it
[02:31] Action: ubitux on roqvideodec
[02:34] Action: ubitux on pictordec
[02:38] <ubitux> -                    picmemset_8bpp(s, val, run, &x, &y);
[02:38] <ubitux> +                    picmemset_8bpp(s, frame, val, run, &x, &y);
[02:38] <ubitux> result of the merge:
[02:38] <ubitux>                     picmemset_8bpp(s frame,, val, run, &x, &y);
[02:38] <ubitux> wtf git :))
[02:39] <ubitux> what are you doing?!
[02:42] <michaelni> huh, git shouldnt do that
[02:42] <ubitux> maybe i messed up somewhere but...
[02:42] <ubitux> look at libavcodec/pictordec.c
[02:44] <michaelni> must have been a human typo (aka my fault)
[02:44] <ubitux> how evil you are!
[02:45] Action: ubitux on mdec
[02:46] Action: ubitux on tiertexseqv
[02:48] <michaelni> merged and pushed up to "pngdec:"
[02:49] Action: ubitux on smacker
[02:50] Action: michaelni updated ffwavesynth but thats trivial
[02:51] Action: ubitux on vb
[02:52] Action: michaelni on g729dec
[02:52] <michaelni> well done rather 
[02:52] <michaelni> these audio codecs are too easy
[02:52] Action: ubitux on vqavideo
[02:53] <ubitux> yeah nevcairiel said it while he was at it
[02:55] <ubitux> michaelni: i've moved qpeg on top if you don't want to merge it easily
[02:55] Action: ubitux on xl
[02:56] <michaelni> indeo5 fixed
[02:57] Action: michaelni needs to make 10min pause for eating
[02:59] <ubitux> again?!
[02:59] <ubitux> so you're eating EVERY DAY
[02:59] <ubitux> you told us the same thing yesterday
[03:00] Action: ubitux on tmv
[03:03] Action: ubitux on tiff
[03:12] Action: michaelni on j2k
[03:13] Action: ubitux on vmdav
[03:19] Action: ubitux on truemotion1
[03:20] Action: ubitux on vp6
[03:21] <ubitux> oh oh.
[03:21] <ubitux> i don't think i'll do this one
[03:22] <ubitux> i mean, this one might be ok, but vp5 and vp56..
[03:22] <ubitux> mmh well
[03:22] <ubitux> should be ok in fact
[03:22] <ubitux> let's do it.
[03:27] <michaelni> j2k works, 2 min for the code 8min for finding out how to test it
[03:30] <michaelni> libopencore-amr fixes
[03:30] <michaelni> fixed
[03:33] <michaelni> libvorbisdec done
[03:36] <michaelni> loco done
[03:39] <Compn> code bonanza!
[03:42] <michaelni> paf fixed
[03:45] <ubitux> ok, vp5/vp56/vp6 changes are not trivial at all.
[03:47] <ubitux> michaelni: i'm giving up the vp5/vp56/vp6
[03:47] <ubitux> i won't be able to merge the slice threading properly
[03:48] Action: ubitux on truemotion2
[03:49] <ubitux> oh
[03:50] <ubitux> i think 63edd2f9 broke fate gpl
[03:53] <ubitux> mmh we should remove that conditionnal include
[03:56] <michaelni> prores fixed
[03:57] <ubitux> beh cone dead
[04:00] <ubitux> truemotion 1 & 2 done
[04:03] <ubitux> pushed something for interplayvideo, but untested
[04:05] <ubitux> lcldec fixed
[04:05] <ubitux> libcelt_dec fixed
[04:08] <ubitux> michaelni: i have a few things to pick
[04:12] <ubitux> would be nice if Paul or other codec developers could help
[04:13] <ubitux> because i'm really not a lavc guy and i feel a bit useless here :p
[04:13] <michaelni> useless ? you are alomost done with resolving the conflicts
[04:14] <ubitux> yeah well, they are trivial, and i still need to test them properly..
[04:15] <ubitux> it's likely i've made some mistakes
[04:15] <michaelni> yes and i sure made some as well
[04:16] <michaelni> we will find them when testing
[04:16] <michaelni> of course if paul would help that would speed it up
[04:16] <michaelni> alot
[04:17] <ubitux> fixed compilation for two additionnal codecs
[04:17] <ubitux> i'm doing the same change all over again
[04:17] <ubitux> i hope it's a good one
[04:17] <ubitux> :D
[04:19] <michaelni> ill look at vp56 tomorrow unless someone else does it before
[04:19] <ubitux> actually
[04:19] <ubitux> maybe it would have made sense to revert 01042d4123b6e0a4c15d6828f835bd648eb03d38 in the first place
[04:20] <ubitux> i'll look at... testing my mess tomorrow
[04:20] <ubitux> :)
[04:20] <ubitux> 'night
[04:22] <michaelni> night
[10:37] <durandal_1707> the stereo3d evil change is also wrong
[11:16] <ubitux> durandal_1707: sorry if i made a mistake; what's wrong with the change?
[11:18] <durandal_1707> it copies buffer props which overwrites w/h/sar
[11:19] <durandal_1707> but somehow it still works with ffplay
[11:19] <durandal_1707> IIRC it did not when I did port
[11:19] <ubitux> oh right my bad i didn't realized the w/h were changed
[11:21] <ubitux> this should be re-set after the copy_props
[11:21] <ubitux> but you need to keep it anyway
[11:21] <durandal_1707> well if input is sbsl/r or abl/r and output is ml/mr it width/height should be 50% of original
[11:21] <ubitux> it's copying a bunch of fields that are necessary
[11:22] <ubitux> so copy_props and then re-set w/h, just like scale and some others
[11:22] <durandal_1707> but i wonder why ffplay/ffmpeg still works
[11:23] <ubitux> btw, did we need help for the lavc merge
[11:23] <ubitux> and since i'm far from familiar with lavc, you might want to have a look
[11:24] <durandal_1707> s did// ?
[11:24] <ubitux> yeah drop the did
[11:25] <ubitux> see github:michaelni/lavc-merge-mess
[11:29] <durandal_1707> i think i could only be code monkey for "our only" codecs
[11:29] <durandal_1707> or there are bunch of hard conflicts?
[11:30] <ubitux> yeah there are a few hard conflicts iirc
[11:30] <ubitux> michael was planning to do the vp56 merge
[11:30] <ubitux> (conflict because we have slice threading)
[11:31] <ubitux> try to build, you'll see
[11:32] <durandal_1707> how i checkout it?
[11:32] <durandal_1707> branch i mean
[11:32] <durandal_1707> i already have michaelni as repo
[11:33] <durandal_1707> git pull michaelni lavc-merge-mess want to merge with my master
[11:42] <durandal_1707> nvm, got it
[11:45] <durandal_1707> ubitux: you surce wavpack fate passes with you change?
[11:45] <durandal_1707> *sure
[11:45] <durandal_1707> because you removed reset of nb_samples
[11:46] <durandal_1707> actually not, its fine
[11:57] <ubitux> durandal_1707: i didn't test yet, that's my next task
[11:57] <ubitux> durandal_1707: it was a pain to test yesterday (and it still is somehow)
[11:57] <ubitux> so i postponed
[12:02] <nevcairiel> worse are codecs which have no fate test
[12:03] <nevcairiel> durandal_1707: maybe you can test exr, it didn't have a fate test and i'm not sure its 100% correct, but you seem to have worked on it a lot
[12:09] <durandal_1707> anybody working on interplay?
[12:11] <mateo`> is there a list of codec not yet ported to the new api ?
[12:11] <nevcairiel> checkout the branch, check which break
[12:11] <nevcairiel> :D
[12:11] <nevcairiel> obvious are the ones with merge conflicts in them, less subtle hints are those that still have release_buffer usage in them
[12:12] <ubitux> durandal_1707: i did it
[12:12] <nevcairiel> or those that fail to build because of ff_get_buffer having not enough arguments
[12:12] <durandal_1707> ubitux: when it get merged?
[12:12] <mateo`> nevcairiel: thx
[12:12] <ubitux> dunno if it was, lemme check
[12:13] <ubitux> mmh something changed in the branch
[12:14] <mateo`> i take tiff if nobody is working on it
[12:14] <ubitux> i've done it
[12:14] <ubitux> hehe both tiff and interplay are in my branch
[12:14] <durandal_1707> michaelni: paf still have warning
[12:15] <ubitux> https://github.com/ubitux/FFmpeg/commits/lavc-merge-mess
[12:15] <ubitux> last 3 commits are not upstream
[12:15] <ubitux> so in addition to michael's branch, interplay, qpeg and tiff are done
[12:15] <ubitux> feel free to pick them
[12:17] Action: durandal_1707 is just unbreaking compilation
[12:17] <nevcairiel> looking at qpeg, it suffers from a rather common problem, after all the merging is done we should go through everything again and replace all embedded AVFrames in codec priv contexts with dynamic allocated ones
[12:17] <ubitux> nevcairiel: yes
[12:17] <ubitux> but actually, anton didn't change all of them
[12:17] <nevcairiel> indeed
[12:17] <nevcairiel> in fact, he added calls to init the embedded ones in a later patch
[12:18] <nevcairiel> maybe they dont care about ABI issues between lavu and lavc
[12:18] <nevcairiel> its just a matter of decision, if you want to allow mixing their versions, or not
[12:20] <durandal_1707> the intra only have already be done, they are trivial
[12:24] <durandal_1707> *should, but some are still not like targa_yuv ...
[12:25] <nevcairiel> personally, i just started at the top, not by some criteria like easy ones first =p
[12:32] <mateo`> is vp8 taken by anyone ?
[12:34] Action: durandal_1707 is only doing review of currenly done work, because there is no list of tasks you can pick and mark as taken
[12:39] <durandal_1707> nevcairiel: fate have exr samples, there is just no test because RGBA64 output is missing in sws so big endian would make fate yellow
[12:45] <durandal_1707> michaelni: you did already some new? tell when you push something
[12:46] <michaelni> iam just working on vp5/6 ...
[12:51] Action: durandal_1707 done vima
[13:08] <michaelni> vp5 & vp6 done
[13:09] <michaelni> anything from anyone that is ready to be merged ? 
[13:09] <nevcairiel> ubitux had some if you didnt get those yet
[13:10] <durandal_1707> (trivial only) vima from me
[13:12] <michaelni> ubitux, qpeg crashes with fate
[13:14] <michaelni> ubitux tiff passes fate
[13:16] <michaelni> ubitux, interplay segfaults
[13:16] <michaelni> in fate
[13:18] <michaelni> merged tiff & vima
[13:18] <michaelni> & pushed
[13:19] <michaelni> grep says 4 conflicts left
[13:19] <Bor0> is there any implementation online for frame accurate seeking backwards? I'm implementing something similar but it is a pain in the *** to do, mostly trial & error stuff, probably because of my lack of knowledge of how ffmpeg exactly does stuff
[13:19] <nevcairiel> and probably a bunch of other things that need fixing
[13:19] <nevcairiel> if anything is left when i get home from work, i'll dive into it again
[13:20] <michaelni> 11 files left that fail compile
[13:33] Action: durandal_1707 sanm done
[13:42] <michaelni> ubitux, interplay done
[13:44] <michaelni> interplay & sanm pushed
[13:49] <michaelni> xface done
[13:53] <michaelni> xan fixed
[13:58] <michaelni> v308 & v408 done
[14:03] <michaelni> yuv4 done
[14:04] <michaelni> y41p done
[14:06] <michaelni> xbm done
[14:09] <michaelni> targa_y216 done but not tested
[14:14] <michaelni> ubitux, qpeg fixed
[14:17] <michaelni> conflicts left: 0
[14:18] <michaelni> files failing build left: 0
[14:34] <michaelni> cdxl fate fixes
[14:34] <michaelni> fixeD
[14:41] <michaelni> tscc fate fixed
[14:47] <michaelni> there are some ffprobe & metadata related fate failures, didnt look yet but ubitux? saste? want to look at it ?
[14:49] <durandal_1707> michaelni: you have some style issues like " ,0" in targa_y216
[15:14] <michaelni> msmpeg4 fate fixed
[15:35] <ubitux> oups sorry i couldn't help today
[15:35] <ubitux> and i have to leave again in a few minutes
[15:38] <jojva> yo, just a heads up to inform you the MVC decoder is progressing. I'm now able to extract both left and right views almost perfectly, but only on my samples now. The first extracted frames are mostly green but as soon as a new I-picture is met everything is fine.
[17:22] <michaelni> ubitux, ffprobe fixed
[17:23] <michaelni> not sure actually what it was exactly but it started working when i fixed some crashes
[18:14] <nevcairiel> michaelni: i pushed a few small fixes
[18:40] <nevcairiel> and another one
[18:59] <michaelni> nevcairiel, i see some trailing whitespace in your tree, we wont be able to push this to ffmpeg 
[18:59] <nevcairiel> hm
[18:59] <nevcairiel> let me check
[18:59] <nevcairiel> i thought it was supposed to filter that
[19:03] <nevcairiel> wonder how git didnt yell at me
[19:03] <nevcairiel> but i fixed it and re-pushed the patches
[19:11] <michaelni> nevcairiel, merged & pushed
[19:50] <durandal11707> hmm, some nice api for queue for filters that use multiple input streams would be really nice
[19:51] <durandal11707> aMVC on BD is placed it two files (left and righ eye is separate), so stereo3d could be extended to support such input format
[19:52] <nevcairiel> its one file but two streams, and the decoder needs access to both to decode it properly, its a bit more complicated than that :d
[19:53] <durandal11707> hmm, than decoder could return frames in single stream
[19:53] <nevcairiel> the problem then is, how does it return two views at the same time
[19:54] <durandal11707> left eye in even and righ is odd frame
[19:54] <nevcairiel> probably needs an api extension in avframe or something
[19:54] <durandal11707> there is already such input format for bino
[19:54] <durandal11707> and that one is easier to implement (even for output)
[19:59] <durandal11707> but does lavfi know frame number at all?
[19:59] <nevcairiel> if its part of avframe, then it does
[22:24] <michaelni> nevcairiel or others, anyone interrested in helping fix bugs ?
[22:25] Action: michaelni just fixes a bunch of memory corruption regressions, deadlocks, null pointer dereferences 
[22:25] <michaelni> fixeD
[22:26] <michaelni> philipl, do you have a bit of time to check/update crystalhd to the new buffer ref count API ?
[22:27] <philipl> I guess. I haven't been keeping up on the changes.
[22:27] <philipl> Is there a good summary somewhere?
[22:27] <michaelni> the WIP code is there: https://github.com/michaelni/FFmpeg/tree/lavc-merge-mess 
[22:28] <michaelni> you can take a look at some commits that updated normal decoders
[22:28] <michaelni> should be more or less clear whats neeedd from them
[22:29] <michaelni> also if anyone wants to review the commits in lavc-merge-mess, that is welcome too!
[22:30] <philipl> heh. Ok. I'll take a look later this week.
[22:31] <michaelni> ok, thanks
[22:34] <nevcairiel> michaelni: any particular bugs?
[22:36] <michaelni> some fate failures remain but theres more
[22:36] <michaelni> 5 fate tests fail for me
[22:36] <nevcairiel> i ran fate earlier, and only 3 failed then o.O
[22:36] <Daemon404> oh
[22:36] <Daemon404> tilepro is still broken
[22:36] <Daemon404> unless you havent meged some fixes form libav
[22:36] <Daemon404> for atomics
[22:37] <nevcairiel> hasnt been merged yet
[22:37] <michaelni> Daemon404, feel free to cherry pick any fixes
[22:37] <Daemon404> o ok
[22:37] <Daemon404> michaelni, ill wait for a proper merge
[22:38] <michaelni> well, iam stuck with this bufref mess, it sure makes sense to cherry pick bugfixes
[22:39] <michaelni> nevcairiel, fate failures here are: fate-vsynth1-mpeg4-error, fate-vsynth2-mpeg4-error, fate-wmv8-drm, fate-filter-metadata-silencedetect, fate-filter-metadata-scenedetect
[22:40] <michaelni> nevcairiel, did any commit cause a regression ? 
[22:40] <nevcairiel> i dunno, i'm re-running fate now
[22:41] <nevcairiel> at least wmv8-drm didnt fail earlier, or the test didnt run for reasons unknown
[22:41] <nevcairiel> i'll check
[22:43] <nevcairiel> hm yeah now it fails, odd
[22:43] <nevcairiel> did i miss it?
[22:58] <nevcairiel> hm, gif also fails for me
[22:59] <michaelni> frame thread encoder fixed
[23:01] <michaelni> all 6 gif tests pass here
[23:01] <michaelni> make -j12 `make fate-list | grep gif`
[23:01] <nevcairiel> it doesnt decode at all, need to check the output
[23:02] <nevcairiel> and something in t he filter-metadata* tests crashes ffprobe
[23:02] <nevcairiel> hm
[23:02] <nevcairiel> ../fate-samples//gif/tc217.gif: No such file or directory
[23:02] <nevcairiel> woops
[23:02] <nevcairiel> :D
[23:02] <michaelni> :)
[23:03] <nevcairiel> didnt realize the tests were that new
[23:04] <nevcairiel> ok pass now
[23:29] <nevcairiel> the fate-filter-metadata-* tests are fixed, it was actually a bug in the lavfi movie source, now that the decoders output refcounted frames..
[23:32] <michaelni> nevcairiel, merged & pushed but i think theres a memleak
[23:32] <nevcairiel> it previously crashed because of a double free
[23:33] <nevcairiel> so i dunno
[23:33] <michaelni> valgrind --leak-check=full ./ffmpeg_g -f lavfi -i "amovie=fate-suite/wavpack/num_channels/eva_2.22_6.1_16bit-partial.wv" -f null -
[23:34] <nevcairiel> i cant run valgrind right now, been working on windows, but how much does it claim there leaks?
[23:36] <michaelni> nevcairiel, http://pastebin.com/AZA39EDL
[23:37] <nevcairiel> hm
[23:37] <nevcairiel> maybe the lavfi compat layer isnt good? it reads like the frames are simply not being freed after they reached ffmpeg
[23:38] <nevcairiel> because ffmpeg doesnt know about refcounted frames yet, but its supposed to work anyway
[23:41] <michaelni> maybe nicolas knows ... but he seems not on irc
[23:42] <nevcairiel> there also are buffersink.c and sink_buffer.c, the first still has merge conflicts in it, apparently its unused?
[23:49] <michaelni> i think nicolas already fixed these in master
[23:49] <michaelni> the merge is just based on a 4 days old tree
[23:50] <nevcairiel> indeed he did
[23:55] <nevcairiel> i cant find anything obviously wrong, but i'm also getting sleepy, if its not found i'll break out my linux box tomorrow and valgrind it myself
[23:58] Action: michaelni fixed the remaining fate failures
[23:59] <michaelni> also, any volunteers around to write a nice commit message for the merge like the last one ?
[23:59] <michaelni> ubitux, ?
[00:00] --- Tue Mar 12 2013