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

[burek]

[00:28] <CIA-41> ffmpeg: 03Nicolas George 07master * r752344dada 10ffmpeg/libavfilter/ (af_amerge.c af_astreamsync.c af_pan.c): 
[00:28] <CIA-41> ffmpeg: amerge/astreamsync/pan: fix license boilerplate.
[00:28] <CIA-41> ffmpeg: The boilerplate states that the files are under LGPL,
[00:28] <CIA-41> ffmpeg: but refer the user to the GPL at one place.
[00:28] <CIA-41> ffmpeg: These files were (re)implemented specifically for FFmpeg.
[01:05] <durandal_1707> michaelni: 333 line of lavfi/vf_select.c looks strange to me
[01:50] <ubitux> it's likely the same as if ((ret = ff_start_frame()) < 0) return ret; if ((ret = ff_draw_slice()) < 0) return ret; ret = ff_end_frame(); return ret;
[01:51] <ubitux> it just make use of the || to put only one return ret in case of both success & failure
[01:51] <ubitux> i guess.
[01:52] <ubitux> i agree it looks weird :)
[01:53] <ubitux> maybe that wasn't intended
[02:46] <durandal_1707> kierank: do you know mp2 decoder which supports vbr?
[02:57] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r31d8261cde 10ffmpeg/libavformat/mpeg.c: 
[02:57] <CIA-41> ffmpeg: mpegprobe: fix misdetection of mp3
[02:57] <CIA-41> ffmpeg: Fixes tikcet1524
[02:57] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:08] <ubitux> saste: did you have a look to the aformat issue last of the other day?
[14:11] <ubitux> (wget 'lucy.pkh.me/samples/6ch.flac' && ./ffplay -f lavfi 'amovie=6ch.flac,aformat=channel_layouts\=stereo')
[14:15] <CIA-41> ffmpeg: 03Clément BSsch 07master * rbc42682749 10ffmpeg/libavformat/ (movenc.c movenc.h): 
[14:15] <CIA-41> ffmpeg: lavf/movenc: fix invalid free with timecode meta and tmcd data copy.
[14:15] <CIA-41> ffmpeg: Fixes ticket 1577.
[14:26] <saste> ubitux: seems a problem in the channels laytout conversion
[14:51] <CIA-41> ffmpeg: 03Piotr Bandurski 07master * ra2232e696b 10ffmpeg/libavcodec/cllc.c: 
[14:51] <CIA-41> ffmpeg: cllc: fix typo in the error message
[14:51] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:51] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r71a5cd7dbc 10ffmpeg/libavformat/flvdec.c: 
[14:51] <CIA-41> ffmpeg: flvdec: perform duration search just once
[14:51] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:51] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r231ffb9243 10ffmpeg/libavformat/flvdec.c: 
[14:51] <CIA-41> ffmpeg: flvdec: follow packets backward until a valid last timestamp is found
[14:51] <CIA-41> ffmpeg: Fixed Ticket981
[14:51] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:59] <CIA-41> ffmpeg: 03Clément BSsch 07master * re39f6a3a5c 10ffmpeg/ (libavcodec/crystalhd.c libavfilter/vf_libopencv.c): Fix misc swapped dot and carriage returns in av_log calls.
[15:29] <saste> funny i never noticed it...
[15:43] <ubitux> :)
[16:31] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * r39a8275fdf 10ffmpeg/ (5 files in 2 dirs): lavfi: move color filter to testsrc, factorize
[16:32] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * r44bd69e9b9 10ffmpeg/libavcodec/ (internal.h utils.c): 
[16:32] <CIA-41> ffmpeg: lavc/utils: rename ff_init_buffer_info() pic parameter to frame
[16:32] <CIA-41> ffmpeg: The new name is more expressive, given that the frame is not necessarily
[16:32] <CIA-41> ffmpeg: a picture but may be an audio frame.
[16:32] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * rb99381e8b5 10ffmpeg/libavcodec/utils.c: 
[16:32] <CIA-41> ffmpeg: lavc/utils: generalize ff_init_buffer_info() and use it when seems feasible
[16:32] <CIA-41> ffmpeg: Extend ff_init_buffer_info() to init audio frames as well as video
[16:32] <CIA-41> ffmpeg: frames.
[16:32] <CIA-41> ffmpeg: Avoid code duplication.
[16:35] <fj> hello we are upgrading our old ffmpeg library to the latest version
[16:35] <fj> it seems that AVFormatParameters is taken out of the new version
[16:35] <fj> what should I use instead?
[16:36] <fj> doc/APIchanges only mentions it is deprecated but not what it is replaced with
[16:37] <saste> fj: use format options, an AVDictionary with the corresponding options you used before
[16:38] <saste> also note this is the channel for development *on* ffmpeg, not *with* ffmpeg
[16:40] <saste> seems like we miss a *demuxing* example
[16:42] <fj> oh okay thanks and sorry
[16:57] <ubitux> michaelni: i've trouble parsing "that would make sense, but may with frames drops fail to be what its expected to be"
[17:01] <michaelni> drop every 3rd frame and instead of 30fps you have 20fps which would fail
[17:01] <michaelni> the timebase still might be 30 though
[17:13] <ubitux> mmh..
[17:18] <michaelni> ubitux, you can also try r_frame_rate ....
[17:18] <CIA-41> ffmpeg: 03Paul B Mahol 07master * rd84dd35f8e 10ffmpeg/ (3 files in 2 dirs): 
[17:18] <CIA-41> ffmpeg: paf: fix audio packet duration
[17:18] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[17:28] <durandal_1707> michaelni: is there way to find out host cpu fpu is slow?
[17:45] <michaelni> probably needs to be handled like the other HAVE_FAST things
[17:45] <michaelni> that is listing in configure like fast_64bit_if_any=...
[17:45] <michaelni> fpu is fast on x86, alpha and ppc probably and slow on arm
[17:47] <michaelni> the ones between can be filled in by the fans of these architectures, they should know better anyway
[17:48] <michaelni> also modern arm isnt really slow in terms of fpu but i think we have not much float optims but more fixed optims for arm
[17:48] <michaelni> and floatmp3 is a bit slower than fixed with all optims disabled on my panda board
[17:49] <michaelni> but maybe that wasnt all, i guess i should recompile with disable-asm
[18:31] <kierank> durandal_1707: i don't understand you and the smpte bars filter
[18:32] <durandal_1707> both! :) can you elaborate?
[18:33] <kierank> "For the record I do not really care what colors will be picked...."
[18:35] <durandal_1707> it is about colors which can not be represented in rgb/yuv colorspace
[18:38] <durandal_1707> michaelni: fixed point encoder is faster than float one
[18:40] <durandal_1707> on my machine
[18:41] <durandal_1707> kierank: do you know mp2 decoder which supports vbr files produced with twolame?
[18:41] <kierank> nothing
[18:41] <kierank> it's an experimental feature
[18:42] <durandal_1707> well mono works fine with lavc
[18:42] <kierank> i mean nothing is guaranteed to work
[18:42] <kierank> mp2 is inherently cbr
[19:27] <nevcairiel> michaelni: why did you keep the libmpeg2 idct? does it serve any purpose at all?
[19:30] <ubitux> saste: i'm trying to make showspectrum "reconfigure compliant" (to support resize for instance)
[19:30] <ubitux> should i assume config_output() callback could be called any time?
[19:31] <ubitux> (and thus half destroy stuff in the context and recreate then depending on the new params)
[19:31] <ubitux> also, is there any way to test such thing?
[19:46] <ubitux> http://ubitux.fr/pub/pics/_mismatch-spectrums.png mmh looks like there is still a bug.
[20:01] <michaelni> nevcairiel, any files encoded using that idct need it to be cleanly decoded
[20:02] <JEEB> yay non-specified stuff
[20:02] <JEEB> (I think H.264 was the first one that standardized stuff like that?)
[20:02] <michaelni> yes
[20:03] <iive> nevcairiel: the early version of xvid used it. If it is not used on decoding there is a green tilt.
[20:04] <iive> iso14496 defines precision constraints for the idct, this allowed extending keyframe interval to 300 frames. xvid failed on that, at first.
[20:08] <michaelni> durandal_1707, if fixed encoder is faster then i dont mind if its default
[20:10] <michaelni> btw, mp3float is faster than fixed on ARM too if all asm is disabled
[20:10] <michaelni> that is decoder
[20:14] <michaelni> also about the idct, theres another reason why id liek to keep it, if some file shows artifacts that look like idct rounding i liek to be able to test all idcts to see if any fixes it
[20:19] <durandal_1707> michaelni: mp2 decoder is "prefered" over mp2float....
[20:38] <michaelni> durandal_1707, both encoders should be tested in fate
[20:50] <durandal_1707> michaelni: ok, i will push patch once fate passes
[20:53] <durandal_1707> michaelni: would fixed point mp2 encoder need CMP_SHIFT ?
[21:09] <michaelni> durandal_1707, it should, yes
[21:11] <durandal_1707> saste: what is happening with socis?
[21:15] <ubitux> saste: i'm changing the internals based on outlink->h
[21:17] <ubitux> i could use the width as well
[21:22] <ubitux> saste: right now i'm doing it like this: https://github.com/ubitux/FFmpeg/commit/fc49236cb6ab5aa80cb858631798078079a31acc#L2R138
[21:33] <CIA-41> ffmpeg: 03Michael Bradshaw 07master * ra763cafc0c 10ffmpeg/libavcodec/libopenjpegdec.c: 
[21:33] <CIA-41> ffmpeg: libopenjpegdec: increase max lowres from 5 to 31
[21:33] <CIA-41> ffmpeg: OpenJPEG doesn't have a particular limit
[21:33] <CIA-41> ffmpeg: Signed-off-by: Michael Bradshaw <mbradshaw at sorensonmedia.com>
[21:33] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:44] <ubitux> Daemon404: so does libclang looks like appropriate for the convert tool?
[22:44] <Daemon404> ubitux, of course it is
[22:45] <Daemon404> we need an actual c99 parser
[22:45] <ubitux> i'm curious, it looked interesting last time you mention it
[22:45] <ubitux> and certainly smarter than the other propositions
[22:45] <ubitux> did you succeed in some PoC already?
[22:45] <Daemon404> people want to use dumb regex in scripts or custom token parsing
[22:45] <Daemon404> id prefer an actual c parser.
[22:45] Action: ubitux agrees :)
[22:46] <Daemon404> unfortunately im running into an issue
[22:46] <Daemon404> anonymous structs inside otehr struct declarations
[22:46] <Daemon404> make it a massive PITA
[22:46] <Daemon404> c99 'feature;
[22:46] <ubitux> that's handy ;)
[22:47] <Daemon404> itsn ot handy
[22:47] <Daemon404> its ugly
[22:47] <Daemon404> and poor practice
[22:47] <ubitux> that's discussable
[22:47] <ubitux> do we have a lot of them?
[22:47] <Daemon404> we have a lot of stuff like
[22:47] <Daemon404> typedef struct foo {
[22:47] <Daemon404>     int a;
[22:47] <Daemon404>     struct some_struct *b;
[22:47] <Daemon404> } foo;
[22:48] <Daemon404> strict some_struct {
[22:48] <Daemon404>     ....
[22:48] <Daemon404> };
[22:48] <Daemon404> (below)
[22:48] <nevcairiel> how is that bad? its just a opaque pointer at the point, who cares what it really is
[22:48] <Daemon404> and clangsp arser is telling me struct some_struct *b; is a new struct decl
[22:49] <ubitux> mmh ok
[22:49] <Daemon404> nevcairiel, see what i just said
[22:49] <Daemon404> its a pain to parse
[22:49] <nevcairiel> sounds like clang just fails at that, the feature is fine imho
[22:49] <Daemon404> than if it just returned teh type as struct member
[22:49] <ubitux> i thought you were talking about sth like struct bla { struct { int i, j; } foo; }
[22:50] <Daemon404> i was too
[22:50] <Daemon404> but tahts far more horrid
[22:50] <ubitux> :)
[22:50] <ubitux> and so libclang has trouble with that?
[22:50] <Daemon404> im sure there is a way to tell
[22:50] <Daemon404> but i bet it involves some sort of introspection
[22:50] <Daemon404> and clang ahs no real dev docs
[22:50] <Daemon404> just doxygen
[22:50] <Daemon404> (sound familiar?)
[22:50] <ubitux> reminds me some project
[22:50] <ubitux> :DD
[22:50] <JEEB> :D
[22:51] <nevcairiel> lacking doxy too?
[22:51] <Daemon404> dont worry,  my parser can never be put into teh repo
[22:51] <Daemon404> i used c++ for easy queues and stacks
[22:51] <ubitux> you'll burn in hell for that
[22:51] <nevcairiel> gotta have some convenience here and there
[22:52] <JEEB> :)
[22:52] <Daemon404> at first i looekd for a lib for c
[22:52] <Daemon404> but was like... fuck that
[22:52] <Daemon404> :WHY:
[22:52] <ubitux> there is no python libclang binding?
[22:52] <Daemon404> ubitux, thats even worse
[22:52] <Daemon404> there is doxy fr teh c api
[22:52] <ubitux> why?
[22:52] <Daemon404> with real words
[22:52] <ubitux> ah you mean from a doc PoV ok
[22:52] <Daemon404> teh python api is a swig-generated python file
[22:52] <Daemon404> and nothing more
[22:53] <Daemon404> not to mention the point is to be able to distribute a precompiled binary
[22:53] <Daemon404> with no debs
[22:53] <Daemon404> deps*
[22:53] <Daemon404> for windows.
[22:53] <ubitux> i forgot that detail
[22:53] <ubitux> thought some solution would have been possible, but well
[22:54] <ubitux> anyway, i'm curious about the outcome
[22:54] <nevcairiel> there is always a dependency on some kind of build system
[22:54] <Daemon404> nevcairiel, yeah but the idea is for the chroem devs, the ycan pop preproc.exe in their bin dir with yasm.exe
[22:54] <Daemon404> and they check in a config.h too
[22:54] <ubitux> Daemon404: were you able to do some convert already, or you're still trying to get an AST of the input first?
[22:54] <nevcairiel> i mean, you still need a msys or cygwin of sorts for configure
[22:55] <Daemon404> i cnat convert shit until i can parse struct defs correctly
[22:55] <ubitux> ok
[22:55] <Daemon404> nevcairiel, no, you check in teh config.h and co
[22:55] <Daemon404> for te msvc build
[22:55] <Daemon404> along with a sln
[22:55] <nevcairiel> thats somewhat on the ugly side
[22:55] <Daemon404> welcome to google
[22:55] <Daemon404> they want to get rid of all deps at all costs
[22:55] <Daemon404> etc
[22:56] <Daemon404> i wonder if i write a full functional clang-based thing, i can get google to pay me (lol)
[22:56] <Daemon404> the other thing clang makes annoying is getting the proper struct name 
[22:57] <Daemon404> depending on if it is typedef'd
[22:57] <Daemon404> and teh struct/typedef names match
[22:57] <Daemon404> or are even present
[22:57] <ubitux> Daemon404: if you succeed you should create a proper project page for this
[22:57] <ubitux> you will most likely get contribz
[22:57] <Daemon404> i know
[22:57] <Daemon404> a c++ project to convert c99 to c89
[22:57] <Daemon404> not convoluted at all. nope.
[22:59] <ubitux> what's make me sad is that someone actually needs to do that (for free?) because some company likes insulting the human being common sense
[22:59] <ubitux> but i support you in the process anyway ;)
[23:00] <ubitux> even if i don't have any interest in it myself
[23:00] <Daemon404> yes im not being paid
[23:00] <Daemon404> im doing it because it's interested
[23:00] <Daemon404> also i guess e-penis
[23:06] <ubitux> btw, http://code.google.com/p/pycparser/ looks fun.
[23:30] <CIA-41> ffmpeg: 03Derek Buitenhuis 07master * r144e4b0997 10ffmpeg/LICENSE: 
[23:30] <CIA-41> ffmpeg: LICENSE: Document all GPL files
[23:30] <CIA-41> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[23:30] <CIA-41> ffmpeg: 03Diego Biurrun 07master * r81905088a1 10ffmpeg/libavcodec/x86/h264dsp_mmx.c: x86: h264dsp: K&R formatting cosmetics
[23:30] <CIA-41> ffmpeg: 03Sean McGovern 07master * r3680b24351 10ffmpeg/libavcodec/wmaprodec.c: 
[23:30] <CIA-41> ffmpeg: wmapro: prevent division by zero when sample rate is unspecified
[23:30] <CIA-41> ffmpeg: This fixes Bugzilla #327:
[23:30] <CIA-41> ffmpeg: Signed-off-by: Kostya Shishkov <kostya.shishkov at gmail.com>
[23:30] <CIA-41> ffmpeg: 03Kostya Shishkov 07master * r7f92db14f9 10ffmpeg/libavcodec/g723_1.c: 
[23:30] <CIA-41> ffmpeg: g723_1: save/restore excitation with offset to store LPC history
[23:30] <CIA-41> ffmpeg: The same buffer with saved data is used later in LPC reconstruction, so
[23:30] <CIA-41> ffmpeg: it should have some head space for LPC history.
[23:30] <CIA-41> ffmpeg: 03Kostya Shishkov 07master * r8772d2511a 10ffmpeg/libavcodec/g723_1.c: g723_1: fix off-by-one error in normalize_bits()
[23:30] <CIA-41> ffmpeg: 03Kostya Shishkov 07master * r8ddadea171 10ffmpeg/libavcodec/g723_1.c: g723_1: make scale_vector() behave like the reference
[23:30] <CIA-41> ffmpeg: 03Kostya Shishkov 07master * r802bcdcb2f 10ffmpeg/libavcodec/g723_1.c: g723_1: fix upper bound parameter from inverse maximum autocorrelation
[23:30] <CIA-41> ffmpeg: 03Kostya Shishkov 07master * r94bfdfd6f0 10ffmpeg/libavcodec/g723_1.c: 
[23:30] <CIA-41> ffmpeg: g723_1: increase excitation storage by 4
[23:30] <CIA-41> ffmpeg: Fixed codebook mode in 5300 rate may write up to SUBFRAME_LEN + 4 and
[23:30] <CIA-41> ffmpeg: that is considered normal by the reference decoder. Without that additional
[23:30] <CIA-41> ffmpeg: padding it might overwrite first elements of LPC history.
[23:30] <CIA-41> ffmpeg: 03Diego Biurrun 07master * rca844b7be9 10ffmpeg/ (7 files in 2 dirs): 
[23:30] <CIA-41> ffmpeg: x86: Use consistent 3dnowext function and macro name suffixes
[23:30] <CIA-41> ffmpeg: Currently there is a wild mix of 3dn2/3dnow2/3dnowext. Switching to
[23:30] <CIA-41> ffmpeg: "3dnowext", which is a more common name of the CPU flag, as reported
[23:30] <CIA-41> ffmpeg: e.g. by the Linux kernel, unifies this.
[23:30] <CIA-41> ffmpeg: 03Mashiat Sarker Shakkhar 07master * r8379ea5e9f 10ffmpeg/libavcodec/vc1dec.c: (log message trimmed)
[23:30] <CIA-41> ffmpeg: vc1dec: Invoke edge_emulation regardless of MV precision
[23:30] <CIA-41> ffmpeg: In VC-1 interlaced field pictures, chroma motion vectors can extend beyond
[23:30] <CIA-41> ffmpeg: picture boundary even if luma vectors are bounded. The problem shows up
[23:30] <CIA-41> ffmpeg: only for hpel interpolated MVs, and may be due to the way motion vectors
[23:31] <CIA-41> ffmpeg: is the same for interlaced field and progressive pictures.
[23:31] <CIA-41> (10 lines omitted)
[00:00] --- Sat Aug  4 2012