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

[burek]

[00:15] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r1dcce49e10 10ffmpeg/libavformat/soxdec.c: 
[00:15] <CIA-49> ffmpeg: soxdec: check av_malloc return.
[00:15] <CIA-49> ffmpeg: Bug found by: durandal_1707
[00:15] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:15] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * rb08a742526 10ffmpeg/libavformat/siff.c: 
[00:15] <CIA-49> ffmpeg: siff: simplify code by using ffio_limit()
[00:15] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:17] <CIA-49> ffmpeg: 03Marton Balint 07master * r708df4ac66 10ffmpeg/ffplay.c: 
[00:17] <CIA-49> ffmpeg: ffplay: remove global video state
[00:17] <CIA-49> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[00:18] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * rc8a441efe2 10ffmpeg/: 
[00:18] <CIA-49> ffmpeg: Merge remote-tracking branch 'cus/stable'
[00:18] <CIA-49> ffmpeg: * cus/stable:
[00:18] <CIA-49> ffmpeg:  ffplay: remove global video state
[00:18] <CIA-49> ffmpeg: Merged-by: Michael Niedermayer <michaelni at gmx.at>
[01:31] <durandal_1707> there is one smacker sample which do not work, header parsing in demuxer aborts
[01:34] <durandal_1707> sample is mintro.smk
[01:42] <durandal_1707> where can old bug be found?
[01:57] <drv> durandal_1707: i think that sample is truncated - it doesn't play with the official smacker player either
[01:58] <drv> but if you have mech warrior 2 sitting around, you might be able to find the original ;)
[02:02] <durandal_1707> than it should be removed from server
[02:20] <Compn> ffmpeg doesnt keep track of mime types does it ?
[02:20] <Compn> a quick grep for mime doesnt turn up much
[02:44] <durandal_1707> there is no ENOTSUP on mingw64
[02:44] Action: durandal_1707 spying
[04:18] <CIA-49> ffmpeg: 03Shitiz Garg 07master * r652d81b2c2 10ffmpeg/libavcodec/cljr.c: 
[04:18] <CIA-49> ffmpeg: cljr: Check if width and height are positive integers
[04:18] <CIA-49> ffmpeg: Width and height might get passed as 0 and would cause floating point
[04:18] <CIA-49> ffmpeg: exceptions in decode_frame.
[04:18] <CIA-49> ffmpeg: Fixes bugzilla #149
[04:18] <CIA-49> ffmpeg: Signed-off-by: Janne Grunau <janne-libav at jannau.net>
[04:18] <CIA-49> ffmpeg: 03Nathan Adil Maxson 07master * r7b3894bee9 10ffmpeg/libswscale/swscale_unscaled.c: 
[04:18] <CIA-49> ffmpeg: swscale: fix formatting and indentation of unscaled conversion routines.
[04:18] <CIA-49> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[04:18] <CIA-49> ffmpeg: 03Paul B. Mahol 07master * r2e7905eee8 10ffmpeg/libavcodec/cljr.c: 
[04:18] <CIA-49> ffmpeg: cljr: fix buf_size sanity check
[04:18] <CIA-49> ffmpeg: Signed-off-by: Janne Grunau <janne-libav at jannau.net>
[04:18] <CIA-49> ffmpeg: 03Janne Grunau 07master * r87eebb3454 10ffmpeg/libavcodec/ (h264.c h264.h h264_parser.c): 
[04:18] <CIA-49> ffmpeg: h264: skip start code search if the size of the nal unit is known
[04:18] <CIA-49> ffmpeg: Start code emulation prevention is only required in Annex B bytestream
[04:18] <CIA-49> ffmpeg: packed NAL units. For other coding formats the size is already known.
[04:18] <CIA-49> ffmpeg: Looking for a start code prefix can result in false positives like in
[04:18] <CIA-49> ffmpeg: http://streams.videolan.org/streams/mp4/Mr_MrsSmith-h264_aac.mp4
[04:19] <CIA-49> ffmpeg: avplay: clear pkt_temp when pkt is freed.
[04:19] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[04:19] <CIA-49> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[04:19] <CIA-49> ffmpeg: Signed-off-by: Justin Ruggles <justin.ruggles at gmail.com>
[04:19] <CIA-49> ffmpeg: 03Aneesh Dogra 07master * r0a6aff6936 10ffmpeg/libavcodec/vc1dec.c: 
[04:19] <CIA-49> ffmpeg: vc1: Handle WVC1 interlaced stream
[04:19] <CIA-49> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[04:19] <CIA-49> ffmpeg: 03Luca Barbato 07master * r1ee5b5e823 10ffmpeg/libavutil/ (error.c error.h): 
[04:19] <CIA-49> ffmpeg: lavu: add AVERROR_BUG error value
[04:19] <CIA-49> ffmpeg: It should be used to mark codepath that can be reached only through
[04:19] <CIA-49> ffmpeg: programming error.
[04:19] <CIA-49> (20 lines omitted)
[09:05] <ubitux> heh, 'got a surprise with ffmpeg
[09:05] <ubitux> i generated a movie from pic files recently
[09:05] <ubitux> with a number on each frame
[09:05] <ubitux> but it seems to have dropped some frames with -r 24
[09:05] <ubitux> and added one with -r 25
[09:06] <ubitux> so obviously the numbers on the frame don't really match&
[09:06] <ubitux> how am i supposed to handle this?
[09:07] <ubitux> mmh -r 25 is fine actually
[09:07] <ubitux> 24 fps might match some particular pal code i guess?
[09:17] <cbreak-work> 24 is film, 25 is pal
[09:18] <cbreak-work> 24000/1001 is ntsc-film
[09:20] <ubitux> oups morning derp
[11:06] <ubitux> a i got a crash in mxfdec: mxf_edit_unit_absolute_offset() is sent a null index table
[11:07] <ubitux> i think the check got removed in 2eba8da67572c7e9fa06191fd86312ae42116630
[11:08] <Tjoppen> checking
[11:09] <Tjoppen> I get it with 2011_DCPTEST_24FPS.V.mxf
[11:09] <ubitux> you mean you get the crash?
[11:09] <Tjoppen> yes
[11:10] <Tjoppen> well, only ffplay crashes
[11:10] <ubitux> ok i confirm it comes from this commit
[11:11] <ubitux> Tjoppen: it crashes here with ffmpeg -i a.mxf -f null -
[11:12] <Tjoppen> actually, I only get a crash with slightly older installed fftools
[11:12] <Tjoppen> you have the file cbsrobot posted yesterday, right?
[11:13] <Tjoppen> sha1sum = 8578f901e184e73108bc8dfdaf56f250bf2459b0
[11:14] <ubitux> no it's a local file i can't share unfortunately
[11:15] <ubitux> i trigger the broken or empty case
[11:15] <ubitux> empty index*
[11:15] <Tjoppen> stacktrace?
[11:16] <cbsrobot> ubitux: that's my file: http://ijghv1.dl4free.com/
[11:17] <cbsrobot> Tjoppen: ffplay and ffmpeg decode only 1 frame of it - so both don't work
[11:17] <ubitux> Tjoppen: sure, http://pastie.org/private/qfc827a7wt5dr0g5iiw
[11:18] <ubitux> cbsrobot: nice bandwidth ;)
[11:18] <cbsrobot> It ain't my server ....
[11:18] <Tjoppen> hah, derp. it's only the opatom part that is guaranteed to have an index table
[11:19] <ubitux> cbsrobot: yes, but you choose a good one :D
[11:21] <ubitux> Tjoppen: btw, if you're fixing mxf stuff, here is a good one: ./ffmpeg -i in.mxf -map 0:a out.mxf :)
[11:22] <Tjoppen> ?
[11:23] <ubitux> it leads to a floating exception
[11:23] <ubitux> because the timebase is set only when you get a video stream
[11:23] <ubitux> i'm not sure if mxf can contains only audio, or if you have to force a video stream in mxf
[11:23] <ubitux> but anyway, there is a crash with such command
[11:23] <Tjoppen> they can be audio only. it's quite common
[11:23] <ubitux> well then it doesn't work
[11:24] <ubitux> not sure if it's a regression though
[11:24] <Tjoppen> it sure seems strange
[11:26] <Tjoppen> st->codec->sample_rate = descriptor->sample_rate.num / descriptor->sample_rate.den;
[11:26] <Tjoppen> seems reasonable. didn't touch that part of the logic
[11:26] <Tjoppen> (reasonable unless den == 0 that is)
[11:29] <Tjoppen> perhaps it's supposed to use avpriv_set_pts_info()?
[11:29] <ubitux> no idea at all, all i saw is that tb being set only for video, rescaling pts with it just leads to a crash
[11:30] <ubitux> i guess avpriv_set_pts_info() as to be set for the audio stream(s) too yes&
[11:30] <Tjoppen> actually, it already does: avpriv_set_pts_info(st, 64, material_track->edit_rate.num, material_track->edit_rate.den);
[11:31] <ubitux> i didn't look closer :)
[11:31] <cbsrobot> in my understanding mxf can contain only vidoe, only audio and only subtitles
[11:33] <Tjoppen> you mean "or"?
[11:33] <Tjoppen> that would be opatom. mxf can contain "anything"
[11:35] <cbsrobot> I can send you all of them
[11:35] <Tjoppen> ubitux: wav.c doesn't set time_base
[11:36] <cbsrobot> if you need them
[11:36] <Tjoppen> happens with wav too :o
[11:36] <Tjoppen> ubitux: ./ffmpeg -i temp.wav -y -map 0:a out.mxf
[11:37] <Tjoppen> cbsrobot: yes please
[11:37] <ubitux> Tjoppen: the issue is at the encode
[11:38] <ubitux> well, muxing*
[11:38] <ubitux> you can'y just mux a mxf with audio-only
[11:39] <cbsrobot> mxf with audio only: http://5wupuj.dl4free.com/
[11:40] <cbsrobot> mxf with subtile only: http://z6f5hk.alterupload.com/
[11:41] <Tjoppen> ubitux: oh, you mean mxfenc
[11:41] <ubitux> yes
[11:41] <Tjoppen> well, that's lower priority atm :)
[11:41] <cbsrobot> the video and audio fit together - the subtitle mxf is form another project
[11:42] <cbsrobot> if you need the subtitle for the same project I need to generate some
[11:42] <ubitux> Tjoppen: i don't think muxing audio only mxf is a priority, but crash should be fixed quickly imho :)
[11:42] <ubitux> (i'm not asking you to do it, but since you were working on mxf&)
[11:42] <Tjoppen> add a ticket so we don't forget
[11:42] <ubitux> yep i'll do that
[11:42] <ubitux> do you need one for the regression?
[11:42] <ubitux> < cbsrobot> mxf with subtile only: http://z6f5hk.alterupload.com/ // haha :)
[11:43] <Tjoppen> you mean the mxf_edit_unit_absolute_offset() crash? already fixed
[11:43] <Tjoppen> I've got another set of patches to send to the list
[11:43] <ubitux> ok :)
[11:44] <ubitux> the mxf audio only doesn't play either
[11:44] <ubitux> but it doesn't crash :)
[11:45] <Tjoppen> cbsrobot: that's not very MXF-ish
[11:45] <Tjoppen> the proper way to do subtitles is temporal DMS-1 metadata
[11:45] <ubitux> cbsrobot: what's this subtitle stream?
[11:45] <Tjoppen> XML
[11:46] <ubitux> kind of xml based
[11:46] <ubitux> yes but well
[11:46] <cbsrobot> yes
[11:46] <ubitux> what's the format name?
[11:46] <Tjoppen> DCST: http://www.smpte-ra.org/schemas/428-7/2007/DCST
[11:46] <cbsrobot> it's a subtitle for dcp
[11:46] <Tjoppen> oh, 404
[11:46] <ubitux> ok
[11:46] <ubitux> the name is enough, thx
[11:47] <ubitux> i wonder when we will have the ffxml parser :)
[11:47] <Tjoppen> wrapping xml in mxf has to be the nastiest thing I've seen so far
[11:49] <cbsrobot> hehe
[11:49] <ubitux> is there only one subtitle format supported in mxf?
[11:50] <Tjoppen> check SMPTE RP224
[11:51] <Tjoppen> ^Fsubtitle -> no hits
[11:51] <Tjoppen> that file is using dark medata for the essence descriptor for the subtitle screen
[11:52] <Tjoppen> DataEssenceCoding = [00000000.0000.0000.00000000.00000000]
[11:52] <ubitux> don't have this one: (
[11:52] <cbsrobot> check https://github.com/tmeiczin/OpenDCP
[11:53] <Tjoppen> mxfdump -u reveals three pieces of dark metadata in the descriptor:
[11:53] <Tjoppen> Unknown ff.ff [060e2b34.0101.010c.01011512.00000000] = f0 7d 69 34 5e 20 4a 44 b8 cd 9a d7 ae 84 68 f0
[11:53] <Tjoppen> Unknown ff.fe [060e2b34.0101.010c.04090500.00000000] = 00 55 00 54 00 46 00 2d 00 38
[11:53] <Tjoppen> Unknown ff.fd [060e2b34.0101.0108.01020105.01000000] = 00 68 00 74 00 74 00 70 00 3a 00 2f 00 2f 00 77 00 77 00 77 00 2e 00 73 00 6d 00 70 00 74 00 65 00 2d 00 72 00 61 00 2e 00 6f 00 72 00 67 00 2f 00 73 00 63 00 68 00 65 00 6d 00 61 00 73 00 2f 00 34 00 32 00 38 00 2d 00 37 00 2f 00 32 00 30 00 30 00 37 00 2f 00 44 00 43 00 53 00 54
[11:53] <Tjoppen> the last one is a URL AFAICT
[11:54] <Tjoppen> 00 55 00 54 00 46 00 2d 00 38 = "UTF-8" in UTF-16
[11:54] <ubitux> :D
[11:55] <Tjoppen> wonderful.. the two SourceTracks have the same TrackNumber
[11:57] <Tjoppen> it probably wouldn't take much fiddling to get mxfdec.c to spit that out that xml as a packet in a AVMEDIA_TYPE_DATA stream though
[11:57] <ubitux> AVMEDIA_TYPE_SUBTITLES looks more appropriate
[11:59] <Tjoppen> maybe. or a chained demuxer of sorts
[12:03] <Tjoppen> anyway, the samples don't crash any more at least
[12:14] <Tjoppen> cbsrobot: any particular reason why the audio sample doesn't have the index in the header? it's CBR after all
[12:21] <Tjoppen> cbsrobot: the audio file is a lie
[12:21] <Tjoppen> it claims to be OPAtom, but it's not
[12:25] <cbsrobot> Tjoppen: no I didn't check it
[12:26] <Tjoppen> OPAtom only allows clip wrapping'
[12:26] <cbsrobot> I just produced it without checking the internals
[12:26] <Tjoppen> what software did you use?
[12:27] <cbsrobot> I have to check
[12:27] <cbsrobot> I got the files from a sound designer
[12:28] <cbsrobot> I'm not sure if he produced the wav himself, or if it's some sort of dolby testsuite
[12:28] <cbsrobot> i wrapped it into a mxf with opendcp
[12:28] <cbsrobot> see link above
[12:28] <Tjoppen> then opendcp fail to obey S390m
[12:29] <Tjoppen> tell them to fix their muxer :)
[12:29] <cbsrobot> hehe
[12:29] <cbsrobot> they use libasdcp if i'm not mistaken
[12:29] <Tjoppen> (though it's possible to handle this - the EssenceContainer UL indicates that the file is indeed frame wrapped)
[12:29] <cbsrobot> http://www.cinecert.com/asdcplib/
[12:30] <Tjoppen> lunch
[12:30] <cbsrobot> same
[12:30] <cbsrobot> bon app
[13:14] <OanaStratulat> michaelni: when i try to run a file through zzuf in ffmpeg it gives me some profiling errors http://pastebin.com/Jd9hYErD . any idea why?
[13:23] <OanaStratulat> michaelni: any idea?
[13:26] <merbanan> OanaStratulat: I guess --enable-coverage and zzuf doesn't work together
[13:26] <michaelni> OanaStratulat, first hit from google: http://stackoverflow.com/questions/2590794/gcov-warning-merge-mismatch-for-summaries
[13:26] <michaelni> :)
[13:27] <OanaStratulat> michaelni: yes i figured it out :D
[13:27] <merbanan> or not
[13:28] <OanaStratulat> anyway i`m remaking the ffmpeg
[13:28] <OanaStratulat> that should eliminate all the problems
[13:28] <OanaStratulat> because i had an earlier build
[13:28] <OanaStratulat> anyway got to go, speak later
[13:41] <TimN> Tjoppen: If you are doing some MXF stuff do you fancy adding in support for V210 demuxing. I have some patches which I could submit, but not being a C man would struggle to amend them if they failed review
[13:43] <Tjoppen> it already support V210, kinda
[13:44] <Tjoppen> put a sample up somewhere
[13:45] <ubitux> Tjoppen: do you have write access to ffmpeg repository or you need someone to push your patches?
[13:47] <TimN> Without the patches I get "only framed wrapped mappings are correctly supported" and "parser not found for codec v210, packets or times may be invalid"
[13:48] <Tjoppen> no push access. I don't mind though
[13:48] <Tjoppen> TimN: did you try the latest master?
[13:48] <ubitux> Tjoppen: just to know, i'm not in a position to propose that
[13:52] <TimN> Tjoppen: Well that was last week
[13:53] <Tjoppen> demuxer was partly rewritten yesterday
[13:53] <Tjoppen> *two days ago
[13:54] <TimN> OK I will give it a go after lunch..
[13:54] <Tjoppen> I have some Avid V210 samples that work at least
[13:55] <Tjoppen> and similar 8-bit samples
[13:57] <kierank> afaik v210 works ok
[13:58] <kierank> but i find the patch to change the alignment thing a bit dubious
[14:13] <TimN> So a quick recompile and it looks good, full test later.....
[15:57] <ubitux> mmh stupid math question: if sqrt(a/x) d sqrt(b/x), we have a d b right? (x being a positive integer)
[15:59] <cbreak-work> ubitux: you want to know if sqrt is monotonically increasing?
[15:59] <cbreak-work> http://en.wikipedia.org/wiki/SquareRoot :)
[15:59] <ubitux> i just want to know if sqrt(a/x) d sqrt(b/x) <=> a d b :p
[16:00] <Tjoppen> yes
[16:00] <ubitux> ok thx
[16:00] <ubitux> wanted to confirm before making a stupid mistake
[16:00] <Tjoppen> that's eq. to asking if sqrt(a) <= sqrt(b) implies a <= b, which is does
[16:00] <Tjoppen> *it does
[16:00] <ubitux> yep
[16:14] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7213215 please accept
[16:16] <michaelni> welcome back OanaStratulat, task accepted :)
[16:17] <OanaStratulat> 10x
[16:25] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7213215 marked as completed, please check if the bug is ok. it must loop the ffmpeg 
[18:15] <Tjoppen> I wonder if it's possible to have zzuf go "DING!" when something seems to have hung
[18:19] <j-b> michaelni: libavformat/sbgdec.c:1470: error: 'ENOTSUP' undeclared (first use in this function)
[18:26] <funman> hi
[18:31] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * ra8469223f6 10ffmpeg/libavcodec/alac.c: 
[18:31] <CIA-49> ffmpeg: alac: Check for bitstream overread
[18:31] <CIA-49> ffmpeg: Fixes Ticket801
[18:31] <CIA-49> ffmpeg: Bug found by: Oana Stratulat
[18:31] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:32] <CIA-49> ffmpeg: 03Derek Buitenhuis 07master * rd1c1e350c6 10ffmpeg/doc/developer.texi: 
[18:32] <CIA-49> ffmpeg: doc: make developer.texi point to correct fate doc
[18:32] <CIA-49> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[18:32] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:32] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * rc1acd58198 10ffmpeg/libavformat/idroqdec.c: 
[18:32] <CIA-49> ffmpeg: roq: fix excessive memory alloc
[18:32] <CIA-49> ffmpeg: Fixes Ticket802
[18:32] <CIA-49> ffmpeg: Bug found by: Oana Stratulat
[18:32] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:37] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r154c0a8c98 10ffmpeg/ (libavcodec/libcelt_dec.c libavformat/sbgdec.c): 
[18:37] <CIA-49> ffmpeg: replace ENOTSUP by AVERROR_PATCHWELCOME
[18:37] <CIA-49> ffmpeg: This unbreaks compilation
[18:37] <CIA-49> ffmpeg: Found by: jb
[18:37] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:38] <michaelni> j-b, thx, fixed
[18:42] <funman> Nicolas is on irc?
[18:50] <ohsix> is that error percolated up? :D
[18:51] <funman> arf
[18:51] <funman> j-b is reporting bugs in my back and taking credit for it!
[19:11] <CIA-49> ffmpeg: 03Nicolas George 07master * rb0aaf304a7 10ffmpeg/ (libavcodec/libcelt_dec.c libavformat/sbgdec.c): 
[19:11] <CIA-49> ffmpeg: Replace PATCHWELCOME by relevant error codes.
[19:11] <CIA-49> ffmpeg: This supersedes commit 154c0a8.
[19:11] <CIA-49> ffmpeg: The bug was also reported by Rafaël Carré.
[19:13] <funman> j-b: <3
[19:18] <durandal_1707> does it seems to me that vocdec.o needs riff.o in libavf?
[19:21] <durandal_1707> nvm
[19:28] <Daemon404> so uh
[19:28] <Daemon404> http://i.imgur.com/fBmrH.png <-- this can't be proper output can it?
[19:32] <durandal_1707> i have same duplicated stuff
[19:34] <Daemon404> doesnt seem right
[19:39] <durandal_1707> heh i was not aware that elinks have nice gui for selecting attachment
[19:41] <Daemon404> using a text-based web browser...
[19:41] Action: Daemon404 facepalms
[19:42] Action: gnafu uses ELinks for some things when he's already in a terminal and all he needs is text.
[19:43] <Daemon404> the only thing i use like that is w3m, for the occasional man replacement
[19:43] <Daemon404> lolmanpages
[19:44] <gnafu> I use w3m when I need decent image support :-P.
[19:45] <Daemon404> i use a gui browser.
[19:45] <Daemon404> and gui email client.
[19:45] Action: gnafu uses Firefox most of the time.
[19:45] <Daemon404> yeah
[19:45] Action: gnafu uses web-based e-mail "clients" :-P.
[19:46] Action: Daemon404 svn up's clang, and rebuilds
[20:09] <durandal_1707> so does clang improve decoding/encoding performance comparing to gcc? (for stuff that do not use yasm)
[20:09] <Daemon404> durandal_1707, from what i understand,clang can be hit and miss
[20:09] <Daemon404> ive had it speed up some stuff on arm
[20:09] <Daemon404> and x86
[20:10] <Daemon404> (icc is surely better on x86)
[20:10] <Daemon404> and apple's internal fork of clang is probably much better for arm
[20:10] <Daemon404> or armcc
[20:10] <Daemon404> i use clang cause it's compiler warnings/errors are about a billion times more useful than gcc's.
[20:10] <Daemon404> its*
[20:24] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7215209 please accept
[21:02] <lionaneesh> Hey all
[21:02] <michaelni> hi lionaneesh 
[21:03] <lionaneesh> michaelni: Hey
[21:03] <lionaneesh> Wassup.
[21:04] <michaelni> lots of work, like always :)
[21:04] <lionaneesh> michaelni: I just wanted to know something about FFMPEG command
[21:04] <lionaneesh> and how can i get the most of the stuff included 
[21:05] <lionaneesh> I mean , I wanted to test FFMPEG including its all components
[21:05] <lionaneesh> ffmpeg -i <file> -f null - << Is this cool
[21:05] <michaelni> the internal components should all be enabled by default
[21:05] <Daemon404> michaelni, did you see my paste earlier?
[21:05] <michaelni> Daemon404, 2xversion ?
[21:05] <Daemon404> yeah
[21:05] <Daemon404> i dont really want to attempt to touch ffmpeg.c
[21:05] <Daemon404> <.<
[21:05] <Daemon404> it scares me.
[21:06] <michaelni> stdin & stderr 
[21:06] <Daemon404> so it's supposed to?
[21:06] <michaelni> id say no
[21:07] <Daemon404> yeah
[21:09] <lionaneesh> michaelni: This program is not developed anymore and is only provided for compatibility. Use avconv instead (see Changelog for the list of incompatible changes).
[21:09] <lionaneesh> Whats this ^
[21:09] <Daemon404> it means youre not using ffmpeg's git
[21:09] <Daemon404> you're using libav's
[21:10] <Daemon404> git://git.videolan.org/ffmpeg.git
[21:10] <Daemon404> ^
[21:10] <Daemon404> use this
[21:10] Action: durandal_1707 hides in dark
[21:11] <pasteeater> git://source.ffmpeg.org/ffmpeg.git looks nicer
[21:11] <Daemon404> pasteeater, same thing though
[21:11] <pasteeater> yes
[21:21] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7215209 please review 
[21:23] <michaelni> OanaStratulat, null pointer dereference in indeo5 confirmed
[21:26] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7216212 please accept
[21:31] <Tjoppen> FATE doesn't do any fuzzing, right?
[21:32] <michaelni> Tjoppen, one of the ppcs does when it overheats ;)
[21:32] <Tjoppen> hah
[21:33] <Tjoppen> I was thinking it can't be that hard to take fate-demux* and use zzuf to turn them into fuzz tests
[21:33] <michaelni> yep
[21:33] <Tjoppen> I don't actually know much about Makefile writing though. maybe it's time to learn
[21:34] <Tjoppen> did some mxfdec fuzzing today. patchset incoming tomorrow
[21:37] <Tjoppen> some of the funny cases are those that don't crash but take way too long time
[21:38] <michaelni> reminds me of the avi bug where the eof check was after a do we have this stream then continue
[21:39] <Tjoppen> mostly whenever there's a table that gets partly filled out, then the demuxer rewinds (because it read past the end of the klv) and eventually the metadata parsing spends minuts going over a bogus set of keys or something
[21:40] <Tjoppen> I'm thinking merely checking that it never seeks back in those cases (forward being OK)
[21:41] <Tjoppen> anyway, I'll come up with something tomorrow
[21:49] <durandal_1707> heh first zuffing of kgv1.avi sample resulted in segfautl
[22:02] <Tjoppen> yeah, sometimes it's rather embarassing
[22:02] <Tjoppen> I actually just looked here: http://caca.zoy.org/wiki/zzuf/bugs
[22:03] <Tjoppen> a bit old though of course
[22:04] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7216212 please review
[22:12] <michaelni> OanaStratulat, ok
[22:14] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7218214 please accept
[22:15] <cbsrobot> Tjoppen: I checked with your patches in mxf_fixes_20111220, but the dcptest.v.mxf still does not decode
[22:16] <Tjoppen> possibly. but it doesn't crash
[22:16] <cbsrobot> yes
[22:16] <cbsrobot> it just decodes 1 frame (or less)
[22:16] <Tjoppen> wasn't that jpeg2000?
[22:16] <cbsrobot> yes
[22:17] <Tjoppen> are you sure it isn't a decoder problem?
[22:17] <cbsrobot> hmmm - let me check
[22:17] <Tjoppen> since it's experimental and all
[22:17] <cbsrobot> but I thing the decoding is done with openjpeg
[22:18] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7218214 please accept
[22:18] <cbsrobot> and as I said, avconv decodes it
[22:18] <michaelni> OanaStratulat, done
[22:19] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7218214 please review
[22:20] <Tjoppen> I see. so I need --enable-libopenjpeg I presume
[22:21] <cbsrobot> yes
[22:21] <cbsrobot> so "avconv version N-33762-g284aa07" decodes the stream
[22:22] <cbsrobot> ffmpeg version N-36007-g9d50387 does not <- with the patches from your branch
[22:25] <durandal_1707> bt from gdb is useless for this kega crash
[22:25] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r452406bd5b 10ffmpeg/ (7 files): 
[22:25] <CIA-49> ffmpeg: ff*: Fix duplicatedly printed version info with -version
[22:25] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:26] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * rf27930cd9a 10ffmpeg/libavcodec/ivi_common.c: 
[22:26] <CIA-49> ffmpeg: indeo5: Fix null pointer dereference
[22:26] <CIA-49> ffmpeg: Fixes Ticket803
[22:26] <CIA-49> ffmpeg: Bug found by: Oana Stratulat
[22:26] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:27] <Tjoppen> cbsrobot: ok
[22:30] <OanaStratulat> michaelni: any luck?
[22:36] <michaelni> OanaStratulat, done, good work
[22:39] <j-b> funman: 18:19 <@j-b> michaelni: libavformat/sbgdec.c:1470: error: 'ENOTSUP' undeclared (first use in this function) 18:26 -!- funman [~fun at rockbox/developer/funman] has joined #ffmpeg-devel
[22:41] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7225205 please accept
[22:42] <michaelni> done
[22:44] <pob> hi all, I wonder if some would have 5min to help me with a muxing application
[22:46] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7225205 please review 
[23:09] <funman> j-b: np
[23:13] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7226206 please accept
[23:15] <OanaStratulat> michaelni: 10x
[23:15] <Daemon404> i really wish melange was better
[23:15] Action: Daemon404 thinks having to manually accept every task is bound to drive people insane
[23:17] <cbsrobot> Tjoppen: I bisected and ddcf3e0535191a776728d0ecabc71c6dddf05dd1 is the bad apple
[23:17] <cbsrobot>  mxfdec: Index table driven demuxing and seeking
[23:18] <cbsrobot> although I think you already knew that...
[23:20] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7226206 please review, i think it is a bug, in the valgrind report not all the mem is freed 
[23:36] <OanaStratulat> michaelni:  any luck?
[23:39] <michaelni> definitely lost: 616 bytes in 3 blocks
[23:39] <michaelni> thats not much
[23:40] <OanaStratulat> ok, going to submit another one
[23:41] <OanaStratulat> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7226206 check again with 2 files, i think it`s a segfault
[23:52] <OanaStratulat> michaelni: are the files good for a bug?
[00:00] --- Wed Dec 21 2011