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

[burek]

[02:10] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rd35a986404 10ffmpeg/configure: 
[02:10] <CIA-41> ffmpeg: configure: make fast_unaligned configureable
[02:10] <CIA-41> ffmpeg: Fixes Ticket1481
[02:10] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:32] <durandal_1707> if .read_header fails does .read_close get called?
[04:07] <CIA-41> ffmpeg: 03Peter Ross 07master * rc4e0e74438 10ffmpeg/libavformat/wtvdec.c: 
[04:07] <CIA-41> ffmpeg: wtvdec: return error when filetime_to_iso8601/crazytime_to_iso8601 conversion fails
[04:07] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[08:10] <ubitux> michaelni: i think c4e0e74438 introduced a memleak
[08:11] <ubitux> mmh sorry not a memleak
[08:11] <ubitux> something like buf not being set to NULL i believe
[08:12] <ubitux> ok i'm still half asleep, that shouldn't be that.
[08:13] <ubitux> missing a buf[0]=0.
[08:14] <ubitux> the if () look broken
[08:17] <ubitux> 'just sent a patch
[12:56] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rfbdb205968 10ffmpeg/libavcodec/wmaenc.c: 
[12:56] <CIA-41> ffmpeg: wmaenc: dont mess with the bitrate.
[12:56] <CIA-41> ffmpeg: The bitrate is not writeable by an encoder.
[12:56] <CIA-41> ffmpeg: Fixes generation of invalid wma
[12:56] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:08] <ubitux> oO
[15:08] <microchip_> Oo
[15:10] <CIA-41> ffmpeg: 03Clément BSsch 07master * rc855ce2671 10ffmpeg/libavformat/wtvdec.c: 
[15:10] <CIA-41> ffmpeg: lavf/wtvdec: add missing { } around if.
[15:10] <CIA-41> ffmpeg: This should fix the current failures spotted by FATE.
[15:20] <ubitux> (michaelni: added https://ffmpeg.org/trac/ffmpeg/ticket/1505)
[15:21] <ubitux> should be a relatively simple task, if anyone wants to volonteer for this
[17:06] <ubitux> michaelni: is it not possible reduce a bit all these warnings? http://pastie.org/4187751
[17:10] <michaelni> sure, lets see ...
[17:28] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r04b5eb47a6 10ffmpeg/libswresample/ (rematrix.c rematrix_template.c): 
[17:28] <CIA-41> ffmpeg: swr: fix mix* related function pointer warnings
[17:28] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:37] <ubitux> thank you :)
[17:38] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r087d067a99 10ffmpeg/libswresample/audioconvert.c: 
[17:38] <CIA-41> ffmpeg: swr: fix warning: passing argument 2 of ctx->simd_f from incompatible pointer type
[17:38] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:38] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r338509c2e1 10ffmpeg/libswresample/swresample_internal.h: 
[17:38] <CIA-41> ffmpeg: swr: fix warning: passing argument 1 of s->mix_any_f from incompatible pointer type
[17:38] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:38] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r7309451d73 10ffmpeg/libswresample/rematrix.c: 
[17:38] <CIA-41> ffmpeg: swr: fix warning: passing argument 2 of s->mix_any_f from incompatible pointer type
[17:38] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:38] <michaelni> ubitux, swr should compile without warnings now
[17:38] <ubitux> awesome, thank you :)
[17:42] <ubitux> confirmed, no more warnings here in swr
[18:13] <burek> does ffmpeg have any configurable input caching buffer
[18:13] <burek> so that users can buffer 10 seconds of input (and delay the output)
[18:13] <burek> just in case of network congestion or something
[18:22] <av500> ?
[18:22] <av500> you mean for realtime transcoding?
[18:28] <burek> yes, like remote streaming input, caching, transcoding/remuxing, output/streaming
[18:28] <burek> so if input stream is lagging (check #ffmpeg now) then ffmpeg can use data from the caching buffer, until the input stabilizes
[18:28] <burek> and then refill the buffer
[18:36] <Compn> like mplayer -cache
[18:39] <burek> I don't use mplayer, so I really don't know
[18:52] <burek> btw, ffplay does not support -map?
[18:52] <burek> how can users then select a specific program from multi ES mpegts stream?
[18:55] <kierank> there's a way iirc
[20:48] <mateo`> the new ffmpeg logo (summer edition) is awesome, especially the sun wearing sunglasses and a mustache :)
[20:50] <mateo`> i just thought a "Deal with it" text could be added just below the sun :D
[20:51] <teratorn> mateo`: hehe that would be cool
[20:51] <ubitux> :D
[20:55] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r2ceaffc627 10ffmpeg/libavcodec/resample2.c: 
[20:55] <CIA-41> ffmpeg: resample2: use av_assert()
[20:55] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:55] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r2278a3e5f7 10ffmpeg/libavcodec/vc1dsp.c: 
[20:55] <CIA-41> ffmpeg: vc1dsp: use av_assert2
[20:55] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:02] <CIA-41> ffmpeg: 03Clément BSsch 07master * r7c84e7d337 10ffmpeg/ (configure libavutil/mem.c tests/fate.sh): 
[21:02] <CIA-41> ffmpeg: mem: heap memory poisoning.
[21:02] <CIA-41> ffmpeg: Enable it by default with FATE.
[21:02] <CIA-41> ffmpeg: limitation: not random, and not supported with realloc.
[21:24] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r4ca6d206d1 10ffmpeg/libavcodec/alsdec.c: 
[21:24] <CIA-41> ffmpeg: alsdec: remove dead assignments
[21:24] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:24] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r1c2c64edac 10ffmpeg/libavcodec/proresenc.c: 
[21:24] <CIA-41> ffmpeg: proresenc: make a variable local to the loop where it is used
[21:24] <CIA-41> ffmpeg: This moves the mbs_per_slice declaration inside the only loop
[21:24] <CIA-41> ffmpeg: where it is used. Fixes a dead assignment.
[21:24] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:24] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r800ab1bafa 10ffmpeg/libavcodec/rl2.c: 
[21:24] <CIA-41> ffmpeg: rl2: remove dead assignment
[21:24] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:24] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * r33bb63cb3e 10ffmpeg/libavcodec/snowenc.c: 
[21:24] <CIA-41> ffmpeg: snow: remove a VLA.
[21:24] <CIA-41> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[21:24] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * rff8f8dfb79 10ffmpeg/libavutil/intfloat.h: (log message trimmed)
[21:24] <CIA-41> ffmpeg: intfloat: Don't use designated initializers in the public headers
[21:24] <CIA-41> ffmpeg: intfloat.h is a public header, and is now (since a1245d5ca) included
[21:24] <CIA-41> ffmpeg: by mathematics.h, which many external callers include.
[21:24] <CIA-41> ffmpeg: 03Anton Khirnov 07master * r728d2afa17 10ffmpeg/libavformat/apetag.c: apetag: reindent
[21:24] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r779f8bc24e 10ffmpeg/libavcodec/smacker.c: 
[21:24] <CIA-41> ffmpeg: smacker: remove some unused code
[21:24] <CIA-41> ffmpeg: This removes some code apparently left over from vlc reader
[21:24] <CIA-41> ffmpeg: debugging.
[21:24] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:24] <CIA-41> ffmpeg: 03Mans Rullgard 07master * ra87b17f328 10ffmpeg/libavfilter/ (vf_yadif.c x86/yadif.c x86/yadif_template.c yadif.h): 
[21:25] <CIA-41> (18 lines omitted)
[21:27] <ubitux> mmh the h264 conformance tests with threading might fail more often now with the memory poisoning
[21:28] <ubitux> (or maybe it's not related at all)
[21:43] <nevcairiel> maybe it helps finding issues, so thats good, right? :d
[21:45] <iive> in the long run. In short term, everybody would wonder why these bugs are not fixed yet.
[21:45] <Daemon404> eh? exposing bugs is a good thing.
[21:47] <ubitux> it seems not to raise any other issue
[21:47] <ubitux> so that's good so far :)
[21:47] <Daemon404> there was one failing fate trheads test anyway
[21:47] <ubitux> no, all of them
[21:48] <ubitux> randomly
[21:48] <Daemon404> nondeterminist!
[21:48] <Daemon404> the best kind
[21:48] <ubitux> a few h264 conformance ones
[21:48] <Daemon404> yea
[21:48] <ubitux> but i wasn't able to reproduce it
[21:48] <ubitux> even after 10 minutes of looping over them
[21:48] <ubitux> but sometimes yes
[21:48] <ubitux> :(
[21:48] <Daemon404> it is probably related to load
[22:01] <kierank>  In short term, everybody would wonder why these bugs are not fixed yet. --> because they are hard to fix
[22:01] <ubitux> hard to find first :p
[22:03] <kierank> there are many h264 bugs
[22:03] <ubitux> it's always two of them
[22:03] <kierank> iirc the fate tests have been setup to hide them
[22:03] <kierank> there's a list on the wiki
[22:03] <ubitux> h264-conformance-cama2_vtc_b and h264-conformance-mr1_bt_a
[22:03] <ubitux> that's the only two i spot
[22:04] <ubitux> based on all the fate threads instance failures history
[22:04] <kierank> http://wiki.multimedia.cx/index.php?title=FATE_failures
[22:12] <llogan> has anyone looked at the coverity scan results for ffmpeg recently?
[22:12] <ubitux> it is broken
[22:12] <ubitux> i don't understand why
[22:12] <ubitux> (if you're refering to lcov)
[22:16] <llogan> you need an account to view results, AFAIK.
[22:27] <Snaggle> Thanks again for ffmpeg.  Will the new so version for libavfilter (3) be pushed into ffmpeg-0.11.2, or is the 0.11 branch scheduled to stay at VERSION_MAJOR=2 for the forseable future?
[22:30] <ubitux> llogan: huh?
[22:30] <ubitux> http://lucy.pkh.me/ffmpeg-coverage/ it was here, before the failure
[22:30] <ubitux> http://lucy.pkh.me/coverage.log
[22:30] <michaelni> Snaggle, no soname bump in 0.11 planned
[22:31] <llogan> ubitux: i meant http://scan.coverity.com/all-projects.html
[22:31] <ubitux> ah my bad then
[22:31] <Snaggle> michaelni: thanks
[22:33] <michaelni> kierank, mr4 & mr5 match between ffmpeg -strict 1 and jm
[22:34] <kierank> read what it says in the wiki
[22:34] <michaelni> it says its not correct (to do what the spec says is correct) ?
[22:34] <kierank> yeah
[22:35] <michaelni> of course i also prefer it to work withoit -strict 1 ...
[22:35] <kierank> oh ok
[22:36] <michaelni> kierank, where can i find the CAVLC 444 files ?
[22:36] <kierank> http://streams.videolan.org/itu-t/h264/
[22:37] <kierank> i think in the bottom directory
[22:39] <michaelni> thx
[23:22] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r41dd30068a 10ffmpeg/doc/developer.texi: 
[23:22] <CIA-41> ffmpeg: doc/developer: refer to av_malloc() instead of malloc()
[23:22] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:22] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r2c883c6acf 10ffmpeg/libavformat/utils.c: 
[23:22] <CIA-41> ffmpeg: has_decode_delay_been_guessed: improve heuristic
[23:22] <CIA-41> ffmpeg: This allows MR4_TANDBERG_C.264 and MR5_TANDBERG_C.264 to be decoded without -strict 1
[23:22] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:22] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r1fb07be062 10ffmpeg/tests/fate/h264.mak: 
[23:22] <CIA-41> ffmpeg: fate: drop strict 1 for MR4_TANDBERG_C.264 and MR5_TANDBERG_C.264
[23:22] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:22] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rbafa1c7f38 10ffmpeg/libavcodec/ (h264.c internal.h): 
[23:22] <CIA-41> ffmpeg: h264: add avpriv_h264_has_num_reorder_frames()
[23:22] <CIA-41> ffmpeg: This function exports the exact sps.num_reorder_frames value
[23:22] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:22] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r4e9e0700fb 10ffmpeg/libavformat/utils.c: 
[23:22] <CIA-41> ffmpeg: has_decode_delay_been_guessed: skip guessing when sps.num_reorder_frames is available
[23:22] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:30] <michaelni> kierank, fixed -strict 1 need
[23:37] <nevcairiel> does running with strict 1 have any real disadvantages?
[23:38] <michaelni> yes, 16 frames delay or so
[23:40] <nevcairiel> I'm just wondering, because i'm running avcodec without avformat probing and filling the codec context properly, and as i understand it, when it manually increases the re-order buffer size, frames may be lost?
[23:44] <Daemon404> man is that pkg-config guy on the ML
[23:44] <Daemon404> like
[23:44] <Daemon404> retarded?
[23:44] <Daemon404> :|
[23:44] <Daemon404> or at leats severe readign comprehension problems
[23:44] <michaelni> nevcairiel, yes
[23:44] <ubitux> don't be so aggressive :')
[23:45] <Daemon404> arguing your point to someone who just Wont Get IT isn never fun
[23:45] <Daemon404> or that just teh ability to comprehend a situatio
[23:45] <Daemon404> n
[23:46] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * ra08efa2e36 10ffmpeg/libavformat/utils.c: 
[23:46] <CIA-41> ffmpeg: has_decode_delay_been_guessed: tighten up the heuristic.
[23:46] <CIA-41> ffmpeg: This adds the minimum delay needed with the current decoder to
[23:46] <CIA-41> ffmpeg: recognize the reorder buffer size for the reference bitstreams.
[23:46] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:46] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rb2527d5d5a 10ffmpeg/libavcodec/alsdec.c: 
[23:46] <CIA-41> ffmpeg: Revert "alsdec: remove dead assignments"
[23:46] <CIA-41> ffmpeg: This reverts commit 4ca6d206d1b5beea42c4290d2ee801aaf5cd31f0.
[23:46] <CIA-41> ffmpeg: The assignment is not dead, this should fix fate failures on BSD
[23:47] <ubitux> Daemon404: sure, but keep in mind being aggressive is likely to make the guy closing himself and insisting on his error :)
[23:47] <ubitux> though i admit you are trying to explain the issue deeply :)
[23:48] <Daemon404> ubitux, i admit to havign a low tolerance for things relating to cross-compiling
[23:48] <Daemon404> havign had to deal with N project maintainers who Just Don't Get It
[23:48] <Daemon404> (my last job was all about cross-compiling)
[23:48] <nevcairiel> it is true that cross-compiling for x64 will result in not having pkg-config available (in todays ffmpeg setup anyway), never bothered me because i dont use any of the stuff that uses pkg-config
[23:49] <nevcairiel> his solution was weird, though
[23:49] <Daemon404> and broken
[23:50] <Daemon404> I tried my best to give an example situation
[23:50] <Daemon404> i guess eitehr i utterly failed at explaining it
[23:50] <Daemon404> or he failed at comprehending
[23:50] <Daemon404> dunno which
[23:51] <ubitux> isn't he on irc anyway?
[23:51] <ubitux> might be simpler
[23:51] <nevcairiel> michaelni: so since my decoder cannot really figure out the delay when its not in the SPS, my best solution when i dont want to lose frames is to either somehow communicate the value of has_b_frames from the demuxer to the decoder, or use strict 1, or am i missing another option?
[23:54] <llogan> ubitux: as Zeranoe, IIRC.
[23:56] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rb6851d34c0 10ffmpeg/libavfilter/x86/gradfun.c: 
[23:56] <CIA-41> ffmpeg: x86/gradfun: fix compilation failure on open solaris
[23:56] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:58] <michaelni> nevcairiel, yes these are the options mostly. One could try to guess some compromise value from the profile or so too but i suspect this would be unreliable
[23:58] <nevcairiel> I wonder if the extra delay can really be "felt"
[23:58] <nevcairiel> I need a slow PC for testing, on this one i feel nothing
[23:58] <nevcairiel> it just works
[23:59] <michaelni> for realtime communication it surely can
[00:00] --- Tue Jul  3 2012