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

[burek]

[00:11] <saste> beastd, thanks
[00:12] <ubitux> saste: i think gitignore needs a /doc/*.3
[00:13] <durandal_1707> is there filter that split y, u and v component into each frame?
[00:13] <ubitux> saste: also, it doesn't seem to be cleaned by git clean
[00:13] <saste> ah gitignore...
[00:13] <ubitux> (not sure the .1 files are cleaned though)
[00:13] <ubitux> (it seems they are)
[00:14] <saste> ubitux, feel free to beat me with time
[00:14] <beastd> saste: np. and again sorry for delaying libswresample.texi review. it is just too late now.
[00:14] <saste> durandal_1707, no, that's something I thought but never implemented
[00:14] <ubitux> saste: i'll beat you to the rush to the bed i believe
[00:14] <saste> implementation would be trivial, should i add it to my todo?
[00:15] <durandal_1707> saste: there is extremly ugly code for this in img2enc i gonna remove now
[00:15] <durandal_1707> i cant activate it though
[00:16] <saste> durandal_1707, wait a few days so i can implement the feature, before we drop that
[00:17] <durandal_1707> no point if a cant use it
[00:18] <beastd> bye...
[00:18] <saste> durandal_1707, never tried that feature, never figured how it works as well (i don't think it's documented)
[00:18] <durandal_1707> it does raw thing if you output to .y
[00:20] <durandal_1707> it obviously does not work if you set -vcodec to something that does not match with stupid hack
[00:21] <durandal_1707> ie it works only for one pix fmt
[00:21] <Daemon404> btw
[00:21] <Daemon404> raw+image2 is useful
[00:21] <Daemon404> for dumping compressed vcopy'd frames
[00:21] <Daemon404> for RE purposes
[00:22] <durandal_1707> yes but this one works for only single pixel format
[00:22] <durandal_1707> and for other you get crap
[00:22] <durandal_1707> and overreads
[00:22] <Daemon404> as long as you dont remove the functionality i just mentioned
[00:23] <Daemon404> im cool with it
[00:23] <durandal_1707> disagre, this one is security hole
[00:23] <Daemon404> its certainly possible to retain teh functionality i mentioned
[00:23] <Daemon404> without it being a security hole
[00:23] <durandal_1707> it is trivail to write code which will separate planes from random raw output
[00:24] <Daemon404> thats not what i mentioned
[00:24] <Daemon404> if you read what i said
[00:24] <durandal_1707> lavfi looks to be best place to implement this
[00:25] <Daemon404> i dont think you have comprehended teh functionality i described
[00:25] <Daemon404> whatsoever
[00:25] <durandal_1707> you just said: raw+image2 is useful -- i agree
[00:26] <Daemon404> you have neglected to understand teh actual functionality i saifd
[00:26] <durandal_1707> removing functionality which is badly written will force it being properly implemented soon
[00:26] <Daemon404> you can dump -compressed- frames
[00:26] <Daemon404> with image2
[00:27] <Daemon404> i.e. if i have a huffyuv compressed file in avi
[00:27] <Daemon404> image2 can dump those huffyuv frames
[00:27] <Daemon404> demux and dump them
[00:27] <Daemon404> in to a file per frame
[00:27] <Daemon404> no container
[00:27] <Daemon404> that is useful for intermediate REing
[00:27] <durandal_1707> and what that have to do with separating planes?
[00:28] <Daemon404> it doesnt, but it related to image2
[00:28] <Daemon404> and 'raw' to an extend
[00:28] <Daemon404> in that image2 doesnt do any muxing
[00:29] <durandal_1707> there is code in image2 muxer which write some jp2 bits i gonna remove that to
[00:29] <Daemon404> basically, if it can sitll do what i just described, after your patch, im fine with it
[00:29] <Daemon404> is all im saying.
[00:29] <Daemon404> nothing more, nothing less.
[00:30] <durandal_1707> Daemon404: can you provide example so i can make sure that functionality is preserved?
[00:31] <Daemon404> -i someunknownfile.avi -f image2 -c:v copy -an %02d.raw
[00:31] <Daemon404> might work
[00:31] <Daemon404> i cant remember teh exact syntax
[00:32] <durandal_1707> Daemon404: i removing this crap:
[00:33] <durandal_1707> -i somefile -f image2 out.y
[00:37] <durandal_1707> it is triggered only for .y extension
[00:37] <durandal_1707> so your case should still work
[00:37] <durandal_1707> i failed to find reviews for commit which introduced such code
[00:40] <Daemon404> git blame
[00:41] <Daemon404> i have a feeling i know who it was who comitted it
[00:44] <durandal_1707> try guessing 3 times: (i know)
[00:48] <ubitux> b4097b13d4f290664630df0c05acf4e62e64d5d3 for j2k part, and i'd say 55cf1959521b0d8db6b9153265c6a48436f5f221 for the rest
[00:55] <durandal_1707> j2k part is dead code - nothing sets extradata for such codec, and this is worst place to put such code
[00:57] <durandal_1707> the y raw part is unmaintaned code - it should be removed or properly fixed
[00:58] <michaelni> durandal_1707, tell me whats broken in the y code and iam happy to fix it
[00:59] <durandal_1707> i already replied by mail
[01:00] <michaelni> ok, ill look into it ASAP
[01:16] <saste> btw seeking rawvideo files with ffplay is borken
[01:18] <cone-480> ffmpeg.git 03Stefano Sabatini 07794cea588cc5: examples/demuxing: dump input information *after* trying to open audio stream
[01:18] <cone-480> ffmpeg.git 03Stefano Sabatini 077f6f8f642c33: examples/demuxing: fix braino
[01:32] <cone-480> ffmpeg.git 03Michael Niedermayer 076dfcc7abdd5c: img2enc: ensure that the codec is rawvideo for split planes mode.
[01:32] <cone-480> ffmpeg.git 03Michael Niedermayer 0767ee2d2f6d89: img2enc: check pix_fmt for split planes mode.
[01:32] <cone-480> ffmpeg.git 03Michael Niedermayer 07db012e161e86: img2enc: Fix yuva with yuv split planes.
[01:46] <cone-480> ffmpeg.git 03Michael Niedermayer 072c875651473f: img2enc: support storing alpha planes too in split plane mode
[02:01] <durandal_1707> michaelni: yuva444p16 does not work
[02:31] <cone-480> ffmpeg.git 03Michael Niedermayer 0752c40a0e52ea: MAINTAINERS: fix entry for img2
[02:31] <cone-480> ffmpeg.git 03Michael Niedermayer 072a0dfc51ea9c: img2enc: support 16bit per sample yuv in split planes.
[04:19] <cone-480> ffmpeg.git 03Marton Balint 07747c749d425e: ffplay: adjust external clock speed based on buffer fullness for realtime sources
[04:19] <cone-480> ffmpeg.git 03Michael Niedermayer 076a302331dd02: Merge remote-tracking branch 'cus/stable'
[07:43] <nevcairiel> Daemon404: what fate failure, fate passes fine on msvc
[07:45] <Daemon404> oh it got fixed
[07:47] <nevcairiel> ffmpeg still doesnt compile in msvc shared unless you disable the aac encoder, but what can you do
[10:28] <ohsix> ok now i have to ignore the bug bot because i made the mistake of clicking on some
[11:02] <ods15> ubitux, heh, it does look bad... in principle, it's no worse than what is in vorbis_encode_frame(), where the size is also decided "externally". The only real way to solve it would be dynamic realloc, which would be an extensive change to putbitcontext
[11:03] <ods15> (the other horrible way of solving it would be dry run and then alloc...) both of these methods suck and not really worth it imo
[11:03] <ubitux> the problem is mainly that it's on the stack
[11:05] <ohsix> a stacksplosion
[11:08] <ods15> oh, it bothers you it is stack instead of heap? feel free to switch to malloc, that should be easy
[11:09] <ubitux> ods15: the issue was raised from mplayer mailing list
[11:09] <ubitux> someone was willing to add more huge stack buffers
[11:09] <ubitux> saying there were some all around
[11:09] <ubitux> and this one was in the list
[11:29] <cone-11> ffmpeg.git 03Stefano Sabatini 07e8c0b6710cec: examples/muxing: fix typo: allocated -> allocate
[11:37] <cone-11> ffmpeg.git 03Stefano Sabatini 07d658f9a1cb87: doc/ffserver: fix typos/reword paragraphs about FFM versions
[11:40] <ubitux> i've done a forward R->C rdft, and then inverse C->R rdft to get the value back
[11:40] <ubitux> it seems they are not normalized, so i tried to divide them by 1/sqrt(N), N being the 1<<nbits
[11:40] <ubitux> it doesn't seem to work
[11:40] <ubitux> 1/(2*sqrt(N)) works for nbits=4, but doesn't for a different value
[11:41] <ods15> ubitux, you're right, it's probably bad practice... not sure how much effort should be spent in fixing the old code, but new code shouldn't be that way
[11:41] <ubitux> what's the common way to normalize these values?
[11:45] <ubitux> ods15: that buffer is one of the bigger one, there shouldn't be much fix to do
[11:45] <ubitux> (it's likely the biggest stack one)
[11:47] <ubitux> (according to a git grep -E '\[[0-9]{5}')
[11:47] <ubitux> most of the other buffers here are either static tables, or in a heap allocated struct
[11:59] <cone-11> ffmpeg.git 03Alexander Strasser 0723b57b020305: doc/libavcodec: improve wording in description
[11:59] <cone-11> ffmpeg.git 03Alexander Strasser 0798506e16c790: doc/libavcodec: do not say multimedia streams in the title
[12:02] <ubitux> also, i'd be curious to know if it's possible to know the range of the frequencies input in advance
[12:03] <ubitux> (if given N samples of range (0,1) we can know the range of N/2+1 complex samples in output)
[12:04] <ubitux> i guess that's related
[12:24] <cone-11> ffmpeg.git 03Stefano Sabatini 07a1934daeb4e1: doc/Makefile: remove .3 file with make clean
[12:24] <cone-11> ffmpeg.git 03Stefano Sabatini 07f6b39376cea4: .gitignore: ignore *.3 files as well
[13:31] <ubitux> saste: thx for the .3
[13:44] <saste> michaelni, what's the point of fe0089a6edb974f000b7f8dced4d6c6c3c5f2985?
[13:58] <cone-11> ffmpeg.git 03Paul B Mahol 070fe8c9f45858: wavpack: use more meaningful error codes
[14:14] <saste> michaelni, -fdebug?
[14:15] <michaelni> saste, liek the comit msg of fe0089a6edb974f000b7f8dced4d6c6c3c5f2985 says, it fixes -qscale X breaking audio codecs
[14:15] <michaelni> fdebug ?
[14:16] <ubitux> i'm far from being an asm expert, but in the mips patch, in float_to_fixed24_mips(), would it make sense to group the instructions per accesses instead of per instruction type?
[14:16] <ubitux> (also it would be easier to macrotize it)
[14:17] <ubitux> i mean, isn't it more "cache efficient" to group the memory accesses?
[14:17] <saste> michaelni,  s = av_asprintf("q%s", opt + 6);?
[14:17] <saste> in opt_qscale()
[14:18] <saste> basically qscale is just a shortcut for q:a q:v
[14:18] <ohsix> ubitux: usually to make sure they're far enough apart :p or there's enough cache that the working set doesn't thrash
[14:18] <saste> which in turns is just a shortcut for: set the qscale flag, and set the value of quality (rescaled)
[14:18] <ubitux> ohsix: right, there are likely pretty close now
[14:18] <saste> so why was -qscale added?
[14:21] <saste> also what's -fdebug useful for, since it is just another alias for -debug?
[14:21] <ubitux> wasn't -qscale the original option name, which was specifically meant to work only on video?
[14:21] <michaelni> saste, do you want to take over ffmpeg*.c maintaince ? iam asking because it is inpractical to explain every trivial bugfix to everyone
[14:22] <ubitux> iirc there was -q/-qscale for video, and -aq for audio
[14:22] <michaelni> ubitux, yes
[14:22] <ubitux> and then it was merged to a common -q:[av] option
[14:22] <michaelni> yes and that broke audio
[14:22] <saste> michaelni, i'm trying to understand the code, having undocumented features (not even explained in the commit log), is not that practical
[14:22] <ubitux> and thus -q/-qscale then affected -aq
[14:22] <ubitux> and so it changed the defualt behaviour
[14:23] <ubitux> unless you explicited the :[av]
[14:23] <ubitux> saste: is that answering your question?
[14:23] <ubitux> michaelni: btw, any idea for my normalization question about rdft?
[14:23] <saste> ubitux, yes
[14:24] <michaelni> ubitux, dont remember the question exactly but IIRC each *ft adds a sqrt(n) factor
[14:24] <michaelni> so rescaling should be abou *n
[14:24] <michaelni> after rdft + inverse
[14:24] <michaelni> but thats from memor
[14:24] <michaelni> y
[14:24] <ubitux> it seems not to suffice unfortunately
[14:24] <ubitux> or i miss something
[14:25] <ubitux> lemme me simplify my code to show the problem..
[14:25] <michaelni> saste, fdebug is libavformat debug libavcodec
[14:25] <michaelni> f for format
[14:27] <saste> i see
[14:27] <ubitux> michaelni: http://pastie.org/5334618 ’ http://pastie.org/5334619
[14:27] <saste> i'd suggest to deprecate -qscale, since right now it is only causing confusion and bloat
[14:28] <ubitux> michaelni: if i replace samples[i] = samples[i] * (1./sqrt(1<<N)) with samples[i] = samples[i] * (1./(2*sqrt(1<<N))); it works as expected
[14:28] <ubitux> but not if I increase N
[14:28] <ubitux> so just a "lucky shot"
[14:31] <ubitux> (the code is just generating 1<<N random samples, doing a forward rdft, then inverse, then renormalize)
[14:34] <ubitux> saste: i don't see the point with deprecating -qscale
[14:34] <michaelni> ubitux, by what factors is it wrong per N or is it wrong in a way digfferent from just scaling?
[14:34] <ubitux> we have -q/-qscale:[av], seems pretty nice
[14:36] <ubitux> michaelni: http://pastie.org/5334652 N=4 f=1/(2*sqrt(1<<N))
[14:36] <ubitux> michaelni: http://pastie.org/5334655 N=5, same factor
[14:36] <ubitux> as you can see, with N=4 it's fine, and N=5 doesn't match
[14:37] <saste> ubitux, would be much nicer without the redirect, you could make qscale an alias for -q, but the previous -qscale only applied to video, so it had a different semantics
[14:37] <ubitux> saste: current -qscale still applies to video only
[14:37] <saste> right now it is just confusing, and add (a little) to the bloat you have to read/understand when looking through the file
[14:37] <ubitux> and just warn about that
[14:38] <saste> ubitux, yes, i'm not saying that it should be removed since it is a useful backward compatibility layer, but that we should deprecate it
[14:38] <saste> and remove (e.g. in two releases)
[14:39] <ubitux> it is kind of deprecated
[14:39] <ubitux> since it warns about it
[14:40] <ubitux> i'm not sure that's really cluttering anything
[14:40] <ubitux> the function is pretty straightforward to me
[14:40] <saste> also qscale is a libavcodec option (a flag), which adds to the confusion
[14:41] <saste> not that much, for example i missed the point that opt could have been qscale:a, so couldn't figure out the second part of the function
[14:41] <ubitux> we use that trick in one or two others options as well iirc
[14:42] <ubitux> old2new() iirc for example
[14:43] <ubitux> well anyway, i can't say much about it, i just don't see a real problem here :p
[14:44] <ubitux> and the benefit of not breaking scripts "for free" while instructing the user with a warning sounds like the most wise choice
[14:46] <saste> ubitux, medium-term backward compatibility = good
[14:46] <saste> ethernal backward compatibility -> bad
[14:47] <ubitux> for commonly used options i sounds good to keep it a little longer IMO
[14:47] <saste> for maintainance reasons, and you have to balance maintainability and backward usability
[14:47] <ubitux> here, the problem is that breaking the backward compat will provoke a bad behaviour without noticing the user
[14:48] <ubitux> we have several options that works like -xxx[:av]
[14:48] <ubitux> the generic one (without the [:av]) always applies to a & v (afaict)
[14:48] <ubitux> if we start doing this at some point
[14:48] <ubitux> and a user jump from 0.5 to 1.1
[14:49] <ubitux> the behaviour of his command will just change in an expected way, without him to notice at first
[14:49] <ubitux> OR
[14:49] <ubitux> we would have to "break" -qscale/-q when the [:av] is not specified
[14:49] <ubitux> but this would be inconsistent with the other options with -xxx[:av] syntax
[14:50] <ubitux> right now, it's inconsistent for backward compat but the user is immediately aware of the problem, and things just work as expected
[14:50] <ubitux> so it looks like a sane choice to me
[14:51] <ubitux> (tell me if i'm not clear again)
[14:51] <saste> ubitux: i rephrase my question, would be OK with deprecating -qscale and dropping it in 1/2 releases?
[14:51] <ubitux> deprecating -qscale[:av] or just -qscale?
[14:51] <saste> -qscale
[14:52] <ubitux> what would happen if the user specifies -qscale?
[14:52] <saste> so you're forced to use -q:SELECTOR
[14:52] <ubitux> how would it break?
[14:52] <ubitux> i mean, what will be the message?
[14:52] <ubitux> unrecognized option?
[14:52] <saste> just a warning, ehy pal change this option or this will break later
[14:52] <ubitux> (we don't do that for any -xxx[:av] option, that's why i'm asking)
[14:52] <ubitux> no i mean when it's dropped
[14:53] <ubitux> what would become the cmd line?
[14:53] <ubitux> err
[14:53] <ubitux> the result*
[14:53] <saste> -qscale => -q:v
[14:53] <ubitux> i mean, what will be the error?
[14:53] <ubitux> default "unrecognized option"?
[14:53] <michaelni> saste, least maintaince burden is to leave it as it is
[14:54] <michaelni> if we change it its maintaince burden on users fixing their memory and scripts
[14:54] <michaelni> and us awnsering more user questions
[14:54] <michaelni> also i maintain ffmpeg*.c so its burden i have to cary
[14:54] <iive> I don't quite get, what is the problem with qscale.
[14:55] <ubitux> saste: the problem i see with only supporting -qscale:a/v and -qscale resulting in an unrecognized option is that all the option -xxx[:av] options have a working -xxx, so even power user will be surprised
[14:55] <ubitux> unless you add a specific message
[14:55] <ubitux> but if you do so, you will just have almost the same code as now
[14:55] <ubitux> except that it will just abort instead of fallback to another behaviour
[14:56] <saste> ubitux, i never said that, right now we have this
[14:56] <saste> qscale == q:v, for the rest equal to q
[14:56] <saste> so the point is, what's the utility of qscale (apart saving backward compat)? none
[14:57] <ubitux> <@saste> qscale == q:v, for the rest equal to q // i'm unable to parse after the comma, what do you mean?
[14:57] <saste> also qscale/q is special, since it is a combo (set qscale flag, set rescaled quality factor)
[14:58] <ubitux> i'd say the second utility of -qscale is just to match the syntax of other -xxx[:av] option
[14:58] <ubitux> (even if it warns about a particular behaviour)
[15:00] <saste> ubitux, i see, but all the special casing is getting a bit bizantine
[15:00] <ubitux> it looks pretty small to me
[15:00] <ubitux> and user friendly
[15:04] <knotmaker> Hi I'm trying to run this on an AWS micro instance 
[15:04] <knotmaker> ffmpeg  -i 1.caf test.wav
[15:04] <knotmaker> but getting error "Sample depth 32 is not supported."
[15:05] <knotmaker> does anyone have a clue what's wrong in my code
[15:12] <durandal_1707> how to select stream with ffmpeg ?
[15:15] <Compn> knotmaker : our caf support doesnt have support for 32bit caf files i guess , upload your sample
[15:16] <cone-11> ffmpeg.git 03Diego Biurrun 07352e18b76665: x86: avresample: Add missing colons to assembly labels
[15:16] <cone-11> ffmpeg.git 03Diego Biurrun 0706c7b3383145: fate: aac: cosmetics: Group AAC LATM tests together
[15:16] <cone-11> ffmpeg.git 03Diego Biurrun 07e6c4c0f7cfaf: fate: atrac: Place atrac1 and atrac3 tests in different groups
[15:16] <cone-11> ffmpeg.git 03Michael Niedermayer 071e4e4979117e: Merge remote-tracking branch 'qatar/master'
[15:17] <durandal_1707> Compn: 32bit pcm in caf is supported
[15:17] <durandal_1707> knotmaker: use pastebin or similar to paste full uncut console output
[15:18] <Compn> maybe its old ffmpeg :P
[15:18] <knotmaker> http://hnc-dev.codewalla.com/hnc/1.caf
[15:19] <knotmaker> this is the caf file
[15:19] <ubitux> durandal_1707: huh? -map? :/
[15:21] <ubitux> knotmaker: there is an io error but output wav is playable for me
[15:21] <durandal_1707> knotmaker: what is your goal?
[15:21] <durandal_1707> knotmaker: 32 bit pcm seems to not be supported by wav container
[15:21] <durandal_1707> and caf sample you have is 32bit alac
[15:21] <knotmaker> i want to convert caf to mp3
[15:21] <knotmaker> this is the error http://pastebin.com/QBizxaT5
[15:22] <ubitux> missing beginning of the output
[15:22] <ubitux> and command line
[15:22] <nevcairiel> the alac decoder probably doesnt to 32-bit from the log
[15:22] <ubitux> the pasted sample works pretty fine
[15:22] <durandal_1707> actually wav supports 32 bit pcm
[15:23] <durandal_1707> it is just by default downscaled to 16 bit pcm - which is bad
[15:23] <nevcairiel> 32-bit support in alac is relativly new
[15:23] <nevcairiel> from july
[15:23] <ubitux> ffmpeg -i 1.caf -c:a pcm_s32le test.wav works fine
[15:23] <ubitux> ffmpeg -i 1.caf test.wav works fine too
[15:23] <nevcairiel> so might not be in 0.11
[15:23] <durandal_1707> knotmaker: you are using old version without 32 bit support for alac
[15:24] <ubitux> this is a user question btw&
[15:24] <nevcairiel> get ffmpeg 1.0, or better, a recent git build, and it should work just fine
[15:24] <knotmaker> update error log http://pastebin.com/NuJzp1g0
[15:24] <ubitux> this is not ffmpeg
[15:24] <knotmaker> i am using 0.8 version
[15:24] <ubitux> nope
[15:25] <ubitux> you're using a forked version of ffmpeg
[15:25] <ubitux> and old yes
[15:25] <nevcairiel> my guess is that you're on ubuntu or debian which claim you are using ffmpeg, but in reality, you are not
[15:25] <durandal_1707> ubitux: not user question if its log ask to contact ffmpeg devs ;)
[15:26] <durandal_1707> but log says to contact libav-devel ml
[15:26] <nevcairiel> yeah, it says to contact libav devs :P
[15:27] <ubitux> knotmaker: for further questions (such as how to upgrade), please join #ffmpeg, or the channel of the fork you are using
[15:27] <ubitux> depending on what you wanna do
[15:27] <knotmaker> ok
[15:28] <ubitux> thanks :)
[15:46] <durandal_1707> michaelni: wv demuxer is so brain dead that there is no robust way to find out correct flags for packet, so if wv file changes channels midstream muxer is screwed up
[15:46] <durandal_1707> ubitux: so how to select nth audio stream?
[15:47] <ubitux> -map:a n ?
[15:54] <durandal_1707> michaelni: so is it fine to rewrite wv demuxer and decoder?
[15:58] <cone-11> ffmpeg.git 03Peter Ross 079632f5efcf48: wtvenc: fix typo
[15:58] <cone-11> ffmpeg.git 03Peter Ross 071701a22fce3e: wtv: rename ff_stream_guid to ff_SBE2_STREAM_DESC_EVENT
[15:58] <cone-11> ffmpeg.git 03Peter Ross 07e6ef628b1efb: wtv: move duplicated guids into wtv.c
[16:00] <michaelni> durandal_1707, if you maintain them after that in your git repo and integrate all improvments from libav, sure, rewrite them
[16:02] <durandal_1707> it is not big rewrite just adding/removing few lines
[16:03] <michaelni> well then maybe "rewrite" is the wrong term, i dont know what your plans are ...
[17:16] <cone-11> ffmpeg.git 03Paul B Mahol 074744f67d4fe8: wavpack: check if number of samples is not too big
[17:24] <cone-11> ffmpeg.git 03Paul B Mahol 071c445f4b93a0: fate: add PMP demuxer test
[18:20] <durandal_1707> is there fate with libvpx enabled?
[18:54] <cone-11> ffmpeg.git 03Michael Niedermayer 072ca649f177e0: utils: fix integer overflow with DURATION_MAX_READ_SIZE
[21:44] <cone-11> ffmpeg.git 03Michael Niedermayer 0744e9d7f182bb: vf_drawbox: dont move uninitialized and then unused colors around
[21:52] <cone-11> ffmpeg.git 03Nicolas George 07e9b8523d52ca: sbgdec: dont set slide to a uninitialized value
[22:50] <cone-11> ffmpeg.git 03Stefano Sabatini 075f634480d1c4: lavfi/showwaves: simplify check in filter_samples()
[22:50] <cone-11> ffmpeg.git 03Stefano Sabatini 07b5436f4b5dae: lavfi/showwaves: return error in case of allocation failure in filter_samples()
[23:00] <cone-11> ffmpeg.git 03Stefano Sabatini 0729d46d7bce1c: ffprobe: fix potential NULL pointer dereference
[23:05] <ubitux> :)
[23:21] <durandal_1707> i get pops when using trellis with adpcm what could cause this?
[23:36] <cone-11> ffmpeg.git 03Stefano Sabatini 072b442ff5f5c1: lavfi/movie: return proper error code in case of av_get_token() allocation failure
[23:39] <saste> uhm coverity down?
[23:41] <ubitux> saste: seems to
[23:41] <ubitux> at least very slow.
[00:00] --- Wed Nov  7 2012