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

burek burek021 at gmail.com
Thu Apr 19 02:05:03 CEST 2012


[00:41] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r5e8280d177 10ffmpeg/libavutil/samplefmt.h: avutil: add better documentation for AVSampleFormat
[00:41] <CIA-17> ffmpeg: 03Alex Converse 07master * rca332b1d8c 10ffmpeg/libavcodec/libfaac.c: faac: Add .channel_layouts
[00:41] <CIA-17> ffmpeg: 03Samuel Pitoiset 07master * rb3b1751201 10ffmpeg/libavformat/rtmpproto.c: 
[00:41] <CIA-17> ffmpeg: rtmp: Support 'rtmp_playpath', an option which overrides the stream identifier
[00:41] <CIA-17> ffmpeg: This option is the stream identifier to play or to publish.
[00:41] <CIA-17> ffmpeg: Sometimes the URL parser cannot determine the correct
[00:41] <CIA-17> ffmpeg: playpath automatically, so it must be given explicitly
[00:41] <CIA-17> ffmpeg: using this option (ie. -rtmp_playpath).
[00:41] <CIA-17> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[00:41] <CIA-17> ffmpeg: 03Samuel Pitoiset 07master * r6465562e13 10ffmpeg/libavformat/rtmpproto.c: 
[00:41] <CIA-17> ffmpeg: rtmp: Support 'rtmp_app', an option which overrides the name of application
[00:41] <CIA-17> ffmpeg: This option is the name of application to connect on the RTMP server.
[00:41] <CIA-17> ffmpeg: Sometimes the URL parser cannot determine the app name automatically,
[00:41] <CIA-17> ffmpeg: so it must be given explicitly using this option (ie. -rtmp_app).
[00:41] <CIA-17> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[00:42] <CIA-17> ffmpeg: 03Carl Eugen Hoyos 07master * raf2f655c02 10ffmpeg/libavcodec/libfaac.c: 
[00:42] <CIA-17> ffmpeg: faac: Fix multi-channel ordering
[00:42] <CIA-17> ffmpeg: Signed-off-by: Alex Converse <alex.converse at gmail.com>
[00:42] <CIA-17> ffmpeg: 03Alex Converse 07master * r9fb7e14635 10ffmpeg/libavcodec/ (aac.h aacdec.c aacsbr.c): 
[00:42] <CIA-17> ffmpeg: aacdec: More robust output configuration.
[00:42] <CIA-17> ffmpeg: Save the old output configuration (if it has been used
[00:42] <CIA-17> ffmpeg: successfully) when trying a new configuration. If the new configuration
[00:42] <CIA-17> ffmpeg: fails to decode, restore the last successful configuration.
[00:42] <CIA-17> ffmpeg: 03Diego Biurrun 07master * rdb6e26d70c 10ffmpeg/libavcodec/dv_tablegen.h: dv_tablegen: Drop unnecessary av_unused attribute from dv_vlc_map_tableinit().
[00:42] <CIA-17> ffmpeg: 03Justin Ruggles 07master * r8099fc763b 10ffmpeg/libavformat/riff.c: 
[00:42] <CIA-17> ffmpeg: riff: use bps instead of bits_per_coded_sample in the WAVEFORMATEXTENSIBLE header
[00:42] <CIA-17> ffmpeg: This matches the value for the plain WAVEFORMATEX header.
[00:42] <CIA-17> ffmpeg: Also fixes stream copy to WAVE for non-16-bit raw pcm.
[00:42] <CIA-17> ffmpeg: 03Justin Ruggles 07master * rb1041f8048 10ffmpeg/avconv.c: 
[01:05] <michaelni> Daemon404, ive put a av_log() in planarCopyWrapper and rund swscale-test, planarcopywrapper does get called
[01:06] <michaelni> but maybe i misunderstood
[01:06] <Daemon404> strange
[01:06] <Daemon404> ill retest tonight.
[01:49] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r68526dbc29 10ffmpeg/libavcodec/aacdec.c: 
[01:49] <CIA-17> ffmpeg: aacdec: reduce difference to alexs version of aacdec.c
[01:49] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:50] <taqattack> Hey everyone.
[01:51] <taqattack> When I tried to run FFmpeg convert directshow input to stream for RTMP, I get huge memory usage (close to 1.8GB). Any idea why that could be?
[01:59] <Compn> taqattack : give us an example command line so we may reproduce
[02:00] Action: Daemon404 has a feeling it is some rouge dshow filter
[02:03] <taqattack> http://pastebin.com/SgpttCAZ
[02:05] <taqattack> Yeah I'm suspecting it to be a directshow problem as well. I ran it with native rtmp and librtmp. It happens when I'm recording to harddrive as well but not as often.
[02:08] <Compn> surprised you got it working from my email instructions :)
[02:09] <Compn> taqattack : try a smaller res and see if it gets the same mem leak as fast ?
[02:10] <Compn> or maybe try with 1 thread
[02:10] <Compn> not sure if dshow can handle 4 threads
[02:10] <ohsix> it's com, things can be apartment threaded
[02:10] <Compn> i mean ffmpeg's dshow implementation
[02:11] <ohsix> right
[02:11] <Compn> you mr smart guy
[02:11] <Compn> in other words
[02:11] <Compn> try to make command line smaller, by throwing out options, see if you find the reason
[02:12] <ohsix> if ffmpeg is making assumptions about things being free threaded or whatever when they call into com, DOOM
[02:13] <ohsix> com will insert adapters when there's a mismatch but you still need to comply with one of the types
[02:14] Action: Compn inserts a COM into ohsix
[02:16] <ohsix> but if it doesn't crash it shouldn't make the elements go crazy either; can ffmpeg's dshow thing register the graph it builds for debugging?
[02:16] <ohsix> you can open registred graphs with graphedit
[02:16] <Compn> tell him to install valgrind on windows while you're at it
[02:18] <ohsix> http://msdn.microsoft.com/en-us/library/windows/desktop/ms695276%28v=vs.85%29.aspx
[02:19] <ohsix> eh, start with opening it from the ROT w/graphedit
[02:19] <ohsix> you will see any weird filter elements that shouldn't be there, if they're all signed or microsoft provided you can probably ignore them
[02:19] <taqattack> Just ran it with smaller resolution: http://pastebin.com/f6nV2aT3
[02:19] <taqattack> The memory problem is still there
[02:20] <taqattack> Should I take out the -threads command?
[02:20] <Compn> yes
[02:20] <Compn> try just recording it to local harddrive
[02:20] <Compn> i want to narrow down the problem exactly.
[02:21] <ohsix> http://msdn.microsoft.com/en-us/library/windows/desktop/dd390650%28v=vs.85%29.aspx
[02:21] <ohsix> it's probably ffdshow, does it drop late frames or anything from the directshow source?
[02:22] <ohsix> -ffdshow
[02:22] <ohsix> +ffmpeg
[02:25] <taqattack> Yeah it drops frames when I take out "-rtbufsize 100000000"
[02:25] <taqattack> It's not giving me the error when I try to output to harddrive now. But it happens occasionally.
[02:26] <ohsix> anyways, it's easy to rule out dshow when you look at it with graphedit
[02:52] <burek> is there anyone willing to help create a wiki page at ffmpeg's trac wiki about compiling ffmpeg statically?
[02:52] <ohsix> if they're going to deal with the license hassle they should figure it out themselves, no? or if they're going to ignore the licenses ... ;]
[02:53] <ohsix> you could always reverse engineer the build process of someone already doing that, too
[02:53] <burek> well, I'd like to round it up, in the complete guide, for those that want it
[02:54] <burek> now, if they are going to abuse it, well.. it's the same case as with guns factories :)
[02:54] <ohsix> yea, not really
[02:54] <burek> but I deeply believe that more people will start using ffmpeg if there is an option to just download-and-run it
[02:55] <ohsix> for your own personal use it's not even really very useful to build statically
[02:55] <burek> how come
[02:56] <burek> well, here is the (use) case for static build
[02:56] <burek> people often use apt-get install ffmpeg
[02:56] <burek> they don't want to bother (or play around) with compiling things
[02:56] <burek> they find it to be "nice and clean" philosophy.. install/uninstall
[02:57] <burek> and that's fine
[02:57] <burek> but when they hit the bug, they are always asked to use the latest git
[02:57] <burek> and there comes the trouble.. a lot of them will mostly avoid doing it
[02:57] <burek> simply searching for another tool that will do their job
[02:57] <burek> and who loses in such scenario? well guess :)
[02:57] <ohsix> what if their philosopy involves them not believing in computers, how will you support them using ffmpeg
[02:58] <burek> come on, this is very common scenario
[02:58] <burek> experienced mostly in #ffmpeg
[02:58] <ohsix> you should see from all the bundled license violations that the people who want that use case do just fine
[02:59] <burek> what does license violation has got to do with this case at all?
[02:59] <burek> we can make gpl static build
[02:59] <burek> and offer it for people to download
[03:00] <silverrocker> what does idc stand for?
[03:05] <burek> Image Density Control?
[03:08] <burek> silverrocker, the closest match i've found is IDC level here: http://www.avidemux.org/admWiki/doku.php?id=tutorial:h.264
[03:08] <Compn> burek : you mean the static builds at zeranoe's site for win32 users ?
[03:08] <Compn> what are you guys talking about :)
[03:08] <burek> Compn, I was more interested in linux 32/64 builds
[03:09] <burek> because no need to reinvent the wheel right? :)
[03:09] <Compn> you'll never get it into apt-get , the distros dont like static
[03:09] <burek> that's not the goal
[03:09] <Compn> ah
[03:10] <Compn> so i'm guessing theres something wrong with just compiling --enable-static or whatever
[03:10] <burek> I'll put the download link somewhere for people to download it, unofficially, just so that they can have the latest git version
[03:10] <Compn> ah
[03:10] <burek> because we loose a lot of bug reports due to people not wanting/knowing to compile things
[03:11] <Compn> right
[03:11] <Compn> so what problem do you get when you pass the cflag=-static ?
[03:11] <burek> well, I'd like to do it right
[03:12] <burek> that's all
[03:12] <burek> I tried it myself, got the working builds
[03:12] <burek> created cron job to build new binary each day (with git pull)
[03:12] <burek> just to find out that on some machines ffmpeg says even -h option not recognized :S
[03:12] <burek> so fail :)
[03:12] <Compn> lol
[03:13] <silverrocker> burek: in the code you have variables ending with _idc all the time. I was wondering what it was
[03:13] <Compn> since there is no runtime cpu detection in ffmpeg , are you compiling with --disable-optimizations ?
[03:13] <burek> let me tell you exactly :)
[03:13] <burek> http://ffmpeg.gusari.org/static/
[03:13] <burek> scroll just a little bit down
[03:13] <Compn> no i'd rather guess for another hour
[03:13] <Compn> :P
[03:13] <burek> and see the configure options
[03:13] <burek> :)
[03:14] <Compn> did you strace to see why -h was failing ? (or what it reads)
[03:14] <burek> so, that's the magic tool :$
[03:14] Action: burek is writting down: strace
[03:15] <Compn> strace is evil evil tool
[03:15] <Compn> ;)
[03:16] <burek> so, cflags=-static should make it totally static?
[03:16] <Compn> no 
[03:16] <Compn> what you have
[03:16] <Compn> --enable-static
[03:16] <Compn> should do it
[03:17] <Compn> your binaries are very tiny tho
[03:17] <burek> gzipped? :)
[03:18] <Compn> i guess
[03:18] <Compn> thought it would be bigger :P
[03:18] <burek> 20 MB unzipped
[03:19] <burek> anyway, strace cmd ... right?
[03:19] <Compn> yes
[03:21] <burek> http://pastebin.com/uFRKycPp
[03:21] <burek> famous Unrecognized option 'h' ^^
[03:28] Action: Compn can understand none of strace
[03:28] <Compn> does --help do anything? :P
[03:28] <Daemon404> i dont see how strace would be useful :V
[03:28] <burek> Unrecognized option '-help' :D
[03:32] <Compn> does ffmpeg -i work ?
[03:32] <Compn> i mean, can it encode files ?
[03:32] <burek> hardly :)
[03:32] <Compn> strange strace didnt say what it tried to access
[03:32] <burek> i mean, if -h doesn't work.. :D
[03:32] <Compn> does it say unrecognized option ?
[03:32] <Compn> lol
[03:32] <burek> yes it does for -i also :)
[03:33] <Compn> dumb quesiton but i had to :P
[03:33] <Compn> well i'm out of ideas then
[03:33] <burek> but --help produced an error like unrecognized option '-help'
[03:33] <burek> like it doesn't understand --bla options
[03:33] <burek> or long options or what's the name
[03:34] <burek> i guess it failed to initialize the time functions or so: ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS...
[03:35] <burek> I remember having some errors regarding those timer functions
[03:35] <burek> back to the lab.. :)
[03:35] <burek> that's why I ask if anyone is interested in helping write a wiki about static build :)))
[03:42] <Compn> :)
[03:48] <taqattack> I was able to cross-compile from ubuntu to windows using libx264 and libmp3lame. That took me 2 days to figure out. On top of that I spent 2 days trying to add librtmp which just wouldnt compile. 
[06:41] <taqattack> What causes "[dshow @ 0156f620] real-time buffer 232% full! frame dropped!"?
[06:47] <ohsix> realtime buffer 232% full
[09:02] <TimNich> burek:  I compile statically for linux and win  so have built a shed load of scripts, so happy to share on a wiki
[09:16] <av500> Hmm, burek...
[09:46] <burek> TimNich, great :) do you have any links already where I can take a look? :)
[09:55] <TimNich> not at the moment. its all stuff on my devel system
[09:59] <burek> ok
[10:01] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r124eb7e476 10ffmpeg/libavcodec/aacdec.c: 
[10:01] <CIA-17> ffmpeg: aacdec: drop channel reseting code.
[10:01] <CIA-17> ffmpeg: its no longer needed and causes a race with the flv demuxer.
[10:01] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[10:02] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rdbe29db8cb 10ffmpeg/libavcodec/aacdec.c: 
[10:02] <CIA-17> ffmpeg: aacdec: more verbose overread error message
[10:02] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[10:02] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * raa0f84df5a 10ffmpeg/libavcodec/aacdec.c: 
[10:02] <CIA-17> ffmpeg: aacdec: disable new chan_config guessing code from libav.
[10:02] <CIA-17> ffmpeg: It causes more problems than it solves.
[10:02] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[10:33] <CIA-17> ffmpeg: 03Alexander Bokovikov 07master * rfc882b6e9c 10ffmpeg/libavcodec/Makefile: Fix build dependencies for libvo-aac and libopencore-amrnb.
[11:23] <ubitux> cbreak-work: what do you mean by didn't really work?
[11:23] <ubitux> (about the git bisect)
[11:24] <ubitux> also, you can try a faster git bisect specifying some path
[11:24] <cbreak-work> The commits bisect wanted me to test had various problems
[11:24] <ubitux> if you have a slight idea what file could have broke the feature
[11:24] <cbreak-work> like av_log_format_line being missing
[11:24] <ubitux> cbreak-work: you can ignore broken states
[11:25] <ubitux> git bisect skip
[11:25] <cbreak-work> or _formatContext->iformat->long_name / _codecVideo->long_name having an invalid pointer value
[11:26] <cbreak-work> _formatContext is a AVFormatContext*
[11:26] <cbreak-work> the other is a AVCodec*
[11:26] <cbreak-work> I skipped them, but I only got such commits, so I am not sure if bisect made me test relevant commits at all
[11:27] <cbreak-work> also, building ffmpeg normally creates an ffprobe for me
[11:27] <cbreak-work> but during bisect, most of the time it created an avprobe
[11:28] <ubitux> looks like you're bisecting way back
[11:28] <cbreak-work> that's what I suspected
[11:28] <cbreak-work> since my good commit is on a different branch than the bad one
[11:29] <cbreak-work> (the good one is n0.10.2, on a release branch, the one I found bad was the tip of master)
[11:32] <ubitux> git bisect start HEAD n0.10.2 libavformat/mov.c, or sth like that?
[11:32] <ubitux> i'm not sure how that will work when branches diverge
[11:52] <cbreak-work> ubitux: well, I manually started at the merge base now
[11:53] <cbreak-work> the merge base seems to still work, and lets me open the mov
[12:16] <cbreak-work> ubitux: not sure if those commits really are old
[12:17] <cbreak-work> for example 0f96f0d9968a767ead3aec823fcdfb78f26f7be7 gives me avprobe instead of ffprobe
[12:17] <cbreak-work> and it's missing av_log_format_line
[12:18] <nevcairiel> bisecting is no fun anymore because of the merges from libav
[12:28] <michaelni> if you end with a avprobe instead of ffprobe on a bisect checkout you can just test avprobe ...
[12:29] <cbreak-work> no
[12:29] <cbreak-work> I test the libraries
[12:29] Action: michaelni reads a few lines of the back log
[12:30] <av500> [12:18:20] <nevcairiel> bisecting is no fun anymore because of the merges from libav
[12:31] <michaelni> just say "git bisect bad" if you get a checkout from libav
[12:31] <michaelni> should end up with the commit from ffmpeg or a merge commit then
[12:31] <michaelni> that introduced the issue
[12:33] <cbreak-work> the whole thing is a mess
[12:38] <ohsix> good thing git doesn't care :]
[12:42] <cbreak-work> well, the first problem starts with e37f161e66e042d6c2c7470c4d9881df9427fc4a
[12:42] <cbreak-work> before that I can open the file
[12:42] <cbreak-work> after that libswscale complains about bad src pointer
[12:42] <cbreak-work> so the decoding fails
[12:42] <cbreak-work> and after that, the problems just increase
[12:44] <michaelni> how can i reproduce the problem ?
[12:45] <michaelni> can it be reproduced with the command line tools ?
[12:45] <cbreak-work> no idea. Maybe with ffplay
[12:46] <cbreak-work> ffplay isn't built on OS X, probably due to dependencies
[12:47] <michaelni> welll lets assume it can be reproduced with ffplay, what would i need to feed into ffplay ?
[12:48] <cbreak-work> curl -A "Apple Mac OS X v10.6.2 CoreMedia v1.0.0.10C540" -O http://trailers.apple.com/movies/disney/brave/brave-tlr3_h1080p.mov gives you a trailer, that's the one I tested with
[12:49] <cbreak-work> at n0.10.2 I can decode it flawlessly
[12:50] <cbreak-work> at master's tip either avformat_open_input or avformat_find_stream_info fail, and the resulting context has nb_streams == 0
[12:50] <cbreak-work> so no streams
[12:50] <cbreak-work> and on the commit I linked just above, libswscale fails to handle the image returned by the decoder
[12:50] <cbreak-work> (I use swscale to do color space conversion to rgb)
[12:51] <cbreak-work> but for now I've given up on debugging, I'll just use latest release :)
[12:51] Action: cbreak-work goes to lunch
[12:53] <michaelni> eb9f73569cc078b00ae1c62c120e2995  /home/michael/videos/brave-tlr3_h1080p.mov <---- plays with ffplay
[13:12] <michaelni> cbreak-work, btw if you find out why it doesnt work for your application, iam very interrested so we can document the issue for others or possibly add some workaround/fix
[13:13] <michaelni> also you can compare your code to ffplays, probably not fun to do but should point in the direction of the problem
[13:25] <michaelni> " <iive>	I thought the problem is with git. Aka it cannot merge things from the downstream into the upstream."
[13:25] <michaelni> git can merge anything
[13:25] <Compn> that  was a joke, about how libav is the 'upstream'
[13:26] <Compn> as is constantly described itself as
[13:26] <michaelni> ahh ok
[13:27] <cbreak-work> michaelni: eb9f73569cc078b00ae1c62c120e2995 is not a valid commit in my ffmpeg repo
[13:27] <michaelni> cbreak-work, its supposed to be a md5 sum of a mov file :)
[13:27] <cbreak-work> hmm.
[13:28] <michaelni> i just wanted to make sure i have the right file
[13:28] <cbreak-work> same hash here.
[13:29] <cbreak-work> I don't do a lot in my code, first I avformat_open_input the file, then I avformat_find_stream_info
[13:29] <cbreak-work> and afterwards, if I look into the context, nb_streams is 0
[13:29] <cbreak-work> (at master's tip)
[13:30] <michaelni> any error messages ?
[13:30] <michaelni> and i assume of course the headers and libs you link to match
[13:31] <cbreak-work> at e37f161e66e042d6c2c7470c4d9881df9427fc4a I get streams, but when I try to decode frames sws_scale complains
[13:31] <cbreak-work> I did a fresh make install each time
[13:33] <michaelni> does it work with other files or do you always get 0 streams ?
[13:33] <cbreak-work> I only tried it with this stream.
[13:33] <cbreak-work> will try with avengers trailer next... :)
[13:34] <cbreak-work> first, ffmpeg recompile... for the 20th time today...
[13:35] <michaelni> also do you check the return code of avformat_open_input() ? i mean its not an error ...?
[13:36] <cbreak-work> it's not an error
[13:37] <cbreak-work> my call is error = avformat_open_input(&_formatContext, url.c_str(), 0, 0);
[13:37] <cbreak-work> error is 0 after the execution.
[13:38] <cbreak-work> the call after that is error = avformat_find_stream_info(_formatContext, 0);, again without error return
[13:39] <michaelni> you should get streams before avformat_find_stream_info() with mov
[13:40] <cbreak-work> well, the program is supposed to work with many input formats
[13:41] <cbreak-work> and the number of streams stays 0 in the context
[13:41] <michaelni> you do call avformat_alloc_context() ?
[13:42] <cbreak-work> no
[13:42] <michaelni> that sounds not so good
[13:42] <michaelni> how do you allocate the context ?
[13:46] <michaelni> if you just set the pointer to a pointer to NULL it shoudl work
[13:47] <michaelni> but if you *malloc() it its unlikely to work
[13:53] <cbreak-work> michaelni: it is NULL
[13:53] <cbreak-work> the avformat_open_input is supposed to allocate stuff for me
[13:55] <cbreak-work> I don't think the problem is in my code
[13:55] <michaelni> well, ffplay works ...
[13:55] <cbreak-work> since I really only use bare-bones ffmpeg, which worked back at n0.10.2 :)
[13:55] <michaelni> does ffmpeg (the command line tool) work for you ?
[13:56] <cbreak-work> what should I try to do?
[13:56] <michaelni> ./ffmpeg -i thatfile
[13:57] <michaelni> does it find streams ?
[13:57] <cbreak-work> converting to an avi seems to work.
[13:57] <cbreak-work> so the streams must be found
[14:11] <cbreak-work> michaelni: ffplay does more than my program
[14:12] <cbreak-work> I think it lets av_find_input_format run
[14:13] <cbreak-work> maybe...
[14:26] <RobertNagy> regarding, guess_correct_pts, shouldn't the pts_correction_qqq values be reset on avcodec_flush_codec?
[14:31] <michaelni> they should, arent they ?
[14:32] <RobertNagy> not as far as I can find
[15:35] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rabe6330317 10ffmpeg/libavutil/opt.h: 
[15:35] <CIA-17> ffmpeg: AVoption doxy: clarify a few needs in relation to AVClass less structs.
[15:35] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:35] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r9f39d3d190 10ffmpeg/libavformat/utils.c: 
[15:35] <CIA-17> ffmpeg: lavf: check that the context to avformat_open_input() is valid.
[15:35] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:35] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r8201092241 10ffmpeg/libavcodec/h264.c: 
[15:35] <CIA-17> ffmpeg: h264: reset current_slice on context reinit
[15:35] <CIA-17> ffmpeg: This fixes a null pointer dereference
[15:35] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[15:35] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:35] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r9ed388f598 10ffmpeg/libavformat/oggparseogm.c: 
[15:35] <CIA-17> ffmpeg: ogm: Fix division by 0
[15:35] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[15:35] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:38] <cptspiff> are you guys interested in a sample spewing 'More than one AAC RDB per ADTS frame is not implemented'? i'm not 100 it's not just a corrupt bitstream though.
[15:43] <michaelni> cptspiff, i think we have such samples already IIRC
[15:43] <michaelni> does the file fail to decode correctly ?
[15:43] <cptspiff> k
[15:43] <cptspiff> video decodes (with heavy stutter), no audio
[15:44] <cptspiff> it's an ancient (anime) .ogm though so i wouldn't exclude messed up muxing
[15:45] <michaelni> maybe upload, the file i have that prints that works
[15:46] <cptspiff> incoming works now?
[15:46] <michaelni> no idea, try it ..
[15:46] <cptspiff> right'o
[15:46] <nevcairiel> speaking about ogm, i also have a bunch of ogms produced by GOMStreamer that fail badly
[15:47] <nevcairiel> i think the files are broken though
[15:48] <michaelni> cant hurt to open ticket(s) for them on trac
[15:53] <cptspiff> ffs. good news and stupid news. good news is it works in master, apparently fixed between 0.10.1 and now. stupid news was me using the release and not master as i thought i was. /me stops making noise.
[16:40] <taqattack> Hello I'm having some issues with dropped frames
[16:40] <taqattack> http://pastebin.com/hhLw7gqE
[16:40] <Digidog> taqattack: from where to where?
[16:41] <taqattack> Trying to read from direcshow and output to flv
[16:42] <nevcairiel> all that means is your encoding is too slow for realtime encoding from a screen capture source
[16:42] <nevcairiel> turn down the settings :)
[16:44] <taqattack> Which settings?
[16:44] <teratorn> taqattack: are you using a 64-bit ffmpeg / 64-bit OS?
[16:45] <taqattack> 32-bit on 64-bit OS
[16:45] <taqattack> I have the issue with both versions though
[16:47] <teratorn> taqattack: well you *ought* to be able to get better encoding performance off a 64bit build
[16:49] <taqattack> Is there a way to multithread in FFmpeg?
[16:51] <taqattack> real-time buffer 121% full! frame dropped! in 64-bit build
[16:53] <teratorn> there is the -threads option
[16:54] <teratorn> multi-threaded encoding of a single video stream I don't *think* is very common, but I've heard about work going on in that department. I'm really not sure what the current situation is (?)
[16:58] <taqattack> oh ok
[17:01] <taqattack> So the decoding of directshow filter is single-threaded?
[17:02] <cptspiff> it's obviously decoding fast enough.. ;)
[17:03] <Digidog> does anyone knwo where to get latest mpasource.dll from ?
[17:04] <taqattack> So the problem is with encoding options. Specifically x264 options?
[17:13] <elinenbe> hi there, quick question.  Is there anyway to run an amovie filter on a live stream?  Eg, this works: "ffmpeg -y -f lavfi -i amovie="my_local_file.flv",silencedetect=n=-23dB:d=1 -f null - " but I can't do it on this eg: "ffmpeg -y -f lavfi -i amovie=http://www.example.com/web_file.flv,silencedetect=n=-23dB:d=1 -f null -"
[17:15] <CIA-17> ffmpeg: 03Robert Nagy 07master * rc58290e5e5 10ffmpeg/libavcodec/utils.c: 
[17:15] <CIA-17> ffmpeg: Reset pts_correction state on codec flush.
[17:15] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:15] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * re531e73a6f 10ffmpeg/libavcodec/ivi_common.c: 
[17:15] <CIA-17> ffmpeg: indeo: Make sure the to be used vlc table has been initilaized.
[17:15] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[17:15] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:16] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r601d072e68 10ffmpeg/libavcodec/diracdec.c: 
[17:16] <CIA-17> ffmpeg: diracdec: check xybsep
[17:16] <CIA-17> ffmpeg: Fixes division by 0
[17:16] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[17:16] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:22] <cptspiff> lol. michaelni fyi it was fixed when a ticket i had opened half a year ago was processed :)
[21:26] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * ra02f8ef1d2 10ffmpeg/libavcodec/h263dec.c: 
[21:26] <CIA-17> ffmpeg: h263dec: Prevent dimension changes from leaking on errors in header parsing.
[21:26] <CIA-17> ffmpeg: This fixes crashes with frame threads caused by inconsistent context parameters.
[21:26] <CIA-17> ffmpeg: Fixes Ticket1207
[21:26] <CIA-17> ffmpeg: Found-by: John Villamil
[21:26] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:28] <CIA-17> ffmpeg: 03Alex Converse 07master * rb5d2bf964b 10ffmpeg/libavcodec/cook.c: cook: Make constants passed to AV_BE2NE32C() unsigned to avoid signed overflow.
[22:28] <CIA-17> ffmpeg: 03Alex Converse 07master * rdf8d5eaa14 10ffmpeg/libavcodec/utils.c: 
[22:28] <CIA-17> ffmpeg: avcodec_string: Favor AVCodecContext.codec over the default codec.
[22:28] <CIA-17> ffmpeg: This improves output for formats with more than one AVCodec.
[22:28] <CIA-17> ffmpeg: 03Luca Barbato 07master * r204bcdf56c 10ffmpeg/libavformat/matroskadec.c: 
[22:28] <CIA-17> ffmpeg: mkv: report average framerate as minimal as well
[22:28] <CIA-17> ffmpeg: This is in line with other demuxers and overall seems more correct
[22:28] <CIA-17> ffmpeg: than assuming codec time base.
[22:28] <CIA-17> ffmpeg: 03Luca Barbato 07master * rac97d47d9b 10ffmpeg/libavformat/matroskadec.c: 
[22:28] <CIA-17> ffmpeg: mkv: use av_reduce instead of av_d2q for framerate estimation
[22:28] <CIA-17> ffmpeg: It avoids some rounding errors.
[22:28] <CIA-17> ffmpeg: 03Mans Rullgard 07master * r3c58300269 10ffmpeg/libavformat/matroskadec.c: 
[22:28] <CIA-17> ffmpeg: matroska: do not set invalid default duration if frame rate is zero
[22:28] <CIA-17> ffmpeg: If a video track specifies a zero frame rate (invalid but occurs),
[22:28] <CIA-17> ffmpeg: this results in a division by zero and subsequent undefined conversion
[22:28] <CIA-17> ffmpeg: to integer. Setting the default duration from the frame rate only
[22:28] <CIA-17> ffmpeg: if the latter is greater than zero avoids such problems.
[22:28] <CIA-17> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:28] <CIA-17> ffmpeg: 03Diego Biurrun 07master * raa3f2cb584 10ffmpeg/libavcodec/mpegaudiodec.c: 
[22:28] <CIA-17> ffmpeg: mpegaudiodec: Do not discard mp_decode_frame() return value.
[22:28] <CIA-17> ffmpeg: This fixes the warning:
[22:28] <CIA-17> ffmpeg: libavcodec/mpegaudiodec.c:1704:14: warning: variable out_size set but not used
[22:28] <CIA-17> ffmpeg: 03Diego Biurrun 07master * r0f53601ac6 10ffmpeg/libavcodec/ (dsputil.c dsputil.h ppc/mpegvideo_altivec.c): 
[22:28] <CIA-17> ffmpeg: ppc: drop unused function dct_quantize_altivec()
[22:28] <CIA-17> ffmpeg: This also allows dropping some PPC-specific ugliness from dsputil.[ch].
[22:28] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * re366e6bfab 10ffmpeg/: (log message trimmed)
[22:28] <CIA-17> ffmpeg: Merge remote-tracking branch 'qatar/master'
[22:28] <CIA-17> ffmpeg: * qatar/master:
[22:28] <CIA-17> ffmpeg:  ppc: drop unused function dct_quantize_altivec()
[22:28] <CIA-17> ffmpeg:  mpegaudiodec: Do not discard mp_decode_frame() return value.
[22:28] <CIA-17> ffmpeg:  matroska: do not set invalid default duration if frame rate is zero
[22:28] <CIA-17> ffmpeg:  mkv: use av_reduce instead of av_d2q for framerate estimation
[22:34] <CIA-17> ffmpeg: 03Carl Eugen Hoyos 07master * rdddd06d5b4 10ffmpeg/libavcodec/tiffenc.c: 
[22:34] <CIA-17> ffmpeg: Make tiff-in-mov QuickTime-compatible for more colour-spaces.
[22:34] <CIA-17> ffmpeg: Fixes ticket #1228.
[00:00] --- Thu Apr 19 2012


More information about the Ffmpeg-devel-irc mailing list