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

[burek]

[00:01] <ubitux> mmh fate doesn't use the _g binary...
[00:01] <ubitux> the valgrind output is not really helpful
[00:03] <ubitux> ah great, TOOL option.
[00:03] <Diana_Muscalu> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7197333 marked as completed, waiting for review
[00:04] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r1f273c2bf2 10ffmpeg/ffmpeg.c: 
[00:04] <CIA-49> ffmpeg: ffmpeg: check return code from av_vsrc_buffer_add_frame()
[00:04] <CIA-49> ffmpeg: Fixed Ticket770
[00:04] <CIA-49> ffmpeg: Bug found by: Diana Elena Muscalu
[00:04] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:10] <Diana_Muscalu> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7176257 please accept
[00:12] <michaelni> done
[00:14] <Diana_Muscalu> 10x
[00:17] <Diana_Muscalu> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7176257 marked as completed, waiting for review
[00:19] <Diana_Muscalu> michaelni: do you know what time is at the google server now? when does it make 16th to release the tasks ?
[00:25] <michaelni> Diana_Muscalu, is the file supposed to segfault ?
[00:25] <Diana_Muscalu> michaelni: yes
[00:27] <michaelni> its not segfaulting for me, it does cause somewhat excessive memory allocation though
[00:27] <Diana_Muscalu> michaelni: i think i have mistaken the file, how can i modify the ticket on trac to edit the name?
[00:30] <Diana_Muscalu> michaelni: sorry, i have noted in a .txt that creates an memory exceeded now i see dunno why i have named it sig11
[00:32] <michaelni> Theres a "Modify Ticket"
[00:33] <michaelni> if it wasnt then it is there now, as ive just added "dianamuscalu" to the developer group on trac
[00:34] <michaelni> Diana_Muscalu, so the file is just supposed to allocate a gb and no segfault ?
[00:34] <michaelni> its ok i just want to make sure i have the right file
[00:34] <Diana_Muscalu> michaelni: only memory exceeded no sig11
[00:34] <Diana_Muscalu> sorry for my mistake
[00:34] <Diana_Muscalu> changed the name of the ticket
[00:35] <michaelni> ok, closed task
[00:37] <Diana_Muscalu> michaelni: i have a file which creates a loop but how can i find the seed when it does that?
[00:38] <michaelni> zzuf -v prints the seeds it uses IIRC
[00:38] <Diana_Muscalu> thx
[00:47] <Diana_Muscalu> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7185249 please accept
[00:48] <michaelni> done
[00:49] <Diana_Muscalu> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7185249 this is a loop for 15 minutes is running, hope it is good. marked as completed
[00:54] <pasteeater> apparently people living in italy can not be mentor
[00:55] <pasteeater> not that i am, but i wonder why
[00:58] <kierank> lol
[00:58] <Diana_Muscalu> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7187253 please accept
[00:59] <michaelni> done
[00:59] <Diana_Muscalu> michaelni: 10x
[01:02] <pasteeater> kierank: i thought quebec was lol'er
[01:03] <durandal_1707> is there any video encoder in FFmpeg which use differential coding (something like DPCM for audio)
[01:05] <CIA-49> ffmpeg: 03Carl Eugen Hoyos 07master * r56669837ce 10ffmpeg/libavcodec/v210dec.c: Fix typo in v210 decoder options.
[01:06] <Diana_Muscalu> michaelni: if i have a file bigger than 2.5mb where can i put it? can i put it on my FTP and share the link?
[01:07] Action: durandal_1707 found answer for stupid question
[01:08] <michaelni> Diana_Muscalu, yes, sure
[01:08] <Diana_Muscalu> k
[01:12] <Diana_Muscalu> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7187253 marked as completed, awaiting review
[01:22] <ubitux> michaelni: i'm not sure, but it seems all the valgrind failures come from a memleak
[01:23] <ubitux> http://pastie.org/3023797
[01:23] <ubitux> i have that kind of .err
[01:23] <ubitux> i'm not sure why it is considered a failure though
[01:24] <ubitux> mmh and i need to run it with ffmpeg_g, --enable-debug isn't enough&
[01:25] <Diana_Muscalu> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7196355 please accept 
[01:27] <michaelni> done
[01:27] <michaelni> ubitux, --disable-stripping should work too
[01:28] <ubitux> oh perfect
[01:28] <ubitux> thx
[01:32] <CIA-49> ffmpeg: 03Martin Storsjö 07master * r1b35af3225 10ffmpeg/libavcodec/libgsm.c: 
[01:32] <CIA-49> ffmpeg: libgsm: Reset the MS mode of GSM in the flush function
[01:32] <CIA-49> ffmpeg: The mode is set in libgsm_decode_init, but the decoder
[01:32] <CIA-49> ffmpeg: object is simply destroyed and recreated in the flush
[01:32] <CIA-49> ffmpeg: function - therefore the mode has to be set again.
[01:32] <CIA-49> ffmpeg: This fixes playback using the libgsm_ms decoder in avplay.
[01:32] <CIA-49> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[01:32] <CIA-49> ffmpeg: 03Mans Rullgard 07master * rf7de52354f 10ffmpeg/libavcodec/arm/dca.h: 
[01:32] <CIA-49> ffmpeg: ARM: dca: disable optimised decode_blockcodes() for old gcc
[01:32] <CIA-49> ffmpeg: Old gcc versions have trouble compiling this function, and
[01:32] <CIA-49> ffmpeg: no simple, targeted test is possible.
[01:32] <CIA-49> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[01:32] <CIA-49> ffmpeg: 03Martin Storsjö 07master * r8637af8d24 10ffmpeg/libavcodec/libgsm.c: 
[01:32] <CIA-49> ffmpeg: libgsm: Set options on the right object
[01:32] <CIA-49> ffmpeg: This fixes regressions in decoding using the libgsm_ms decoder,
[01:32] <CIA-49> ffmpeg: broken since 0eea21294354.
[01:32] <CIA-49> ffmpeg: Signed-off-by: Janne Grunau <janne-libav at jannau.net>
[01:32] <CIA-49> ffmpeg: 03Derek Buitenhuis 07master * r6c3abd70fd 10ffmpeg/tests/ (fate2.mak ref/fate/v410dec ref/fate/v410enc): 
[01:32] <CIA-49> ffmpeg: fate: Add FATE tests for v410 encoder and decoder
[01:32] <CIA-49> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[01:32] <CIA-49> ffmpeg: Signed-off-by: Diego Biurrun <diego at biurrun.de>
[01:32] <CIA-49> ffmpeg: 03Diego Biurrun 07master * r44b7e1b942 10ffmpeg/tests/ (Makefile fate/atrac.mak fate2.mak): fate: split off ATRAC FATE tests into their own file
[01:32] <CIA-49> ffmpeg: 03Diego Biurrun 07master * r055c61b857 10ffmpeg/configure: configure: refactor list of programs into a variable
[01:32] <CIA-49> ffmpeg: 03Diego Biurrun 07master * r6146d78d35 10ffmpeg/tests/ (Makefile fate.mak fate/indeo.mak): fate: split off Indeo FATE tests into their own file
[01:33] <CIA-49> ffmpeg: 03Janne Grunau 07master * ref5756aee0 10ffmpeg/tests/fate2.mak: 
[01:33] <CIA-49> (19 lines omitted)
[01:34] <Diana_Muscalu> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7196355 marked as completed, awaiting review 
[01:35] <ubitux> michaelni: seems good, thanks a lot: http://pastie.org/3023830
[01:35] <ubitux> fixing that memleak should fix a lot of valgrind failures
[01:37] <ubitux> all the memleaks come from here
[01:38] <ubitux> there is an invalid read in mov too
[01:41] <michaelni> ubitux, i think this one is difficult to fix, that is IIRC, i dont remember exactly
[01:41] <michaelni> that is the memleak i didnt look at what mov does
[01:42] <michaelni> Diana_Muscalu, done, ok it eats 1.8gb
[01:42] <Diana_Muscalu> michaelni: when will google release the next wave of tasks?
[01:43] <michaelni> i have no idea ...
[01:43] <ubitux> michaelni: http://pastie.org/3023855  this is for the mov
[01:44] <Diana_Muscalu> anyway i think i`ll close the night here, these 2 days really killed me up.
[01:44] <ubitux> mmh wtf is wrong with the system& it is 64bits with 32 bits adresses&
[01:44] <ubitux> i suspect the hacky kernel to be the cause&
[01:59] <Diana_Muscalu> ppl i`m off, good night
[01:59] <ubitux> 'night :)
[02:37] <CIA-49> ffmpeg: 03Carl Eugen Hoyos 07master * r9994643fdd 10ffmpeg/libavcodec/libavcodec.v: 
[02:37] <CIA-49> ffmpeg: Export ff_vdpau_vc1_decode_picture().
[02:37] <CIA-49> ffmpeg: XBMC's configure script checks for this function in installed
[02:37] <CIA-49> ffmpeg: libavcodec.so to determine VDPAU support.
[02:37] <CIA-49> ffmpeg: Fixes ticket #762 reported by Christian Marillat
[02:37] <CIA-49> ffmpeg: 03Carl Eugen Hoyos 07release/0.9 * r866d5c958f 10ffmpeg/libavcodec/libavcodec.v: 
[02:37] <CIA-49> ffmpeg: Export ff_vdpau_vc1_decode_picture().
[02:37] <CIA-49> ffmpeg: XBMC's configure script checks for this function in installed
[02:37] <CIA-49> ffmpeg: libavcodec.so to determine VDPAU support.
[02:37] <CIA-49> ffmpeg: Fixes ticket #762 reported by Christian Marillat
[02:37] <CIA-49> ffmpeg: (cherry picked from commit 9994643fdd6c06b4f986be8879953a139fbd1a40)
[02:38] <ohsix> what a silly
[02:44] <ubitux> :/
[02:53] <bcoudurier> MP4_maniac, isom doesn't requires 'iods'
[02:53] <bcoudurier> 'mp42' yes
[02:53] <bcoudurier> and 3gp/f4v/m4a certainly doesn't require it
[02:53] <j-b> bcoudurier: salut
[02:53] <bcoudurier> hey j-b
[02:55] <MP4_maniac> bcoudurier: mp42 doesn't requires iods. mp42 requires iods only when mp42 has presentation as far as i understand
[02:55] <bcoudurier> well yes
[02:55] <bcoudurier> but not being a presentation is hard in this context
[02:55] <bcoudurier> :)
[02:56] <bcoudurier> btw, that's mainly why lavf uses 'isom' and not mp42
[02:56] <Guest85066> hi guys,i want to use ffmpeg  open DVD files,and how to auto open all vob files in dvd
[02:56] <bcoudurier> quicktime uses mp42 even though it doesn't write iods
[02:56] <MP4_maniac> Apple doesn't use any object descripters, so it is ok
[02:57] <bcoudurier> humm, iods is conditional on presentation not object descriptors AFAIR
[02:57] <j-b> why adding ff_vdpau_vc1_decode_picture ?
[02:58] <j-b> seems a weird work-around
[02:58] <ohsix> because xbmc is dumb, lets add more random public symbols ;]
[03:01] <michaelni> if iam not mistaken it was removed without ABI bump ...
[03:01] <MP4_maniac> bcoudurier: iods is initial object descripter, right? also i have never seen mp4 without M4V and/or M4A brand created quicktime/itunes these don't requires object descripter
[03:03] <michaelni> MP4_maniac, iam planing to disable iods by default, unless someone has some objections
[03:05] <bcoudurier> 14496-14: Sub-part of a presentation, contains an IOD without a BIFS stream (MP4 file);
[03:06] <bcoudurier> you have to explicetely choose MPEG-4 in quicktime to export as mp42
[03:07] <bcoudurier> there was a thread about this a long time ago on ffmpeg-devel
[03:07] <bcoudurier> http://ffmpeg.org/pipermail/ffmpeg-devel/2006-February/010364.html
[03:07] <bcoudurier> If it is a
[03:07] <bcoudurier> presentation or the target of an OD URL, an iods is required, containing
[03:07] <bcoudurier> an IOD or OD respectively.
[03:13] <MP4_maniac> michaelni: i think it is ok. absense of iods means the file is created as edit use
[03:16] <bcoudurier> yup
[03:27] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * rc402c1c976 10ffmpeg/libavformat/smacker.c: 
[03:27] <CIA-49> ffmpeg: smackerdemuxer: check some values before instead of just after malloc()
[03:27] <CIA-49> ffmpeg: Fixes Ticket777
[03:27] <CIA-49> ffmpeg: Bug Found by: Diana Elena Muscalu
[03:27] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:27] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * re2a16e82b1 10ffmpeg/libavformat/westwood.c: 
[03:27] <CIA-49> ffmpeg: westwooddemux: dont require avio_size() functionality.
[03:27] <CIA-49> ffmpeg: Found by reimar
[03:27] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:29] <j-b> ohsix: exactly my point
[04:58] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r0988a6a035 10ffmpeg/ (4 files in 4 dirs): 
[04:58] <CIA-49> ffmpeg: movenc: disable iods by default
[04:58] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[04:58] <CIA-49> ffmpeg: Approved-by: MP4_maniac
[04:58] <CIA-49> ffmpeg: Approved-by: Baptiste Coudurier
[04:58] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r84e57702ea 10ffmpeg/configure: 
[04:58] <CIA-49> ffmpeg: configure: disable avconv again.
[04:58] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[04:58] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r1f99939a63 10ffmpeg/libavcodec/j2k_dwt.c: 
[04:58] <CIA-49> ffmpeg: j2kdec: Fix integer overflow leading to a segfault
[04:58] <CIA-49> ffmpeg: Fixes Ticket776
[04:58] <CIA-49> ffmpeg: Bug found by: Diana Elena Muscalu
[04:58] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[05:35] <plushka> Hi all! Who can answer a few questions?
[05:44] <Compn> easy questions or tough questions ?
[05:46] <plushka> I can not independently determine the level. But I can try to ask a question: When i make ffmpeg falls much WARNING*. How much is normal?
[05:49] <Compn> a lot is normal
[05:49] <Compn> warnings you can ignore, errors are bad
[05:50] <plushka> Compn, it's i understand. Thx
[06:25] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * re098fba5d9 10ffmpeg/libavformat/avidec.c: 
[06:25] <CIA-49> ffmpeg: avidec: Fix infinite loop caused by rounding of timestamps in non interleaved avis.
[06:25] <CIA-49> ffmpeg: Fixes Ticket775
[06:25] <CIA-49> ffmpeg: Bug found by: Diana Elena Muscalu
[06:25] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[06:25] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * rf72601d063 10ffmpeg/libavformat/txd.c: 
[06:25] <CIA-49> ffmpeg: txddemux: Limit allocated packets to filesize.
[06:25] <CIA-49> ffmpeg: Fixes Ticket772
[06:25] <CIA-49> ffmpeg: Bug found by: Diana Elena Muscalu
[06:25] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[06:25] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * ra000975444 10ffmpeg/libavformat/thp.c: 
[06:25] <CIA-49> ffmpeg: thp: simplify overallocate checks.
[06:25] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[06:25] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r62adc60b97 10ffmpeg/libavformat/avidec.c: 
[06:25] <CIA-49> ffmpeg: avidec: Check that the header chunks fit in the available filesize.
[06:25] <CIA-49> ffmpeg: Fixes Ticket771
[06:25] <CIA-49> ffmpeg: Bug found by: Diana Elena Muscalu
[07:30] <ubitux> [Fri, 16 Dec 2011 03:22:40 +0100 :: fate]
[07:30] <ubitux> [Fri, 16 Dec 2011 05:01:24 +0100 :: end]
[07:30] <ubitux> hehe
[07:30] <ubitux> 1h40 for a fate+valgrind on the celeron ;)
[09:38] <Tjoppen> read_close() isn't called if read_header() fails, right?
[11:22] <Tjoppen> there we go, fairly pretty patches
[11:28] <Tjoppen> should intermediate patches also pass FATE btw? it felt a little silly updating a ref only to revert it back in a future commit
[11:29] <nevcairiel> I guess fate should pass after your patch series
[11:29] <Tjoppen> yeah, it does. I'm thinking it might be annoying for people doing say a bisect and landing on one of them
[11:55] <Tjoppen> https://github.com/Tjoppen/FFmpeg/tree/proper_mxf_track_linking   I'll post that to the list
[12:06] <Tjoppen> there we go
[12:36] <Node_685> Hi,  what FF_BUG_NO_PADDING is used for?...thx
[13:57] <Tjoppen> bcoudurier: any thoughts on the recent patch set?
[13:59] <vivienschilis> I have issues to encode  1080p videos, and I use git master
[13:59] <vivienschilis> original videos plays well in vlc or ffplay
[13:59] <vivienschilis> but the encoded video freezes during around 10 seconds
[13:59] <vivienschilis> also if I do -an
[13:59] <vivienschilis> the encoding gets cuts where previously it was just freezing
[13:59] <vivienschilis> how can I debug that guys, any idea?
[15:20] <michaelni> vivienschilis, if it worked before, git bisect
[15:22] <vivienschilis> michaelni, no idea if it worked before, but I have this bug quite often on 1080p videos
[15:22] <vivienschilis> I will try to compile an older version
[15:28] <iive> vivienschilis: do you use threading?
[15:29] <iive> and you said encoding...
[15:30] <vivienschilis> I am re-trying without thread 
[15:30] <vivienschilis> I encode to h264
[15:30] <vivienschilis> from a MOV h264/aac
[15:31] <vivienschilis> I have to file but it take 20min to download
[15:31] <vivienschilis> the*
[15:31] <vivienschilis> wget http://watchmojo-widget.s3.amazonaws.com/c97050dc50d2c5d5ece90351d13d7ee3.mov
[15:32] <vivienschilis> ffmpeg -ss 55 -i c97050dc50d2c5d5ece90351d13d7ee3.mov -threads 1 -vcodec libx264 -an -crf 22 -t 30 -vf "scale=-1:360" -r 29.97 -loglevel debug -y output.mp4
[15:33] <vivienschilis> I do -ss and -t to make my debug faster
[15:33] <CIA-49> ffmpeg: 03Dominique Leuenberger 07master * r39f59a8da7 10ffmpeg/RELEASE: 
[15:33] <CIA-49> ffmpeg: RELEASE: We're now at 0.9.0.git
[15:33] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:33] <CIA-49> ffmpeg: 03Michael Niedermayer 07release/0.9 * rf600d709f0 10ffmpeg/ffplay.c: 
[15:33] <CIA-49> ffmpeg: ffplay: Fix got_frame type.
[15:33] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:33] <CIA-49> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[15:33] <CIA-49> ffmpeg: (cherry picked from commit a5a1e3cb8a5f554818c2e491ab4d2cad833a4556)
[15:33] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:33] <CIA-49> ffmpeg: 03Michael Niedermayer 07release/0.9 * reee78ef30d 10ffmpeg/ffplay.c: 
[15:34] <CIA-49> ffmpeg: ffplay: clear pkt_temp when pkt is freed.
[15:34] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:34] <CIA-49> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[15:34] <CIA-49> ffmpeg: (cherry picked from commit efe8a1ba08dd868e5a96f5759258b0733bb2004c)
[15:34] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:34] <CIA-49> ffmpeg: 03Michael Niedermayer 07release/0.9 * r388e3e7853 10ffmpeg/libavcodec/ac3dec.c: (log message trimmed)
[15:34] <vivienschilis> remove -an , add -acodec libfaac to see the freezing
[15:34] <CIA-49> ffmpeg: 03Michael Niedermayer 07release/0.9 * rde69052b1a 10ffmpeg/libavcodec/mjpegdec.c: 
[15:34] <CIA-49> ffmpeg: ljpeg: Check that lowres is 0 as lowres is not possible with ljpeg.
[15:34] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:34] <CIA-49> ffmpeg: 03Panagiotis H.M. Issaris 07release/0.9 * r2a66a65341 10ffmpeg/ (doc/ffplay.texi ffplay.c): 
[15:34] <CIA-49> ffmpeg: ffplay: add 10 minute seek support to ffplay
[15:34] <CIA-49> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[15:34] <CIA-49> ffmpeg: (cherry picked from commit 91a3ea671adda0039c6c221f158a88391416b574)
[15:34] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:34] <CIA-49> ffmpeg: 03Marton Balint 07release/0.9 * r964d75735f 10ffmpeg/ffplay.c: 
[15:34] <CIA-49> (17 lines omitted)
[16:03] <prunedtree> hello
[16:04] <prunedtree> I have suggestions to make to greatly improve the speed of all codecs using median-prediction or single-table VLC entropy coding (ie most lossless intra codecs)
[16:05] <prunedtree> I'm wondering if anyone would be interested in intregrating these to ffmpeg
[16:07] <microchip_> prunedtree: talk to michaelni
[16:08] <prunedtree> well I suppose he reads this channel, yes ?
[16:08] <microchip_> yes, just ping him
[16:08] <prunedtree> okay
[16:09] <iive> prunedtree: how is this going to help with speed on existing codecs?
[16:10] <prunedtree> it's bitstream compatible
[16:10] <prunedtree> so it can apply to ffvhuff, huffyuv, VBLE, etc...
[16:11] <prunedtree> can't apply to utvideo because it's median prediction is seriously flawed
[16:12] <iive> well, i'm quite sure all our encoders need a little bit more care...
[16:15] <prunedtree> for median prediction, it's just for decoders
[16:15] <prunedtree> entropy coding can be improved for both
[16:18] <prunedtree> right now the fastest median predictor ffmpeg uses is a sequential ISSE implementation, which uses 6 cycle/byte at best from my testing (ffmpeg's might be a little bit slower)
[16:19] <prunedtree> I have an implementation that takes 1.6 cycle/byte (cycle times on a nehalem CPU)
[16:20] <prunedtree> this is nothing revolutionnary, it's just the `obvious' parallelization along diagonals
[16:20] <prunedtree> dataflow is not completely trivial though
[16:22] <prunedtree> and for entropy coding, it's just the fact that most of those codecs have expected entropy in the ~3 bps range, and encode all successive symbols with the same VLC sequentially
[16:22] <prunedtree> this is quite subtoptimal as you can relatively easily decode many more symbols per LUT lookup in expectation
[16:23] <prunedtree> speedups on order 4x for both entropy coding and decoding are reachable
[16:24] <iive> i still don't understand what you are talking about.
[16:24] <prunedtree> are you familiar with how huffyuv works ?
[16:24] <iive> to be honest i haven't messed with it.
[16:25] <prunedtree> well, you can make it faster. much
[16:25] <prunedtree> and a few other codecs like it
[16:26] <prunedtree> and I don't think creating yet another lossless intra codec would be much use to the community
[16:26] <iive> i've heard it uses median, but it needs the result of the previous pixel, so you can't do it easy in parallel.
[16:26] <prunedtree> right
[16:26] <prunedtree> but if look at the dataflow, you can do pixel [x,y] and [x-1,y+1] in //
[16:27] <prunedtree> and continue along the left-down diagonal
[16:27] <iive> i think this looks like xvid thread support.
[16:28] <prunedtree> it might be a similar sitation with macro-block encoding, yes
[16:28] <vivienschilis> michaelni, ok the video encodes normally on 0.6
[16:28] <vivienschilis> but not on 0.7
[16:29] <vivienschilis> to 0.9
[16:29] <vivienschilis> I will try to find a commit id
[16:29] <Cosmin> michaelni: i have completed this task http://google-melange.appspot.com/gci/task/view/google/gci2011/7185250
[16:29] <iive> prunedtree: do you aim at multi-thread support or SIMD optimization?
[16:29] <prunedtree> this SIMD optimization
[16:29] <prunedtree> you can also add MT support on top if you want
[16:30] <prunedtree> I think this is of very dubious value for codecs that are capable of 500 MB/s encoding/decoding on a single thread 
[16:30] <prunedtree> also, the improvement to entropy coding is algorithmic
[16:30] <iive> :) We have a saying here "Appetite comes with the meal".
[16:31] <prunedtree> code ?
[16:31] <prunedtree> or proof of concept app
[16:31] <prunedtree> I come here because I tried to make a utvideo decoder to demonstrate those ideas, but utvideo turns out to be flawed :/
[16:32] <iive> i mean, if you make it, somebody would find use for it.
[16:32] <iive> well, i think huffyuv is not exactly standard codec, so if you want to implement new format, you could probably try it.
[16:33] <prunedtree> I have absolutely no use for that code (I could say `I did it for the lulz')
[16:33] <prunedtree> I certainly don't want to handle VFW or anything like that
[16:33] <prunedtree> I'm just looking if someone wants to pick up were I left. I did the proof of concept, it just needs to be productized
[16:34] <iive> I mean, people will find a way to use it. E.g. that camera that can take pictures faster than the light travels ;)
[16:34] <iive> you don't have to worry about vfw and dshow, ffdshow incorporates almost all ffmpeg codecs, so it would be supported almost out of the box.
[16:35] <iive> in time.
[16:35] <Cosmin> michaelni: are you here?
[16:35] <prunedtree> well, if you started from scratch you'd use different entropy coding and prediction that's even faster (that's what I did first)
[16:36] <prunedtree> I just had a huffman+median code as a baseline, and in the pursuit of fair competition, it ended up faster than anything out there
[16:36] <iive> I've heard pengvado discussing a ways to improve huffyuv, but it was years ago, so I guess he may have abandoned it.
[16:36] <prunedtree> so I tought it could be worth integrating back into existing stuff
[16:36] <prunedtree> so it's not lost
[16:37] <prunedtree> well my median recovery code is possibly very easy to integrate into ffmpeg
[16:39] <iive> well, if you can improve compression without hurting the speed, it would be valuable option. A lot of people used ffv1 just for its better compression, even if it was painfully slow. You can just name your codec ffv2 :)
[16:40] <iive> it uses cabac/cavlc .
[16:40] <prunedtree> I find there's very little value in higher compression for lossless codecs
[16:40] <prunedtree> modelling noise is not fun
[16:41] <prunedtree> and unless you are very I/O limited it's of limited use as well
[16:42] <prunedtree> I also find puzzling people insist on lossless coding... of 8-bit, or worse, downsampled chrominance formats
[16:42] <prunedtree> near-lossless compression of a high-bit 4:4:4 format would achieve far higher quality at much lower rates
[16:43] <iive> I don't see anything strange in that, if I'm capturing from TV that already have downsampled chroma.
[16:43] <prunedtree> and terrific noise levels
[16:44] <prunedtree> lossless encoding of that is a complete waste of bits
[16:45] <merbanan> prunedtree: post your ideas to the mailinglist
[16:45] <JEEB> wow, that almost makes you feel like those people who push ProRes for everything >_>
[16:45] <JEEB> ("visually lossless")
[16:45] <iive> well, I guess the noise is the main reason to want lossless encoding. So you can try something more powerful to remove it later, without some encoder adding its own vision of artifacts. 
[16:46] <prunedtree> jeeb: well I'd insist on more than transparency I suppose. having a near-lossless codec able to re-encode it's own output losslessly at the same rate is a nice property to have
[16:46] <michaelni> prunedtree, havnt read the backlog but do you have a patch ?
[16:47] <prunedtree> well we'll have to meet in the middle
[16:47] <prunedtree> I'd rather not build ffmpeg
[16:48] <prunedtree> so I'd be greatful is some regular contributor could help 
[16:50] <iive> so you are looking for a mentor.
[16:50] <vega13> does libav use an other sdl configuration then ffmpeg?
[16:51] <prunedtree> iive: btw you make a point about how conservative smoothing, while it can't hurt denoising performance in theory, will hurt the assumption of constant noise level denoiser universally make
[16:51] <prunedtree> iive: I don't think I need mentoring, but yes, perhaps ?
[16:54] <michaelni> prunedtree, what kind of help can we provide ?
[16:54] <iive> prunedtree: the easiest way is to clone a copy of ffmpeg, and work on it. when you have something that could be merged tell michaelni to do it.
[16:58] <prunedtree> iive: as I said, I don't want to build ffmpeg
[16:59] <prunedtree> michaelni: well for the median prediction, I can give you my implementation, but it'll need porting
[17:00] <Daemon404> it's still ssse3 right?
[17:00] <prunedtree> and I doubt plain assembly will pass the standards of quality 
[17:00] <prunedtree> Daemon404 : right, you would be the ideal person to help me if you had time :P
[17:01] Action: Daemon404 wonders how much of that time is spent learning SIMD
[17:01] <prunedtree> well you can help me for the entropy coding
[17:01] <prunedtree> no SIMD involved ! :P
[17:01] <prunedtree> you can even make VBLE much faster lol
[17:01] <prunedtree> (it'll be easier to apply to VBLE first, given the fixed structure of the entropy coder)
[17:02] <michaelni> prunedtree, why dont you want to build ffmpeg, it would be alot faster than one of us porting your code ?
[17:02] <prunedtree> that particular code I have is x64/ssse3, but I don't think that's a very strong requirement... it could be ported to lesser ISAs... I think ISSE would be the baseline
[17:02] <prunedtree> michaelni: I don't have a C compiler
[17:03] <prunedtree> well, I do, but frankly I just dread projects such as ffmpeg
[17:03] <iive> prunedtree: btw, coding standard for entry have been greatly reduced after the fork.
[17:04] <michaelni> more correctly "cosmetic" standards
[17:04] <prunedtree> my code isn't C though
[17:04] <Daemon404> isn't it clay
[17:05] <ohsix> lesser isas :D
[17:05] <ohsix> in the x86 universe that's a pretty funny remark
[17:05] <ohsix> for some measure of how better x86_64 is than x86_32
[17:06] <iive> prunedtree: is it in SmallTalk?
[17:07] <prunedtree> heh, it almost seems like you know me :)
[17:07] <prunedtree> but now, I wouldn't write high performance code in smalltalk
[17:09] <prunedtree> I doubt you want code that looks like that: http://pastebin.com/NmMDWEs5
[17:10] <Daemon404> generate from intrinsics?
[17:10] <Daemon404> generated
[17:10] <Daemon404> *
[17:11] <prunedtree> right. that's just an edited assembly dump 
[17:12] <michaelni> we need something that can be build with yasm or gcc inline asm and some change to the C to interface with it
[17:13] <Daemon404> i dont think adding gcc inline asm is a good idea
[17:13] <Daemon404> >.>
[17:13] Action: Daemon404 shudders
[17:13] <Cosmin> michaelni: http://google-melange.appspot.com/gci/task/view/google/gci2011/7185250 hope now it is good, there is no output because it hangs open
[17:13] <prunedtree> if there is a way to compile to ffmpeg on windows that's simple, failproof and doesn't require either cygwin or visual studio (mingw is fine) I could give it a try I suppose
[17:14] <JEEB> yeah
[17:14] <Daemon404> you can either use msys + mingw
[17:14] <Daemon404> or ssh into someone
[17:14] <michaelni> Cosmin, moment ill take a look
[17:16] <prunedtree> well it could also be a task for someone looking to learn x86 SIMD and such
[17:16] <JEEB> just don't get msys/mingw from Sourceforge :P
[17:16] <JEEB> you'll end up gathering packages from their crappy web UI
[17:17] Action: Daemon404 aint lookin to learn x86 simd atm... 
[17:17] Action: Daemon404 is seeing why clang-built ffmpeg crashes on avc
[17:17] <prunedtree> someone else obviously :D
[17:18] <Daemon404> JEEB, btw i ditched native mingw and am cross-compiling clang now
[17:18] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r559ae20dda 10ffmpeg/libavformat/utils.c: 
[17:18] <CIA-49> ffmpeg: lavf: Update AVIOContext.maxsize when hitting the end.
[17:18] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:18] <Daemon404> so much faster
[17:18] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r207d9eab5a 10ffmpeg/libavformat/ (txd.c westwood.c): 
[17:18] <CIA-49> ffmpeg: txd/westwood: remove demuxer specific overallocate solutions as the new generic code
[17:18] <CIA-49> ffmpeg: handles it fine.
[17:18] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:18] <Daemon404> >.>
[17:18] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * ree181f84a3 10ffmpeg/libavformat/utils.c: 
[17:18] <CIA-49> ffmpeg: lavf: print an error if a packet has been truncated due to filesize
[17:18] <CIA-49> ffmpeg: in av_get_packet()
[17:18] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:18] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * rf890cb948c 10ffmpeg/libavformat/mtv.c: 
[17:18] <CIA-49> ffmpeg: mtvdemuxer: fix segfault caused by truncated packets.
[17:18] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:19] <michaelni> Cosmin, no loop with the second file either
[17:19] <michaelni> also ffmpeg should at leastr print its version
[17:19] <michaelni> even if it ends in a infinite loop later
[17:19] <Cosmin> michaelni: it prints it`s version
[17:19] <Daemon404> prunedtree, you are free to ssh into my dev vm <.< >.>
[17:19] Action: Daemon404 runs
[17:19] <Cosmin> michaelni: but after that there is no output
[17:19] <Cosmin> michaelni: have you tried to zzuf the files with the arguments i have posted?
[17:20] <Cosmin> michaelni: and then run it into ffmpeg
[17:20] <michaelni> Cosmin, please copy & paste the output you get no matter how little to the tockt780 on trac
[17:20] <Cosmin> okei
[17:20] <Cosmin> michaelni: have you run the file through the zzuf?
[17:20] <michaelni> Cosmin, yep i copy & pasted the zzuf command and just fixed the directories
[17:21] <Cosmin> michaelni: that mens that my system is crappy
[17:21] <michaelni> maybe your version of ffmpeg is old ?
[17:21] <Cosmin> michaelni: please return with needs more work and i`ll work on another bug
[17:21] <Cosmin> michaelni: it`s the latest, cloned from git yesterday
[17:22] <michaelni> well git pull --rebase
[17:22] <michaelni> i commited some bugfixes very recently
[17:22] <Cosmin> michaelni: okok, but i`ll try for the future only to search for sig11 and sig9 because i have 4gb ram on my machine
[17:24] <michaelni> ok
[17:28] <buzz_> the google code bug hint thing is going well. 
[17:28] <buzz_> i noticed how many they found (and how many you fixed)
[17:34] <bcoudurier> Tjoppen, I'm looking at it
[17:34] <bcoudurier> btw 0 index duration is definitely OK
[18:04] <prunedtree> <+Daemon404> prunedtree, you are free to ssh into my dev vm <.< >.> << I'm not a huge fan of remote developpement
[18:04] <prunedtree> I optimized GPU kernels 10000 km away from the machine
[18:04] <prunedtree> it was... an experience
[18:04] <Daemon404> lol
[18:05] <JEEB> well, setting up msys/mingw isn't exactly hard nowadays
[18:05] <JEEB> Daemon404 knows that
[18:05] <prunedtree> protip: reboot X if you crash fglrx once, or you loose your machine ;)
[18:05] <prunedtree> JEEB: doesn't he use linux ?
[18:05] <Daemon404> prunedtree, ive debugged X itself remotely
[18:05] <Daemon404> hardware vnc
[18:05] <Daemon404> :V
[18:05] <JEEB> prunedtree, both
[18:06] <Daemon404> i run windows, linux, bsd
[18:06] <JEEB> you just have to remember who keeps an up-to-date package of most needed msys/mingw packages from SF in a neat single pack
[18:06] <prunedtree> ^^;
[18:06] <prunedtree> sounds complicated
[18:06] <Daemon404> and who doesnt fucking break their mingw build
[18:06] <Daemon404> by optimizing it for core2
[18:07] <JEEB> yeah
[18:10] <prunedtree> and where can I find that ?
[18:10] Action: Daemon404 turns to jeeb for that
[18:10] <JEEB> oi
[18:10] <JEEB> lol
[18:10] <JEEB> someone just pastebin the needed parts of the log I wrote for you :V
[18:11] <Daemon404> herp derp
[18:11] <prunedtree> also, I have nfi how to format that code for ffmpeg :/
[18:12] <prunedtree> I'm not looking forward to spend a lot of time adapting code for a codebase I'm not familiar with
[18:12] <Daemon404> prunedtree, it's simpyl k&r style
[18:13] <prunedtree> nah, I mean idioms
[18:13] <Daemon404> ah
[18:13] <prunedtree> how you scan over image buffers, all those things
[18:13] <prunedtree> or how the DSP facilities are even supposed to work
[18:14] <Daemon404> you would only be implementing one of teh dsp functions no?
[18:14] <prunedtree> fundamentally, my approach is little more than a 16x16 byte transpose
[18:14] <Daemon404> er, would it work on a line-by-line basis then?
[18:14] <prunedtree> yeah, but there are 3 asm loops + scalar pre/post processing
[18:14] <prunedtree> 16 lines for the main loop
[18:14] <Daemon404> i see
[18:14] <prunedtree> also needs a scratch buffer
[18:15] <prunedtree> 512x16 for instance, to fit in L1
[18:15] <Daemon404> all the huff code would need to be feactored then
[18:15] <Daemon404> the current media restore simd functions work on a line-by-line basis
[18:15] <prunedtree> the huff code works on a planar basis I think
[18:15] <Daemon404> median*
[18:15] <prunedtree> oh
[18:15] <prunedtree> I understood wrong then
[18:15] <prunedtree> any that kind of change is relatively trivial... for someone used to the codebase
[18:15] <prunedtree> anyways
[18:16] <Daemon404> http://libav.org/doxygen/master/dsputil_8c_source.html#l01921
[18:16] <Daemon404> this is relevant to you
[18:17] <prunedtree> right, it would be the add_hfyu_median_prediction_c
[18:17] <Daemon404> there's also a releveant commit for you
[18:17] <Daemon404> that shows exactly how to add a simd version
[18:17] <Daemon404> for that exact function
[18:17] <prunedtree> would have to be 16 lines @ once, and have access to a scratch buffer
[18:18] <prunedtree> and then it would still need a mix of C and asm code, so I don't even know how you guys deal with it
[18:18] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=3daa434a40c56deef91c9d545552349d661105e9
[18:19] <prunedtree> but it would be ~10x faster (than the C version, even with asm-optimised `mid-pred')
[18:20] <Daemon404> michaelni, poke me when youre around
[18:20] <prunedtree> Daemon404: I've seen that asm code before actually, it's very similar to what utvideo (and one of my testing loops) do
[18:21] <prunedtree> it's the 4x slower ones... about twice as fast as cmovs though
[18:21] <Daemon404> prunedtree, i was more using as an example of how to add a new simd version
[18:21] <Daemon404> ;P
[18:22] <prunedtree> oh
[18:22] <prunedtree> patch-wise
[18:22] <michaelni> Daemon404, iam here but always busy ...
[18:23] <prunedtree> Daemon404: it would be more tricky because of the change of interface to the C function
[18:23] <Daemon404> prunedtree, true
[18:23] <prunedtree> also, I have nfi how you give access to scratch buffers to dsp functions 
[18:24] <prunedtree> allocating 8 KB on the stack isn't really great practice
[18:24] <Daemon404> michaelni, hmmm nvm for now
[18:46] <michaelni> Daemon404, what was it that i can help you with ?
[18:46] <Daemon404> ill show you in just a sec
[18:57] <Daemon404> michaelni, i got it sorted out
[18:57] <Daemon404> just fixed the two problems with that wavpack patch
[19:15] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r902c090413 10ffmpeg/libavcodec/h264.c: 
[19:15] <CIA-49> ffmpeg: h264: reset nal_unit_type so that decoding frames without any nal units
[19:15] <CIA-49> ffmpeg: dont leave its value at something random.
[19:15] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:15] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r227960427b 10ffmpeg/libavcodec/h264.c: 
[19:15] <CIA-49> ffmpeg: h264: retuen the amount read in case of NAL_END_SEQUENCE
[19:15] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:15] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r3d07e0aba0 10ffmpeg/libavcodec/h264.c: 
[19:15] <CIA-49> ffmpeg: h264: return the consumed amountg in case of Q264
[19:15] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:00] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * rcf7076ee96 10ffmpeg/ffmpeg.c: 
[21:00] <CIA-49> ffmpeg: ffmpeg: exit() on repeated ctrl-c
[21:00] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:00] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r7b92863f30 10ffmpeg/ffmpeg.c: 
[21:00] <CIA-49> ffmpeg: ffmpeg: Fix killing [Y/n] prompt with ctrl-c
[21:00] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:00] <CIA-49> ffmpeg: 03Michael Niedermayer 07master * r6d8e6fe9db 10ffmpeg/libavcodec/dpcm.c: 
[21:00] <CIA-49> ffmpeg: CODEC_ID_SOL_DPCM: Fix used write buffer.
[21:00] <CIA-49> ffmpeg: Bug found by: Oana Stratulat
[21:00] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:00] <CIA-49> ffmpeg: 03Shitiz Garg 07master * r4af0262f7d 10ffmpeg/libavcodec/cljr.c: 
[21:00] <CIA-49> ffmpeg: cljr: Check if width or height are positive integers
[21:00] <CIA-49> ffmpeg: width and height might get passed as 0 and would cause floating point
[21:00] <CIA-49> ffmpeg: exceptions in decode_frame.
[21:00] <CIA-49> ffmpeg: Fixes bugzilla #149
[21:00] <CIA-49> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:07] <ubitux> michaelni: http://fate.ffmpeg.org/report.cgi?time=20111216214632&slot=x86_64-archlinux-gcc-valgrind
[23:33] <Cosmin> michaelni : http://www.google-melange.com/gci/task/view/google/gci2011/7185250
[23:37] <michaelni> Cosmin, good work, i can confirm the segfault
[23:39] <michaelni> ubitux, great
[23:40] <ubitux> well there are two main failures; i wonder why not all tests are run though
[23:41] <ubitux> if the leak & the mov issues are fixed, it should make all the current tests green
[23:41] <ubitux> but i didn't check every single test
[23:42] <Cosmin> http://www.google-melange.com/gci/task/view/google/gci2011/7209212
[23:42] <Cosmin> please accept
[23:42] <michaelni> Compn, done :)
[23:44] <michaelni> s/Compn/Cosmin/
[23:45] Action: michaelni kicks his IRC clients auto nick completion
[23:48] <iive> michaelni: if you use xchat, there is option to auto-complete in least recently used/walked manner. 
[23:48] Action: Daemon404 ctcp versions michaelni 
[23:48] <iive> oops... wrong most recently talked
[23:48] <iive> whatever you get the idea.
[23:48] <Daemon404> none :i
[23:48] <Daemon404> nice
[23:50] <Cosmin> michaelni : http://www.google-melange.com/gci/task/view/google/gci2011/7209212 please review
[23:54] <michaelni> Cosmin, i see no signal nor crash
[23:55] <Cosmin> on my machine it gives me a signal 6
[23:55] <Cosmin> it says that the bytes received are not as expected
[23:56] <Cosmin> you have the valgrind report
[23:56] <cbsrobot> michaelni, Tjoppen : I've some problems reading mxf files with ffmpeg
[23:56] <Cosmin> and there it is an error
[23:56] <cbsrobot> avconv works
[23:56] <michaelni> Cosmin, it just prints some errors, no signal
[23:56] <michaelni> no crash
[23:56] <Cosmin> okok, i`ll find another one
[23:57] <cbsrobot> ffmpeg tells me : [mxf @ 0x10200e800] failed to find absolute offset of 5a7 in BodySID 1 - partial file?
[23:57] <cbsrobot> ah maybe it's regression
[23:57] <michaelni> cbsrobot, Tjoppen posted some patches 
[23:58] <michaelni> maybe they fix it
[23:58] <cbsrobot> yes I saw them
[23:58] <michaelni> i was waiting for bcoudurier to have a chance to review them before i apply them
[23:58] <cbsrobot> ok
[23:59] <cbsrobot> by the way - can I ask some stupid mt questions ?
[00:00] --- Sat Dec 17 2011