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

[burek]

[00:09] <llogan> saste: thanks for pushing my old-ass patch. i forgot about that one (until that bug report).
[01:21] <llogan> so many people keep the "Patches should be submitted..." message in their bug reports.
[02:45] <highgod> Hi, when I run fate,the output print Test eval failed." Look at tests/data/fate/eval.err for details."And the teh eval.err file shows that [Eval @ 0028fe58] Undefined constant or missing '(' in ''
[02:45] <highgod> [Eval @ 0028fe58] Invalid chars 'gi' at the end of expression '1gi'
[02:45] <highgod> [Eval @ 0028fe58] Invalid chars 'Foo' at the end of expression '1GiFoo'
[02:45] <highgod> [Eval @ 0028fe58] Invalid chars 'oo' at the end of expression '1Gi*3foo'
[02:45] <highgod> [Eval @ 0028fe58] Undefined constant or missing '(' in 'foo'
[02:45] <highgod> [Eval @ 0028fe58] Undefined constant or missing '(' in ''
[02:45] <highgod> [Eval @ 0028fe58] Undefined constant or missing '(' in ')'
[02:45] <highgod> [Eval @ 0028fe58] Undefined constant or missing '(' in 'foo)'
[02:45] <highgod> [Eval @ 0028fe58] Undefined constant or missing '(' in 'sin'
[02:45] <highgod> [Eval @ 0028fe58] Undefined constant or missing '(' in ''
[02:45] <highgod> [Eval @ 0028fe58] Undefined constant or missing '(' in ')'
[02:45] <highgod> [Eval @ 0028fe58] Undefined constant or missing '(' in 'sin)'
[02:45] <highgod> How can I correct it ?thanks
[03:04] <weixuan> hi,wei
[03:38] <Compn> highgod : try rm the file and get fresh copy from git
[03:38] <Compn> i'm guessing your file got windows line endings again, maybe you saved it with notepad program! :P
[03:42] <weixuan> hi, we are tring to do the fate for our patch. when i ran the command "make fate", it reported this error:Test eval failed. Look at tests/data/fate/eval.err for details.
[03:42] <weixuan> make: *** [fate-eval] Error 126
[03:42] <weixuan> ./tests/fate-run.sh: line 70: /home/wwx/ffmpeg_patch8/ffmpeg_correct_merge1/libavutil/eval-test: Bad file number
[03:43] <weixuan> who can tell me why i got this error?
[03:44] <weixuan> thank you very much
[03:46] <highgod> Thanks Compn,you are right,I get the fate from mingw32 command window,I will use git to reget it, thanks
[03:55] <ubitux> weixuan: then you broke something
[03:55] <ubitux> make fate-eval V=1
[03:55] <ubitux> and you'll see the command used
[03:55] <ubitux> so you can reproduce
[03:58] <ubitux> highgod: there error are normal, the eval test is doing some error testing in the eval api
[03:58] <ubitux> the test should not fail though
[03:58] <ubitux> also, please use pastebin when you have more than 3 lines to paste
[04:04] <highgod> OK,I will try it thanks ubitux
[04:04] <ubitux> don't try, do
[04:04] <ubitux> ;)
[04:06] <weixuan> thank you, ubitux
[04:06] <highgod> Yes,I will do it.I mean that,my English is not good,hehe
[04:07] <ubitux> :)
[04:59] <highgod> Hi,ubitux,I run the command line "make fate-eval V=1",still the same error.And I want to ask that if I just add a test case for h264_dxva2,can I just run fate-h264? Thanks
[05:02] <ubitux> V=1 will show you the test run by fate
[05:02] <ubitux> so you can see the command line
[05:02] <ubitux> then you can reproduce that particular test and debug what's going on
[05:03] <ubitux> adding a test for your stuff should not break the rest
[05:03] <ubitux> if it does, then something is wrong with your patch
[05:03] <ubitux> and you need to debug
[05:04] <highgod> OK,Thanks
[05:09] <cone-2> ffmpeg.git 03Michael Niedermayer 07master:7b5fdd04de66: locodec: flip RGBA
[06:21] <cone-2> ffmpeg.git 03Michael Niedermayer 07master:4e0738cec9df: mpegaudiodec/mp3on4: fix buffer size.
[06:21] <cone-2> ffmpeg.git 03Michael Niedermayer 07master:b888cea9cb2a: ac3dec: split out pointer update loop for saftey
[06:32] <ubitux> anyone has a real world sample of utf16 subtitle?
[06:32] <ubitux> (one or more actually)
[06:33] <highgod> Hi,ubitux,we didn't add our fate test yet,we just run the fate suit download from ffmpeg.org use "make fate SAMPLES=fate-suite/",and the eval failed.Should I have to debug the eval fate?
[06:34] <ubitux> i believe so
[06:35] <ubitux> with a fresh checkout of ffmpeg, a make fate SAMPLES=fate-suite should work
[06:35] <ubitux> if you add modifications, it should still work
[06:54] <highgod> ubitux,the eval output error is "Undefined constant or missing '(' in 'foo'  ",I review the code,it is the function "parse_primary" error,but I didn't change code yet,and we didn't add our fate test.Is it the error of eval?
[07:20] <ubitux> as i already said
[07:20] <ubitux> these errors are fine
[07:21] <ubitux> ./libavutil/eval-test > /dev/null
[07:21] <ubitux> you'll see various eval error
[07:21] <ubitux> they are used to test eval
[07:21] <ubitux> OTOH, if the test fails
[07:21] <ubitux> then something is wrong
[10:12] <cone-513> ffmpeg.git 03Benjamin Kerensa 07master:95016fd1c8e1: Fix id3v1 tag spelling.
[10:34] <cone-513> ffmpeg.git 03Carl Eugen Hoyos 07master:2284448775f0: Revert "Fix id3v1 tag spelling."
[10:34] <cone-513> ffmpeg.git 03Carl Eugen Hoyos 07master:155cdc1d05e9: Add a comment about an intentional misspelling to the id3v1 tags.
[11:45] <saste> do we have a test for yadif?
[11:45] <saste> i can't find it...
[11:46] <ubitux> in tests/fate/filter.mak
[11:47] <saste> ubitux, why avfilter.mak and filter.mak?
[11:48] <ubitux> no idea
[11:48] <ubitux> avfilter may be related to the lavfi-regressions
[11:48] <ubitux> while filter may be independant
[11:52] <cone-513> ffmpeg.git 03Stefano Sabatini 07master:b52c1d0c993a: lavfi/yadif: remove unused poll_frame callback
[11:52] <cone-513> ffmpeg.git 03Stefano Sabatini 07master:4ea7c179325f: lavfi/yadif: fail during the configuration stage in case of invalid video size
[11:52] <cone-513> ffmpeg.git 03Stefano Sabatini 07master:8674597fe531: lavfi/yadif: remove redundant NULL checks in uninit
[11:52] <cone-513> ffmpeg.git 03Stefano Sabatini 07master:f7dc6aa6b194: lavfi/yadif: add support to named options and options introspection
[11:52] <cone-513> ffmpeg.git 03Stefano Sabatini 07master:cb8d3965fd7e: lavfi/yadif: add support to named constants
[12:04] <mateo`> hi there ! how/where are the id3 metadata transmitted from a demuxer to a muxer (typically mp3 -> mp3) ? thanks in advance !
[12:10] <saste> ubitux, yesterday i tried to add an offset option to subtitles, and it wasn't working
[12:10] <saste> libass was not recognizing events if i added an offset to time_ms
[12:12] <saste> so the question is, is it possible to specify an offset to libass?
[12:28] <J_Darnley> mateo`: metadata is read by the demuxer and put into a generic structure for any muxer to then write
[12:30] <J_Darnley> For ID3 I would suggest looking at libavformat/id3*.c
[12:31] <mateo`> J_Darnley: ok, i'm looking for the code which allocate/affect the MP3Context->id3 which is used in mp3_write_header.
[12:33] <J_Darnley> Since I don't know I can't give you an answer now.  But I'm sure I can the same searching as you to find out where that comes from.
[12:43] <J_Darnley> ID3v2EncContext (the id3 element of that stuct) is defined in id3v2.h.
[12:43] <J_Darnley> It will be allocated whenever the MP3Context is allocated.
[12:44] <J_Darnley> It will be used by the id3 functions in the write header function.
[12:45] <J_Darnley> It gets the metadata through the AVFormatContext pointer
[12:45] <J_Darnley> With this last it I really mean the id3 functions
[12:47] <ubitux> saste: sorry
[12:47] <ubitux> i was away
[12:47] <ubitux> saste: what is this offset option you are talking about?
[12:49] <ubitux> you want to offset seek?
[12:49] <saste> ubitux, no suppose there is a delay in the subtitles with respect to the video
[12:50] <saste> you want to fix the subtitles delay by adding an offset to the timestamps
[12:50] <ubitux> oh, adding, opposite to a -ss?
[12:50] <saste> i tried to change the way time_ms is computed in subtitles, but that doesn't work
[12:51] <ubitux> it should work, except when remuxing ass :)
[12:51] <saste> i want to shift back/forward in time subtitles overlay
[12:51] <saste> ubitux, but no, it doesn't
[12:51] <saste> something libass related
[12:53] <ubitux> i still don't understand what exactly you did :p
[12:55] <saste> ubitux, will send a patch/rfc
[12:55] <ubitux> okay :)
[12:55] <ubitux> note that ffmpeg -ss 12 -i in.srt -c copy out.srt should do a timing shift
[12:56] <ubitux> btw, speaking of this
[12:56] <ubitux> it could be nice to have a setpts filter not requiring a re-encode :p
[12:59] <saste> muxer-level packet filter?
[12:59] <saste> ubitux, i guess so, remuxing the subtitles file may be a suboptimal solution
[13:00] <ubitux> yes, muxer level filter
[13:01] <saste> ubitux: but that command *should not* do a time shifting
[13:01] <saste> it should just cut the first 12 seconds
[13:02] <ubitux> mmh
[13:02] <ubitux> arg that's something to fix then :$
[13:04] <mateo`> J_Darnley: thx
[13:04] <saste> so basically there is no way to add an offset to subtitles, unless we can filter them
[13:04] <saste> ubitux, do you have some specific plan with regards to subtitles filtering?
[13:05] <ubitux> saste: i'd like to have it
[13:05] <ubitux> i don't plan to work on it personally 
[13:06] <saste> but *you* are the Lord of The Subs!
[13:06] <ubitux> yes but i hate them
[13:06] <ubitux> i'm not a good lord
[13:07] <mateo`> saste: hahaha :)
[13:08] <ubitux> :(
[13:11] <cone-513> ffmpeg.git 03Clément BSsch 07master:3048fae63c99: build: Avoid detecting bogus components named 'x'
[13:11] <cone-513> ffmpeg.git 03Martin Storsjö 07master:a0b7e289075d: aviobuf: Partial support for reading in read/write contexts
[13:11] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:d0b450457b3a: matroskadec: fix ffio_init_context() usage
[13:11] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:e1cf1a9c89db: Merge commit 'a0b7e289075dccf223b7f407790d8a86fc5d77e8'
[13:22] <cone-513> ffmpeg.git 03Martin Storsjö 07master:3f95f0dda55f: rtpdec: Move the URLContext used for RTCP RR out from the context, to a parameter
[13:22] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:ea96feddb7bb: Merge commit '3f95f0dda55fca74b646937095a02a8fa9776622'
[13:28] <cone-513> ffmpeg.git 03Martin Storsjö 07master:e96406eda4f1: rtsp: Add support for depacketizing RTP data via custom IO
[13:28] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:8d0b2aae71f0: Merge commit 'e96406eda4f143f101bd44372f7b2d542183000a'
[13:30] <saste> ubitux: more comments on kerndeint?
[13:31] <ubitux> not anymor
[13:31] <ubitux> +e
[13:33] <cone-513> ffmpeg.git 03Martin Storsjö 07master:53c25ee07364: aviobuf: Discard old buffered, previously read data in ffio_read_partial
[13:33] <cone-513> ffmpeg.git 03Peter Meerwald 07master:be6cde3ce86e: lavr: fix missing " in header documentation
[13:33] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:a08194b4c51e: Merge remote-tracking branch 'qatar/master'
[14:44] <kierank> nevcairiel: whywhywhy does carl want to change h264 sar like that...
[14:48] <nevcairiel> i knew it was wrong when i saw it, but i double checked the spec anyway just in case... :p
[14:52] <nevcairiel> whats with those crazy avc intra files anyway, they come with no SPS of their own? What crazy person would develop such a system
[14:53] <JEEBsv> crazy people who want to make sure only their shit can decode those files
[14:53] <JEEBsv> same people who make a "spec" for "Pro AVC Intra" yet everyone breaks it
[14:54] <JEEBsv> like we found out in the end, practically what the MainConcept/whatever encoder/decoder combo was doing was the "spec" in the end methinks
[15:24] <kierank> 13:53:40 <JEEBsv> crazy people who want to make sure only their shit can decode those files
[15:24] <kierank> this
[15:24] <kierank> a proprietary open standard
[15:33] <saste> what's going on on multimedia.cx?
[15:33] <saste> i can't find track of "vandalized" pages
[15:53] <ubitux> saste: histeq ready for review?
[15:54] <saste> ubitux, yes
[16:01] <ubitux> oh i just noticed the "RFC"
[16:01] <ubitux> erf i'm tired
[16:08] <wm4> ubitux: I love that ffmpeg is going to get teletext decoding
[16:09] <wm4> ubitux: I haven't fully looked at the patch that was sent, but it looks like this will be exported as text?
[16:09] <ubitux> what patch are you talking about?
[16:09] <ubitux> libzvbi patch from Wolfram?
[16:09] <wm4> yes
[16:09] <ubitux> i didn't really look
[16:15] <saste> ubitux: the subtitles patch was an RFC
[16:15] <saste> the problem is related to libass, as i told you
[16:16] <ubitux> yeah i remember reading it
[16:16] <ubitux> sorry i'm a bit slow today
[16:16] <saste> maybe it expects times starting from 0 or something like that
[16:16] <saste> so i can't say what's wrong, if not looking at the libass code
[16:18] <ubitux> fun
[16:18] <ubitux> though, it's strange
[16:18] <wm4> uh what is the problem?
[16:18] <ubitux> are you sure you're not simply wrong with the timing?
[16:19] <ubitux> (like passing pts in minutes instead of seconds dunno)
[16:19] <ubitux> afaik players are able to make it work when seeking from the start
[16:22] <saste> ubitux, that's why i increased the log level
[16:23] <wm4> link to the issue?
[16:24] <ubitux> wm4: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-January/136898.html
[16:27] <wm4> is ass->offset in milliseconds or microseconds?
[16:28] <wm4> you really should have a time option type...
[16:29] <wm4> since vf_ass, in my understanding, always demuxes the subtitles completely on start, there should be no issue
[16:46] <ubitux> 16:27:53 < wm4> is ass->offset in milliseconds or microseconds?
[16:46] <ubitux> 16:28:18 < wm4> you really should have a time option type...
[16:46] <ubitux> two of my comments ;)
[16:47] <wm4> yeah, I read that
[16:47] <wm4> sorry for the redundancy
[16:47] <ubitux> vf_ass doesn't demux anything
[16:47] <ubitux> it just paste the .ass file into libass 
[16:47] <ubitux> vf_subtitles does a demux to reconstruct a fake .ass basically
[16:47] <ubitux> but no ass filter
[16:47] <ubitux> since it's already the good markup :p
[16:48] <cone-513> ffmpeg.git 03Alexander Strasser 07master:ac25b31ede03: lswr: Improve default resampler's default parameters
[16:48] <wm4> does vf_subtitles handle image subs too?
[16:48] <ubitux> nope
[16:48] <ubitux> we need a public blending api :'(
[16:48] <ubitux> so we could put the ffplay bitmap blending code into it
[16:49] <ubitux> factorize the overlay, drawtext, ass and subtitles blending
[16:49] <ubitux> and support muxed subtitles blending in ffplay :(
[16:49] <wm4> libswblend?
[16:50] <ubitux> would be nice
[16:50] <ubitux> i have a patch for ffplay to support the muxed subtitles
[16:50] <ubitux> but it uses the private api of lavfi
[16:50] <ubitux> so it can't be compiled :(
[16:50] <ubitux> (in shared)
[16:50] <ubitux> it's too bad, because i could finally watch my animes with ffplay!
[16:58] <ubitux> wm4: you going to write it?
[16:58] <wm4> what
[16:58] <ubitux> libswblend
[16:58] <ubitux> want to write it?
[16:59] <wm4> probably not
[16:59] <ubitux> :(
[16:59] <wm4> I'm not one to squish out large amounts of asm, which is probably what'd be expected here
[16:59] <ubitux> a first C version would be nice
[17:00] <ubitux> i would be happy to do it, but hell i have thousands of stuff to do before that :(
[17:01] <wm4> in mpv, we have some basic blending, that relies on swscale to bring everything into a common format
[17:05] <michaelni> wm4, first bringing things into a common format is probably the correct approach
[17:05] <michaelni> especially when adding the same subtitle onto several frames
[17:06] <michaelni> only 1 convert
[17:10] <wm4> michaelni: I mean what I'm doing is converting the regions covered by subs to 444 (essentially upsampling), blend, and convert back
[17:13] <nevcairiel> personally i subsample the overlay in such a case
[17:16] <wm4> nevcairiel: this was done with libass in mind, where multiple bitmaps are blended over the target image
[17:16] <wm4> so subsampling would lead to quality reduction
[17:17] <wm4> and converting the subs to RGBA first would probably be slower (or not, didn't really check)
[17:17] <wm4> err, not RGBA, but YUVA
[17:17] <wm4> in the common case, at least
[17:18] <durandal_1707> wm4: what is this about?
[17:18] <wm4> durandal_1707: subtitle rendering
[17:19] <wm4> nevcairiel: though, how do you deal with alpha? is it in luma and chroma resolution?
[17:19] <ubitux> durandal_1707: http://pastie.org/private/vlntkqvfbchhpk6eo0xj2a
[17:19] <nevcairiel> wm4: luma, and for chroma blending i average it
[17:20] <nevcairiel> a lot like vf_overlay works in fact
[17:22] <wm4> I guess that has less operations per pixel than the other way around
[17:31] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:c98d3056cf02: msrle: fix small palette handling
[17:38] <durandal_1707> is there >8 channel sample?
[17:47] <Compn> like 16 channel sample ?
[17:47] <durandal_1707> there is one?
[17:47] <Compn> humm
[17:48] <Compn> in what format ?
[17:48] <Compn> music producers may have such things but otherwise ...
[17:48] <durandal_1707> irellevant
[17:48] <durandal_1707> wav pcm
[17:49] <saste> i dislike when people create a new thread for each patch revision :-(
[17:50] <Compn> saste : did you write it in developer rules to keep one thread going? :P
[17:51] <saste> Compn, there are so many rules that it is impossible to honor them all
[17:51] <durandal_1707> ffmpeg cant decode wav with 512 channes
[17:51] <Compn> :D
[17:51] <Compn> wow
[17:51] <saste> durandal_1707, how did you create the sample?
[17:52] <durandal_1707> saste: people are lazy
[17:52] <durandal_1707> saste: i found it on web
[17:52] <saste> a distinct channel for each voice/instrument in a symphonic orchestra?
[17:53] <durandal_1707> i get error: [graph 0 input from stream 0:0 @ 0x29c29200] Invalid sample format '(null)'
[17:54] <saste> uh-oh
[17:54] <wm4> audiophiles will kill you
[17:54] <saste> sure reporting sucks hard
[17:54] <saste> there is a missing check somewhere
[17:55] <wm4> (lol 512 channels)
[17:55] <durandal_1707> this is synthetic one
[17:55] <saste> it would be useful to support that
[17:57] <wm4> useful?
[17:57] <saste> yes in the italian parliament for example
[17:57] <saste> everyone speaks and no one listen the others
[17:58] <wm4> for that'd you'd use different audio streams
[17:58] <wm4> there is no speaker setup called "italian parliament"
[17:59] <wm4> anyway, enjoy your API that usually breaks with >8 channels ;D
[17:59] <saste> wm4: the <= 8 limitation is supposed to be overcome
[17:59] <wm4> by adding a new special case
[18:04] <durandal_1707> the only limitation is for planar sample formats
[18:04] <durandal_1707> i see no reason why interleaved could not be supported
[18:08] <saste> durandal_1707, why is planar limited?
[18:08] <saste> you have no limitation on the number of planes you can alloc
[18:08] <saste> of course code may be bugged/rely on the old assumption
[18:09] <saste> but no design limitation in libavcodec/libavfilter
[18:10] <durandal_1707> for >8 one need to use extended_data
[18:10] <JEEB> I thought the assumption was that everyone would use extended_data
[18:10] <JEEB> for audio
[18:10] <wm4> and if it doesn't, it just blows up randomly?
[18:10] <durandal_1707> wm4: nope, because nothing supports >8
[18:10] <wm4> or is there something that makes sure it doesn't
[18:11] <wm4> ffun
[18:11] <durandal_1707> by nothing i mean ffmpeg/lavfi
[18:12] <wm4> you could just always force code to use extended_data by not setting data
[18:12] <durandal_1707> looks like extended_data was added for fun 
[18:13] <durandal_1707> l releasing 96
[18:13] <JEEB> more like it was added because data had a limit in how many things could be put there :P Not that I fully agree with how it was handled, but this way things basing upon data wouldn't break until they tried using >8 channels
[18:14] <durandal_1707> michaelni: fine to push l patches that are stuck in limbo for eternity?
[18:25] <saste> durandal_1707, alsdec: fix typo <- push it directly
[18:28] <durandal_1707> saste: no I wait Thilo explicit approval he is als maintainer and prefer to have full control, i cant say him f* off
[18:28] <saste> durandal_1707, ok
[18:29] <durandal_1707> otherwise i get complaints in cvs log ml that i'm not subscribed and people get angry when i ignore them
[18:34] <michaelni> durandal11707, which l patches ?
[18:44] Action: Compn wonders what wiki changes
[18:53] <cone-513> ffmpeg.git 03Maximilian Seesslen 07master:467c033858a8: fixed granularity of video quality when encoding with theora codec
[20:09] <durandal_1707> ubitux: unkown is typo in patcheck typos?
[20:29] <cone-513> ffmpeg.git 03Paul B Mahol 07master:d885cc41e526: Fix "knwon" typo and add a check in tools/patcheck
[20:56] <cone-513> ffmpeg.git 03Justin Ruggles 07master:f2214c622458: au: use ff_raw_write_packet()
[21:04] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:84aba8eed97d: mpegpsenc: restructure SCR handling
[21:04] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:2a23f6035ec4: mpegpsenc: Fix SCR handling for DVD
[21:04] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:9fd0cf8a3b9e: mpegpsenc: move preload recalculation to where its needed
[21:04] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:cf369d444985: mpegpsenc: show first SCR/DTS at debug level
[21:04] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:fa11f368764f: mpegpsenc: avoid shifting dts/pts
[21:04] <durandal11707> michaelni: if lavf/mxfenc use tables from lavc they should be renamed from ff_ to av_
[21:06] <michaelni> yes or avpriv
[21:06] <iive> are these tables to be used by applications?
[21:08] <michaelni> durandal11707, which table is it that has a wrong prefix ?
[21:08] <durandal11707> ff_dnxd
[21:08] <durandal11707> ff_dnxhd
[21:09] <durandal11707> 2 tables, mentioned in .v file
[21:15] <cone-513> ffmpeg.git 03Paul B Mahol 07master:ddeb299234cc: lavc: remove img_get_alpha_info as it not available any more
[21:20] <michaelni> durandal11707, Tjoppen patch to fix ff_dnxhd in mxfenc posted
[21:25] <durandal11707> add commit that removes those from .v on top of that set
[21:33] <michaelni> removing them from v is a ABI break
[21:34] <durandal11707> was img_get_alpha_info removed with ABI break?
[21:37] <michaelni> that symbol seems not there anymore so nothing should break
[21:37] <michaelni> that wasnt already broken
[21:38] <durandal11707> yes, i ask did it got broken ....
[21:38] <nevcairiel> if such a function is not part of the public ABI, is it really a break?
[21:39] <nevcairiel> i mean, noone should be accessing ff_* symbols
[21:39] <durandal11707> it is named img_
[21:39] <nevcairiel> even worse :p
[22:13] <durandal11707> anyone run ffmpeg git tree under gource ?
[22:58] <cone-513> ffmpeg.git 03Michael Niedermayer 07master:498e1c6bb963: lavu: check av_clip*() limits
[00:00] --- Sat Jan  5 2013