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

[burek]

[00:00] <saste> uhm michaelni: that will also require to change the fate-ffprobe references
[00:04] <ubitux> arh i'm too tired i don't want to mess up
[00:04] <ubitux> i'll push in a few hours
[00:05] <ubitux> night ppl
[00:47] <llogan> <distro_foo> "finally, ffmpeg is no longer beta."
[00:51] <Daemon404> trollolol
[00:52] <JEEBsv> yes, it is alpha as it has always been
[00:53] <JEEBsv> there is a good quote from Loren about how hard it is to keep software in alpha
[00:53] <JEEBsv> compared to going beta/final
[00:55] <llogan> I propose FFmpeg Navigator Gold
[00:56] <Skyler_> FFmpeg Enhanced Edition: Director's Cut
[00:57] <gnafu> With all new footage, where Mans shoots first!
[00:59] <Compn> whos jar jar in this scenario?
[01:04] <Daemon404> Compn, if you have to ask...
[01:27] <gnafu> "Meesa Compn Binks!"
[01:27] Action: gnafu runs away.
[08:56] <durandal_1707> why g729dec have duplicated scalarproduce function?
[09:02] <ubitux> CIA is dead :(
[09:28] <j-b> tagging a 1.0 when h264-mt is not working seems a bit pretentious...
[09:29] <durandal_1707> than, pick 0.0.0.0.0.1 alpha
[09:31] <ubitux> anyone knows a trick to automatically cp data to ref when a fate test fails?
[09:31] <ubitux> i made a change that will change a bunch of references
[09:31] <ubitux> and it's a pain to do the copies manually
[09:33] <durandal_1707> ^ :)
[09:33] <ubitux> :D
[09:33] <ubitux> it looks like it's triggering the issues even more often recently :)
[10:46] <ubitux> saste: btw, how does ffprobe behaves with "chapters"? like in mkv and such
[10:47] <saste> ubitux, don't have idea
[10:47] <saste> never tested
[10:47] <saste> ubitux, are chapters marked at the libavformat level?
[10:47] <ubitux> no idea
[10:48] <saste> how i can retrieve them, programmatically?
[10:51] <durandal_1707> saste: using lavf?
[10:51] <saste> durandal_1707, yes
[10:52] <saste> i don't know how chapters are handled in matroska, and how we handle them in lavf
[10:52] <saste> never used that feature
[10:52] <durandal_1707> there is code in mplayer that gets them
[10:52] <saste> exposing chapters in ffprobe would be useful, sure
[10:53] <durandal_1707> but isn't already available with ffmpeg?
[10:53] <saste> dunno
[11:12] <saste> ubitux: well maybe i won't have to break syntax after all
[11:12] <ubitux> :D
[11:12] <ubitux> \o/
[11:12] <saste> thanks the xml writer for that
[11:13] <saste> tags are indeed somehow "special", in the sense that you have no fixed key=>value
[11:13] <saste> so you need to embed each single one in a separate container
[11:13] <saste> in the case of XML: tags => tag => key=... val=...
[11:14] <saste> so i can mark the section like "IS_VARIABLE_ARRAY"
[11:15] <saste> and add a field to the section struct, which tells the name of the "contained elements", which will be "tag" in the case of "tags"
[11:17] <ubitux> :)
[11:17] <ubitux> meh i don't understand how i'm supposed to map the streams meta
[11:30] <divVerent> saste: there is this "standard" notation <dict><key>Key</key><string>Value</string><key>Key</key><int>42</int></dict> ;)
[11:31] <divVerent> but please don't use it, Apple invented it and it makes XPath queries for keys impossible :P
[11:32] <saste> divVerent, yes it sucks hard at first sight
[11:32] <divVerent> apple plist still sucks hard at second sight ;)
[11:32] <divVerent> I mean, why not <string key="Key">Value</string>
[11:32] <saste> the kind of stuff that big companies employees consider "smart"
[11:33] <divVerent> or even <key name="Key" type="string">Value</key> :P
[11:33] <divVerent> but then it's almost normal XML
[11:33] <divVerent> and then the patent application probably gets rejected ;)
[13:50] <iive> maybe the verbosity of the logger should be decreased?
[13:51] <iive> e.g. not reporting every change, just status changes e.g. new, closed, fixed etc.
[13:58] <ubitux> yay
[14:04] <michaelni> ubitux, about the failing threads tests, do we have a listz of which h264 files sometimes fail and the decoded output of such failures ?
[14:05] <ubitux> yes, always the same test
[14:05] <ubitux> i was also able to get a valgrind traceback at some point for the race
[14:06] <ubitux> so h264-conformance-cama2_vtc_b
[14:06] <ubitux> i don't know if it's always the same output
[14:07] <ubitux> it seems to fail always the same
[14:07] <ubitux> according to http://fate.ffmpeg.org/report.cgi?time=20120922051314&slot=x86_64-archlinux-gcc-threads-8 http://fate.ffmpeg.org/report.cgi?time=20120921165530&slot=x86_64-archlinux-gcc-threads-8 and http://fate.ffmpeg.org/report.cgi?time=20120921111134&slot=x86_64-archlinux-gcc-threads-8
[14:07] <ubitux> michaelni: do you want the valgrind trackback?
[14:08] <ubitux> michaelni: here it is: http://pastie.org/4602183
[14:09] <ubitux> it's the only time i was able to trigger it with valgrind
[14:10] <ubitux> michaelni: it seems h264-conformance-mr1_bt_a fails as well at times
[14:15] <ubitux> i don't have the generated sample though
[14:38] <ubitux> anyway, that's the only two i regularly spot, but more often h264-conformance-cama2_vtc_b
[15:16] <cbsrobot> ubitux: cross referencing the ebur128 now !
[15:17] <ubitux> yay.
[15:46] <Compn> ffmpeg went 1.0 and i didnt even notice :D
[15:46] <Compn> congrats michaelni :)
[15:48] <ubitux> not yet!
[15:51] <Compn> oh :)
[15:53] <maker> what's the planned deadline for 1.0 release?
[15:55] <j-b> after my bug is solved :0
[15:56] <maker> think there's nothing easy I can do ultil tomorrow :\
[15:56] <ubitux> j-b: got one bug?
[15:57] <j-b> many ;)
[15:57] <Compn> does vlc support libavfilter already ? 
[15:57] <maker> j-b: if there's anything I can do until tomorrow, let me know, I would be pleased to help!
[15:57] <j-b> maker: I doubt :)
[15:57] <j-b> Compn: I don't think so
[15:58] <j-b> maker: the bug is present since many months...
[15:58] <ubitux> what bug?
[15:58] <ubitux> hey i thought the rtmp thing was solved.
[16:06] <cbsrobot> ubitux ping
[16:07] <ubitux> pong cbsrobot 
[16:07] <cbsrobot> so I tried a single mono 48k pcm 24le file 
[16:08] <j-b> ubitux: the h264-mt change size one
[16:08] <cbsrobot> the m and s are not that important (or it's hard to mesure them)
[16:09] <ubitux> j-b: ooh i though you were talking about the race we sometimes have
[16:09] <cbsrobot> for I I get -29.6 LUFS, the dolby gives me -27.0 LUFS
[16:09] <ubitux> mmh
[16:09] <ubitux> cbsrobot: is that a short duration?
[16:10] <cbsrobot> LRA is 20.1 LU, Dolby is 20.2 LU - so that looks ok
[16:10] <ubitux> i think i need to ignore the processing until i have one complete window to avoid the false positive
[16:10] <Compn> j-b : theres lots of samples of h264 change res? :\
[16:10] <ubitux> cbsrobot: can you try with a longer duration?
[16:10] Action: Compn guesses tv streams
[16:10] <j-b> Compn: yep
[16:10] <cbsrobot> sure
[16:11] <cbsrobot> maybe I need to find out first, what duration dolby uses & or do you have any recommandations ?
[16:12] <cbsrobot> what would also be interesting is "True Peak"
[16:12] <ubitux> the thing is: the results at the beginning are unreliable, and over the time it might reach the same correct result
[16:12] <ubitux> i need to change something to fix that
[16:12] <ubitux> like setting a correct starting default and/or not start analyzing until i've one full window
[16:12] <ubitux> so basically it doesn't matter the duration, just make it longer :p
[16:13] <saste> ubitux: any opinion on "lavfi: store and propagate number of channels information in audio buffer properties"
[16:13] <cbsrobot> yeah - I could send you the dolby logs in csv format
[16:13] <cbsrobot> and the ffmpeg logs
[16:14] <saste> i'm going to drop the patch since it is not very useful to me, the pro is that storing the nb channels info you don't need to recompute it from chlayout, the con is that nb_channels/chlayout may be inconsistent
[16:14] <ubitux> saste: i don't find that thread
[16:14] <ubitux> cbsrobot: would be nice; if you have the input, it's even better :)
[16:15] <saste> ubitux, http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/148775
[16:16] <ubitux> ah right it's old
[16:16] <saste> yes like my duration in AVFrame thread
[16:16] <ubitux> AVFilterBufferRefAudioProps is not public?
[16:16] <saste> sure it is
[16:17] <ubitux> it's not ok to add in the middle then
[16:17] <saste> yes i'm not asking about technical problem (that was already spotted by michael)
[16:17] <saste> i'm asking if you think that the pros outweigh the cons
[16:17] <ubitux> oh.
[16:18] <ubitux> saste: i'm always a bit uncomfortable with two fields to keep in sync
[16:19] <ubitux> if it's necessary for each filter to do various checks like "do i have nb_channels? no, ok i'm going to guess it, oh ok i can't either" etc
[16:19] <ubitux> then it might not really be worth the effort :p
[16:21] <ubitux> saste: btw, any idea how we could make a movie=stillimage.png,fade=... works?
[16:21] <ubitux> it works with a movie, but not with a pic
[16:21] <ubitux> and i'm not sure how and where that could be handled
[16:24] <saste> ubitux: loop
[16:24] <saste> having duration in lavfi may help
[16:24] <Compn> ubitux : fading watermark ?
[16:24] <ubitux> saste: loop option in movie? i thought it was default to 1
[16:25] <saste> or you create a static movie from the pic, then overlay
[16:25] <ubitux> yes the intermediate movie is a solution
[16:25] <ubitux> movie=pic.png:loop=1 doesn't help
[16:26] <saste> ubitux, please read the docs
[16:26] <saste> when all else fails...
[16:36] <saste> ubitux, elaborating more, loop=1 means play the pic once
[16:37] <saste> loop=-1 means plays the movie again and again, iirc
[16:43] <ubitux> ah sorry, i should have done loop=0
[16:43] <ubitux> but it doesn't work: Unable to loop: Invalid argument
[16:43] <ubitux> :(
[16:44] <saste> uhm sounds like a bug
[16:45] <saste> or maybe that's supposed to work only with movies
[16:45] <saste> it is possibly trying to seek on an image, and failing
[16:45] <ubitux> reminds me the "bug" of unanimated gif with ffplay :(
[16:45] <ubitux> (though, mjpeg works)
[16:46] <michaelni> Topic for #cia is: CIA is dead.  https://github.com/nenolod/irker-cia-proxy may be useful when used with an implementation of the irker notification shipping protocol (of which an implementation is forthcoming)
[16:47] <JEEB> yup, http://pastebin.com/raw.php?i=9RBBniM1
[16:48] <Daemon404> lol netbsd
[16:48] <ubitux> saste: this works: ./ffplay -f lavfi -i testsrc=s=640x480 -vf "testsrc=s=256x256,format=rgba,fade=out:20:25:alpha=1 [x]; [in][x] overlay=W-w-90:50"
[16:49] <ubitux> saste: this doesn't: ./ffplay -f lavfi -i testsrc=s=640x480 -vf "movie=in.png:loop=0,format=rgba,fade=out:20:25:alpha=1 [x]; [in][x] overlay=W-w-90:50"
[16:49] <Daemon404> 19:56  <nenolod> the data was destroyed, there is no backup
[16:49] <Daemon404> ^ good work 
[16:49] <ubitux> :D
[16:49] <Daemon404> good sysadmin is good
[16:49] <saste> no data, no problem
[16:49] <saste> problem solved
[16:49] <Compn> nuke it from orbit
[16:49] <Compn> its the only way to be sure
[16:50] <Tjoppen> hardcore
[16:50] <Compn> who needs backups anyways
[16:50] <Compn> i drag shortcuts and symlinks to a floppy every week!
[16:51] <Compn> amazing it all fits 
[16:51] <ubitux> oh michael fixed the utvideo thing :)
[16:52] <michaelni> burek, can you implement something like CIA so we get commit notes again ?
[16:53] <Daemon404> ubitux, \o/
[16:53] <JEEB> I think there was someone who said he'd work on something similar
[16:53] <JEEB> http://esr.ibiblio.org/?p=4607
[16:53] <ubitux> Daemon404: \o/ to michaelni :p
[16:53] Action: Daemon404 checks atheme.org
[16:53] <Daemon404> wtf is cherokee web server
[16:53] <Compn> sounds racist
[16:53] <JEEB> notapache
[16:53] <Compn> like apache
[16:53] <Compn> stealing the great native american name :P
[16:53] Action: Compn afk
[17:42] <ubitux> http://www.w3.org/TR/ttaf1-dfxp/ AAAAAAH T_T
[17:42] <ubitux> wtf is this again :(
[17:44] <j-b> Well, classic TTML
[17:44] <ubitux> is it used?
[17:44] <j-b> no
[17:44] Action: ubitux feels safe
[17:44] Action: ubitux is going to request the w3c to delete that page, just in case
[17:44] <j-b> you cannot
[17:44] <ubitux> i can not request?
[17:47] <ubitux> http://www.unified-streaming.com/ "Support for W3C Timed Text Markup Language (TTML) for captions and subtitles."
[17:47] <ubitux> :/
[17:48] <j-b> IE10 has it too.
[17:48] <ubitux> dafuck? :))
[17:48] <ubitux> seems like there are some dash-related stuff as well
[17:49] <ubitux> seems they support webvtt as well
[17:49] <ubitux> so it will likely take over it
[17:50] <ubitux> (ie10)
[18:00] <av500> j-b: do I remember a blog post about 4 different TTML implementations=
[18:00] <av500> j-b: do I remember a blog post about 4 different TTML implementations?
[18:01] <j-b> av500: at least
[18:01] <av500> nice
[18:04] <Daemon404> lol man
[18:04] <Daemon404> the children cant play nice
[18:04] <Daemon404> so everyone has to design their own overcomplicated subtitle/tt  format
[18:04] <av500> srt should be enough for everybody
[18:04] <av500> or even that braindead frame # based one
[18:05] <Daemon404> .ass
[18:05] <Daemon404> i s what ive used for almost a decade now
[18:08] <saste> a lot of people used that
[18:09] <av500> Daemon404: no, SUB is the one that stores frame # instead of time
[18:09] <av500> my favorite
[18:10] <av500> but then, it survives frame rate changes :)
[18:11] <Daemon404> av500, i know it is
[18:11] <Daemon404> i didnt say .ass in that context
[18:11] <av500> ah
[18:12] <Daemon404> the guy who has worked a lot on stuff liek aegisub and whatnot actually wrote his thesis about designing a new subtitle format to replace .ass
[18:12] <Daemon404> its the sanest thing ive read, re: subtitle formats
[18:13] <Plorkyeran> too bad it will never be finished
[18:14] <Daemon404> of course.
[18:16] <Plorkyeran> had a p good chance of becoming the base for a w3c subtitling standard if he'd kept working on it, too
[18:24] <Daemon404> Plorkyeran, nad now look at what weve got
[18:24] <Daemon404> :/
[18:38] <ubitux> Daemon404: is the thesis public?
[18:39] <ubitux> (you're talking about the guy designing AS6, right?)
[18:39] <ubitux> the only teaser i got was a draft about some kind of ass++
[19:05] <Daemon404> ubitux, i dont knwo
[19:06] <ubitux> didn't you read it?
[19:07] <Daemon404> doesnt mean its public
[19:08] <ubitux> i wasn't implying anything :)
[19:08] <ubitux> i'd be interested in reading it
[19:11] <ubitux> saste: do you want me to review some pending ffprobe patches or you're reworking something?
[19:12] <saste> ubitux: wait since i'll have to revisit some of the already published patches
[19:12] <ubitux> ok
[19:12] <saste> it is getting more painful than i thought...
[19:12] <ubitux> :(
[19:12] <saste> but i should know better (it's always like that)
[19:13] <ubitux> the fate tests should help though :))
[19:41] <Daemon404> hmm
[20:14] <michaelni> Tjoppen, do you have time to look at "[PATCH]Support more AVC-Intra files" ?
[20:37] <Tjoppen> michaelni: oops, forgot
[20:48] <michaelni> Tjoppen, theres also "[FFmpeg-devel] [PATCH] mxfdec: allow container_ul to override codec_ul if codec is A-law" if you have time
[21:13] <ohsix> nice bug
[23:04] <cbsrobot> as long as cia is down, maybe burek could run https://github.com/mmueller/supybot-git
[00:00] --- Fri Sep 28 2012