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

[burek]

[01:04] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * r36583d23bd 10ffmpeg/libavcodec/ (audio_frame_queue.c audio_frame_queue.h): (log message trimmed)
[01:04] <CIA-122> ffmpeg: audio_frame_que: simplify
[01:04] <CIA-122> ffmpeg: Also update libav->ffmpeg as theres pretty much no code left from libav.
[01:04] <CIA-122> ffmpeg: The new code is faster, requires fewer mallocs and less memory. Its
[01:04] <CIA-122> ffmpeg: also half the number of lines of code.
[01:04] <CIA-122> ffmpeg: This code is not 100% identical in behavior to the previous, but the
[01:04] <CIA-122> ffmpeg: differences appear to be rather limitations of the previous design
[01:52] <dalecurtis> Quick Q: Playing this Mp3 all the way through w/ HEAD ffplay http://www.danedington.co.uk/superThings/HTML5Guitar/D_0.mp3 generates a "Header missing" error. However playing with say -ss 1 shows no error.
[01:52] <dalecurtis> mediainfo shows no problems. burek suggested it might be a bug and to try asking here :)
[01:53] <dalecurtis> Error is in the last packet per a test loop of av_read_frame/avcodec_decode_audio
[01:53] <dalecurtis> Is it a bug or corrupt file?
[01:53] <burek> can you please use pastebin.com, to show your command line and its output?
[01:53] <dalecurtis> Sure.
[01:55] <dalecurtis> http://pastebin.com/Xd6QVqR3
[01:59] <burek> btw, that's just a warning, it's not the error
[02:36] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * r011004152f 10ffmpeg/libavcodec/utils.c: 
[02:36] <CIA-122> ffmpeg: lavc/utils: change a few asserts to av_assert0()
[02:36] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:52] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * r3183c38aaa 10ffmpeg/libavcodec/mpegaudiodec.c: 
[03:52] <CIA-122> ffmpeg: mp3decoder: discard ID3 tags
[03:52] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:52] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * rf46185c289 10ffmpeg/libavformat/mp3dec.c: 
[03:52] <CIA-122> ffmpeg: mp3demux: fix off by 1 error
[03:52] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:52] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * r7da0a07283 10ffmpeg/libavformat/mp3dec.c: 
[03:52] <CIA-122> ffmpeg: mp3demux: fix id3 discard code
[03:52] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:54] <Daemon404> http://fate.ffmpeg.org/report.cgi?time=20120506190419&slot=x86_32-ubuntu-mingw32-gcc
[03:54] <Daemon404> ^ who runs this?
[03:54] <Daemon404> ah damn nvm.
[03:54] <Daemon404> it's teh same stupid steup as the rest :|
[03:58] <michaelni> Daemon404, ?
[03:59] <Daemon404> michaelni, cross-compiled on linux
[03:59] <Daemon404> not a real windows fate test
[03:59] <Daemon404> same problem in libav
[03:59] <Daemon404> not a single real windows fate instance between teh two projects
[03:59] <ohsix> is that a problem
[04:00] <Daemon404> yes.
[04:00] <Daemon404> windows users (via chrome, strea, vlc, etc) are a HUGE chunk of tour users
[04:00] <Daemon404> neglectign regression tests on it is silly
[04:00] <Daemon404> s/strea/steam/
[04:00] <ohsix> so the builds aren't tested at all, not even with wine?
[04:01] <Daemon404> they use wine
[04:01] <Daemon404> but wine is not windows.
[04:01] <Daemon404> it's an independant reimplemention of teh apis
[04:01] <ohsix> the apis ffmpeg use lots of!
[04:01] <Daemon404> and not a valid substitute for teh real os
[04:01] <Daemon404> as in all of windows apis? yes.
[04:01] <ohsix> all of them? heh
[04:02] <Daemon404> well as much as they can
[04:02] <michaelni> well Daemon404 do you happen to have a windows7 license key ?
[04:02] <ohsix> you could easily test the directshow parts separately, the rest is basically just the c library (which, if busted, is more than an ffmpeg problem)
[04:02] <michaelni> or can i download it from microsoft.org ?
[04:03] <Daemon404> michaelni, i have many windows license keys
[04:03] <Daemon404> studenst get tons
[04:03] <Daemon404> for whatever reasonb
[04:03] <Daemon404> my 7 keys are in use though.
[04:03] <michaelni> well i have a original windows 7 64bit home premium i think CD here but no unused key though
[04:04] <ohsix> just run fate on your computer a few times a year, if it shows a problem then you can worry about it; there's no useful difference, are there even any windows specific tests?
[04:04] <Daemon404> i woudl set up a box gladly, but i lack hardware
[04:04] <ohsix> vmware
[04:04] <Daemon404> no i mean i have no hardware not in use
[04:05] <ohsix> me neither, but on this very machine i type on, i use vmware regularly for such things
[04:05] <Daemon404> im talkign about a dedicate fate server for bothj projects
[04:05] <ohsix> just run the tests once, if theres no difference don't worry about it
[04:05] <Daemon404> up 24/7
[04:06] <Daemon404> i dont think you grasp how regression testign works
[04:06] <ohsix> i do, you have an issue with wine
[04:07] <Daemon404> if you dotn see teh issue with runnign it under wine, you dont understand regression testing >_>
[04:07] <ohsix> you surely aren't advocating testing it on every windows version ever
[04:07] <ohsix> wine is its own baseline with respect to regressions, even if nobody ever uses ffmpeg with wine
[04:07] <Daemon404> just supported ones
[04:07] <Daemon404> xp/vista/7
[04:07] <Daemon404> i think 2003 is still supported for now
[04:07] <ohsix> are there any windows specific fate tests? or do they test the stuff the other builds run
[04:08] <ohsix> windows tests = like the directshow input
[04:08] <Daemon404> why would taht even matter?>
[04:08] <michaelni> xp/vista/7 {32|64}bit
[04:08] <ohsix> because you aren't testing the features that might actually not be fit for purpose in wine, you are testing the C library
[04:09] <ohsix> nothing would work in wine if ffmpeg was affected by anything it actually uses in the existing tests
[04:09] <ohsix> and if you aren't testing the windows features, you aren't really getting anything from checking more than one windows version
[04:10] <ohsix> what sort of problems do you expect to discover running tests on vista and windows 7?
[04:10] <michaelni> Daemon404, so what you would need is $$$ for a dedicated box? virtualbox/vmware is no option ?
[04:10] <Daemon404> for example
[04:10] <Daemon404> ive experience apps that work fien udner wine
[04:10] <Daemon404> and crash on real windows
[04:11] <ohsix> same here, but was it ffmpeg?
[04:11] <Daemon404> michaelni, i dont like getting donations/money. i'd rather try and provide keys/software were i can
[04:11] <Daemon404> [22:11] < ohsix> same here, but was it ffmpeg? <-- irrelevant.
[04:11] <Daemon404> the poitn is wine is not windows.
[04:11] <ohsix> totally relevant, ffmpeg touches almost nothing outside of the C library
[04:11] <Daemon404> now stop trolling.
[04:11] <michaelni> Daemon404, i would need a key AND time ...
[04:11] <ohsix> i accept your point, but it isn't one worth making to argue for "real" windows tests, there is no practical difference
[04:12] <ohsix> run fate once, if there's a problem i will eat my hat
[04:12] <Daemon404> i really dont think you put much value on real regression testing
[04:12] <Daemon404> and it's point
[04:12] <Daemon404> michaelni, true
[04:12] <ohsix> regressing in wine will regress in windows
[04:13] <ohsix> wine is equivalent 100% to the actual tests ran, if you had windows specific tests, say the directshow portion; you might have to question wine
[04:14] <ohsix> you can look at the imports to ffmpeg and the dll's on windows
[04:17] <Daemon404> you do realize wine reimplements the crt (most of it) right?
[04:17] <ohsix> yes
[04:17] <Daemon404> thus it is not a valdi substitute for the real c runtime.
[04:17] <ohsix> you can use microsofts "real" c runtime if you wish, and have a license to
[04:17] <ohsix> you aren't running regressions on wines crt, you're running them on ffmpeg; and even the crt's used on windows changed greatly, if you want to test the C library on windows oyu've got like 120 variants just with xp/vista/7
[04:17] <Daemon404> except a) thats not being done b) at that point you may as well sue windows anyway, since the license is teh whole issue in teh first place
[04:18] <ohsix> you're arguing for something that would a) cost money to someone, b) be of dubious use or facility, and you say i'm trolling ...
[04:18] <ohsix> i think i get what michaelni was saying ;]
[04:20] <ohsix> for the facilities ffmpeg uses, wine is a sufficient host; that is not always true, but wine has nearly no windows specific features, and there are no tests for them anyways
[04:21] <ohsix> you'll sooner find more differences in the windows versions ... if you wrote the tests, that will require changes that are not regressions
[04:22] <ohsix> nobody runs anything that builds it with microsoft's sdk too; of which there are maybe 6 versions in regular use, so you need to build with 6 tool chains to see if any regress, or tell them to use mingw
[04:22] <ohsix> it's so silly i don't know why i even tried to explain :[
[04:27] <Compn> Daemon404 : ramiro used to run some windows fate boxes ;P
[04:27] <Daemon404> what happened to em?
[04:27] <Compn> think he got a real life
[04:28] <Compn> ehe
[04:28] <Daemon404> lol
[04:28] <Compn> or he was so digusted about fork he left
[04:28] <Compn> i'm not entierly sure
[04:30] <ohsix> i am desparate for validation!
[04:30] <ohsix> Compn: were the mingw tests stopped while he was running it? was there ever a regression that occured only on the windows machine and not all of them, or the mingw one?
[04:31] <Compn> once in a rare while someone would commit something that broke on mingw
[04:31] <ohsix> interesting :]
[04:31] <Compn> if you are just looking for breakage, zeranoe runs automated win32 builds
[04:32] <ohsix> someone find ramiro and ask him if it was worthwhile, there's got to be a reason (besides disgust) that he stopped running it
[04:32] <Compn> so could ask him to set up some kind of alert on failed build...
[04:32] <ohsix> if he's already running it maybe he wouldn't mind running the whole thing
[04:32] <Daemon404> zeranoe is an ideal candidate
[04:33] <Daemon404> wait, no
[04:33] <Daemon404> he cross-compiels from debian
[04:33] <Daemon404> i forgot
[04:33] <ohsix> well at least he's building it the right way ;]
[04:33] <Compn> and his builds somehow link to newer dlls
[04:33] <Compn> so they dont work on win9x/win2k :\
[04:33] <Daemon404> Compn, mingw-w64
[04:34] <Compn> prolly
[04:34] Action: Compn on 12 year old OS
[04:34] <ohsix> yar that's another aspect of the CRT version problem
[04:35] <ohsix> it's not just windows versions, there are several toolchain & library versions in use; what you're really testing when you test xp and vista is different crt versions (and that assumes you use a different toolchain, or the crt on xp would be used on vista as well)
[04:35] <Compn> but uh
[04:35] <Compn> to answer your question
[04:35] <Compn> i dont remember one reg test failing on mingw vs others
[04:36] <ohsix> thought so, thanks
[04:36] <ohsix> would have taken a lot of effort for me to verify by myself :]
[04:36] <Compn> sometimes it would happen , but rarely i think
[04:36] <ohsix> yar no doubt
[04:36] <ohsix> when you think about "forever", it's certain to happen
[04:37] <ohsix> it costs $money to wait for it to happen though :]
[04:38] <Compn> hmm
[04:38] <Compn> what happens when you give other software a 10bit yuv4mpeg file crafted by ffmpeg ?
[04:39] <ohsix> small puff of smoke
[04:39] <ohsix> is there any other notable software that does yuv4mpeg, is it strange to support 10 bit already?
[04:40] <Compn> well... yuv4mpeg is an intermediary format
[04:40] <Compn> so thered be no point in using it if you werent piping between ffmpeg and another tool
[04:40] <Compn> cuz then youd just be using ffmpeg , then why use an intermediate format ?
[04:41] <Compn> kind of getting into microsoft mindset, take standard, improve on it, and force people to use it ... :p
[04:41] <ohsix> right, but like; if they do yuv4mpeg already, is it implied that they do more than 8 bit?
[04:41] <Compn> you're saying yuv4mpeg is outdated now and taking it over wont hurt ?
[04:41] <ohsix> i have no idea about yuv4mpeg
[04:42] <Compn> well , i'm not big on it either :P
[04:42] <Compn> ehe
[04:45] <Compn> oh i guess he just wants to use it for doing some strange ffmpeg wrangling 
[04:45] <Compn> joining files and reencoding i guess :P
[04:45] <ohsix> looks like the de-facto version is mjpegtools?
[04:45] <Compn> so maybe my question isnt all that important
[04:45] <Compn> plus yuv4mpeg already has a bunch of other codecs :P
[04:45] <Compn> er colorspaces
[04:46] <ohsix> http://linux.die.net/man/5/yuv4mpeg lists the one that works in libmjpegutils
[04:47] <ohsix> also Each sample within each plane is one octet (8-bits) in size.
[04:47] <ohsix> if ffmpeg can do it already maybe someone should tip off the mjpegtools guy
[04:47] <ohsix> if it wasn't unchanged since 2005 :O
[04:48] <ohsix> there was a release in 2011
[04:49] <ohsix> interesting, BBB made the last changes many years ago http://mjpeg.cvs.sourceforge.net/viewvc/mjpeg/studio/yuv4mpeg/
[04:50] <ohsix> and there's a comment in there that says it would be part of ffmpeg some day
[04:51] <ohsix> so ffmpeg is the de-facto version, and i don't know of any software that reads yuv4mpeg; huhuhuhu
[06:54] <tg2> THREADS, MOAR THREADS
[06:54] Action: tg2 goes to sleep
[11:04] <CIA-122> ffmpeg: 03Carl Eugen Hoyos 07master * r299d58e18a 10ffmpeg/ (8 files in 3 dirs): Support yuva422p rawvideo in nut.
[11:04] <CIA-122> ffmpeg: 03Carl Eugen Hoyos 07master * r4e4634aa16 10ffmpeg/libavcodec/ffv1.c: Support yuva422p in ffv1.
[11:04] <CIA-122> ffmpeg: 03Carl Eugen Hoyos 07master * r8ba543eb3b 10ffmpeg/ (7 files in 3 dirs): Add Avid Meridien (AVUI) decoder.
[11:04] <CIA-122> ffmpeg: 03Carl Eugen Hoyos 07master * r541bfba85d 10ffmpeg/libavcodec/targaenc.c: 
[11:04] <CIA-122> ffmpeg: Write palettised targa.
[11:04] <CIA-122> ffmpeg: Fixes ticket #1190.
[11:04] <CIA-122> ffmpeg: Reviewed-by: Paul B Mahol
[11:04] <CIA-122> ffmpeg: 03Carl Eugen Hoyos 07master * r143a5c55ff 10ffmpeg/ (12 files in 4 dirs): Add yuva422p pix_fmt.
[11:04] <CIA-122> ffmpeg: 03Carl Eugen Hoyos 07master * r29fe6b3cbf 10ffmpeg/libavfilter/vf_yadif.c: Add yuva422p to yadif format list.
[11:53] <j-b> good morning
[14:02] <cbsrobot_> !fflogger "j-b"
[14:03] <cbsrobot_> shit
[14:03] <cbsrobot_> hehe
[14:03] <cbsrobot_> nah - not working then
[14:05] <av500> we do manual flogging here
[14:05] <cbsrobot_> AV500_LOG_ERROR
[14:05] <burek> try now
[14:06] <av500> \o/
[14:06] <av500> somebody kill him now for using color
[14:07] <cbsrobot_> but the picture is right :-)
[14:07] <Compn> oh no color
[14:07] <av500> yes, the brushed metal, that is me
[14:07] <Compn> ;p
[14:07] <Compn> 30gb ?
[14:08] <Compn> is this 1999 again ?
[14:08] <av500> close
[14:08] <av500> 30GB in 1.8"
[14:08] <burek> hm, it doesn't use colors on #ffmpeg
[14:08] <av500> flog it!
[14:09] <burek> :)
[14:11] <burek> oh
[14:11] <burek> #ffmpeg has +c set
[14:11] <burek> that's why :)
[14:13] <cbsrobot_> Compn: you dont like the y4m patch ?
[15:43] <Compn> cbsrobot_ : just curious :) i think its good idea :)
[17:03] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * re7117f1c10 10ffmpeg/ (libavcodec/aasc.c tests/ref/fate/aasc): 
[17:03] <CIA-122> ffmpeg: aasc: use the correct reader offset
[17:03] <CIA-122> ffmpeg: Fixes Ticket1232
[17:03] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:03] <CIA-122> ffmpeg: 03Jean First 07master * rf7f6aaf988 10ffmpeg/libavformat/yuv4mpeg.c: 
[17:03] <CIA-122> ffmpeg: yuv4mpeg: support 9/10/16 bit pixel formats
[17:03] <CIA-122> ffmpeg: Signed-off-by: Jean First <jeanfirst at gmail.com>
[17:03] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:23] Action: Daemon404 is starting to wonder if it's even possible to demux avc to an elementary stream via ffmpeg
[19:07] <kierank> Daemon404: ffmpeg -i in.file -y out.264
[19:07] <kierank> or out.h264
[19:32] <Daemon404> kierank, close
[19:32] <Daemon404> -bsf h264_mp4toannexb -f h264
[19:32] <Daemon404> ^ i needed this
[19:33] <kierank> yeah you need that for some files
[19:33] <nevcairiel> that bsf has quite a few issues though
[19:37] <Daemon404> nevcairiel, what sort?
[19:38] <nevcairiel> the bsf will insert sps/pps after every IDR frame, but if your stream already contains sps/pps in the bitstream on a frequent basis, it may result in problems
[19:38] <nevcairiel> especially when the contents of the sps/pps change over time
[19:39] <nevcairiel> (after or before the idr, i dont remember, probably before)
[19:39] <Daemon404> have you filed a bug?
[19:39] <Daemon404> this is kinda crappy, since i was plannong on using it possibly
[19:40] <Daemon404> nevcairiel, do you know how it compares to e.g. the approach gpac takes?
[19:40] <nevcairiel> i have no idea how gpac works
[19:41] <Daemon404> im wondering if it is even plausible to do it correctly
[19:41] <nevcairiel> its only inserted into the bitstream to allow proper random access, because there is no global header
[19:41] <nevcairiel> it could analyze the bitstream and check if its already in there
[19:42] <nevcairiel> if your stream was initially sourced from a mpeg-ts stream, it'll most likely have them
[19:42] <nevcairiel> if it was encoded straight to mkv/mp4, most likely not
[19:42] <Daemon404> wouldnt this entail a 2 pass method?
[19:43] <nevcairiel> it could have some threshold based on some empirecal evidence from real-world files, if no sps/pps occured within X frames/idrs/etc, insert it
[19:43] <nevcairiel> i dunno
[19:43] <nevcairiel> i don't use that thing anymore
[19:44] <Daemon404> what do you use instead?
[19:44] <nevcairiel> when i want to demux a h264 stream, i usually use eac3to, but of course windows only
[19:44] <Daemon404> doesnt eac3to use ffmpeg for some stuff
[19:45] <nevcairiel> initially i used the bsf to convert to annexb for playback as well (some hw decoders only like annexb), but that problem outlined above made me write a new version designed for playback
[19:45] <nevcairiel> for decoding of things, not for demuxing, afaik
[19:45] <Daemon404> you wrote a new bsf?
[19:45] <nevcairiel> not really, i just do it manually
[19:46] <Daemon404> i see
[19:46] <nevcairiel> i only need the annexb conversion, its really trivial
[19:46] <Daemon404> well
[19:46] <Daemon404> same with me
[19:46] <nevcairiel> during playback, i know when a random access occured
[19:46] <Daemon404> i only need anneb conv
[19:46] <Daemon404> annexb*
[19:46] <nevcairiel> so i can insert to sps/pps at that point
[19:46] <nevcairiel> s/to/the/
[19:47] <Daemon404> the way i need it, it would only ever be muxed back into mp4 at the end
[19:47] <Daemon404> linearly
[19:47] <nevcairiel> it needs to store the sps/pps somewhere though, and a raw h264 file doesn't have a "header" field
[19:48] <CIA-122> ffmpeg: 03Nicolas George 07master * r75e0324eab 10ffmpeg/libavfilter/src_buffer.c: src_buffer: move code to avoid forward declarations.
[19:48] <Daemon404> humm
[20:12] <kierank>  it needs to store the sps/pps somewhere though, and a raw h264 file doesn't have a "header" field --> at the beginning of every i-frame
[20:12] <kierank> well every keyframe technically
[20:19] <Daemon404> well
[20:19] <Daemon404> both mp4box and ffmpeg are creating a mangled file when i extract this vid
[20:20] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * r0261902dac 10ffmpeg/doc/examples/Makefile: 
[20:20] <CIA-122> ffmpeg: doc/examples/Makefile: split lines up to make diffs that change them clearer
[20:20] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:20] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * rb4b5848513 10ffmpeg/libavcodec/shorten.c: 
[20:20] <CIA-122> ffmpeg: shorten: increase max_frame_size.
[20:20] <CIA-122> ffmpeg: Fixes Ticket1250
[20:20] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:20] <Daemon404> complete borks seeking for example
[20:34] Action: Daemon404 thinks it's weird mp4...
[20:45] <nevcairiel> seeking in raw h264 is always just weird
[20:45] <nevcairiel> no timestamps, no nothing
[20:53] <Daemon404> nevcairiel, no i mean after i remux it to anything else
[20:53] <Daemon404> the stream is derped
[20:53] <nevcairiel> oh
[21:13] <bcoudurier> j-b, mon frere habite a cote de bastille, alors bon :)
[21:16] <j-b> bcoudurier: et?
[21:18] <j-b> bcoudurier: il a donc pu te dire qu'il y avait autrement plus de drapeaux du PCF, du FdG et de FH que des drapeaux étrangers.
[21:21] <bcoudurier> oui, mais ce n'est pas ca le probleme
[22:07] <CIA-122> ffmpeg: 03Justin Ruggles 07master * rb461cd4deb 10ffmpeg/libavcodec/utils.c: 
[22:07] <CIA-122> ffmpeg: avcodec: remove fallbacks for AVCodec.encode() in avcodec_encode_audio2()
[22:07] <CIA-122> ffmpeg: We no longer have any audio encoders using AVCodec.encode().
[22:07] <CIA-122> ffmpeg: 03Justin Ruggles 07master * rfa0319b4fd 10ffmpeg/libavcodec/utils.c: avcodec: refactor avcodec_encode_audio2() to merge common branches
[22:07] <CIA-122> ffmpeg: 03Ronald S. Bultje 07master * r64953f67f9 10ffmpeg/libavcodec/qdm2.c: 
[22:07] <CIA-122> ffmpeg: qdm2: clip array indices returned by qdm2_get_vlc().
[22:07] <CIA-122> ffmpeg: Prevents subsequent overreads when these numbers are used as indices
[22:07] <CIA-122> ffmpeg: in arrays.
[22:07] <CIA-122> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[22:07] <CIA-122> ffmpeg: CC: libav-stable at libav.org
[22:07] <CIA-122> ffmpeg: Signed-off-by: Justin Ruggles <justin.ruggles at gmail.com>
[22:07] <CIA-122> ffmpeg: 03Justin Ruggles 07master * r74e10b6204 10ffmpeg/libavcodec/utils.c: avcodec: for audio encoding, reset output packet when it is not valid
[22:07] <CIA-122> ffmpeg: 03Justin Ruggles 07master * r85e5b866dc 10ffmpeg/avplay.c: 
[22:07] <CIA-122> ffmpeg: avplay: properly close/reopen AVAudioResampleContext on channel layout change
[22:07] <CIA-122> ffmpeg: fixes Bug#280
[22:07] <CIA-122> ffmpeg: 03Alex Converse 07master * r6345209a7d 10ffmpeg/tests/Makefile: fate: Add avprobe as a make dependency
[22:07] <CIA-122> ffmpeg: 03Ronald S. Bultje 07master * r4bfa67bdad 10ffmpeg/tests/ (Makefile fate-run.sh fate/probe.mak): 
[22:07] <CIA-122> ffmpeg: Add probe fate tests to test for regressions in detecting media types.
[22:07] <CIA-122> ffmpeg: Signed-off-by: Alex Converse <alex.converse at gmail.com>
[22:07] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * rb4178a3f13 10ffmpeg/: (log message trimmed)
[22:07] <CIA-122> ffmpeg: Merge remote-tracking branch 'qatar/master'
[22:07] <CIA-122> ffmpeg: * qatar/master:
[22:07] <CIA-122> ffmpeg:  rtmp: Support 'rtmp_live', an option which specifies if the media is a live stream.
[22:26] <Daemon404> humm... interesting... cannot find the /g 36
[22:26] <Daemon404> ... epic fail
[23:19] <CIA-122> ffmpeg: 03Reimar Döffinger 07master * rbadb0c07d4 10ffmpeg/libavcodec/cscd.c: (log message trimmed)
[23:19] <CIA-122> ffmpeg: CSCD: must use reget_buffer.
[23:19] <CIA-122> ffmpeg: Using release_buffer and get_buffer as currently might
[23:19] <CIA-122> ffmpeg: not prefer the previous frame contents which the
[23:19] <CIA-122> ffmpeg: decoder relies on.
[23:19] <CIA-122> ffmpeg: This leads to horrible playback in players using direct
[23:19] <CIA-122> ffmpeg: rendering like MPlayer.
[23:35] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * r66337bf9d5 10ffmpeg/libavcodec/qdm2.c: 
[23:35] <CIA-122> ffmpeg: qdm2: print error messages instead of just retunring failures
[23:35] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:00] --- Wed May  9 2012