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

[burek]

[03:36] <CIA-47> ffmpeg: 03Michael Niedermayer 07master * r7b1ff5e2f3 10ffmpeg/libavcodec/h263dec.c: 
[03:36] <CIA-47> ffmpeg: h263dec: fix xvid IDCT switching
[03:36] <CIA-47> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:42] Action: ubitux just realized that... ffmpeg -codecs | grep jpeg2000...
[03:42] <ubitux>  DEVILS jpeg2000             JPEG 2000 (decoders: j2k libopenjpeg ) (encoders: j2k libopenjpeg )
[03:42] <ubitux> DEVILS @_@
[04:18] <ubitux> would it make sense to transmit the qscale video parameter to the crf libx264 param?
[04:42] <pengvado> if you want two different ways of setting the same option, measured in different units, then sure.
[04:42] <ubitux> isn't qscale an encoder-specific metric option?
[04:44] <ubitux> (and looks ignored by our libx264 wrapper encoder)
[04:44] <ubitux> that's what we use in the libmp3lame encoder for example
[04:44] <ubitux> ’ lame_set_VBR_quality(s->gfp, avctx->global_quality / (float)FF_QP2LAMBDA);
[04:45] <pengvado> documentation in avcodec.h says "This should be proportional to MPEG-1/2/4 qscale."
[04:47] <pengvado> and this equality is assumed by -same_quant
[04:47] <ubitux> "qscale" "use fixed quality scale (VBR)"
[04:49] <ubitux> but well, just a suggestion
[04:49] <ubitux> no idea how it should be done
[04:49] <michaelni> if its ignored maybe a warning should be printed when its non default
[04:49] <ubitux> but imo not honoring the qscale parameter with the libx264 codec looks wrong
[04:51] <pengvado> but yes, -qscale should be meaningful to x264, the only question is what units.
[04:53] <ubitux> there is a "qscale_type" that might help
[04:54] <ubitux> looks mostly unused
[04:55] <pengvado> it's also a member of AVFrame, not AVCodecContext, and thus unavailable at setup time.
[04:55] <pengvado> I think it's intended for postprocessors
[06:16] <CIA-47> ffmpeg: 03Peter Ross 07master * rbf959ac2c6 10ffmpeg/libavformat/tty.c: 
[06:16] <CIA-47> ffmpeg: tty: return EOF when the 'effective' end of file is reached. ('effective' because ansi/tty files may be concatenated with SAUCE/EFI metadata)
[06:16] <CIA-47> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[06:16] <CIA-47> ffmpeg: 03Peter Ross 07master * r299489714a 10ffmpeg/libavformat/tty.c: 
[06:16] <CIA-47> ffmpeg: tty: return av_get_packet() error codes instead of converting them to EIO
[06:16] <CIA-47> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[06:16] <CIA-47> ffmpeg: 03Michael Niedermayer 07master * r688cb71252 10ffmpeg/libavcodec/aaccoder.c: 
[06:16] <CIA-47> ffmpeg: aaccoder: switch to av_assert
[06:16] <CIA-47> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[11:42] <CIA-47> ffmpeg: 03Stefano Sabatini 07master * rd815763548 10ffmpeg/ (doc/muxers.texi libavformat/segment.c): 
[11:42] <CIA-47> ffmpeg: lavf/segment: add escaping for filename field of the CSV list file
[11:42] <CIA-47> ffmpeg: CSV escaping code is borrowed from ffprobe.c.
[11:42] <CIA-47> ffmpeg: 03Stefano Sabatini 07master * r838b1d60a1 10ffmpeg/libavformat/segment.c: lavf/segment: add EXT-X-MEDIA-SEQUENCE tag in M3U8 header
[11:42] <CIA-47> ffmpeg: 03Stefano Sabatini 07master * r3b34cbce19 10ffmpeg/doc/examples/ (Makefile scaling_video.c): 
[11:42] <CIA-47> ffmpeg: examples/scaling_video: write to rawvideo file
[11:42] <CIA-47> ffmpeg: This is more useful for testing purposes. Also allow to specify the name
[11:42] <CIA-47> ffmpeg: of the output file.
[11:42] <CIA-47> ffmpeg: 03Stefano Sabatini 07master * r9de7622927 10ffmpeg/ (3 files in 2 dirs): 
[11:42] <CIA-47> ffmpeg: lavfi/transpose: implement landscape passthrough mode
[11:42] <CIA-47> ffmpeg: Emulate the mp=rotate passthrough mode.
[11:42] <CIA-47> ffmpeg: 03Stefano Sabatini 07master * rebd703f0a0 10ffmpeg/ (doc/muxers.texi libavformat/segment.c): 
[11:42] <CIA-47> ffmpeg: lavf/segment: deprecate "ext" format in favor of "csv"
[11:42] <CIA-47> ffmpeg: The new option name is more descriptive.
[13:26] <shroomM> umm... i know the bug report isn't helpful, but maybe any idea how to provide you guys more information ...
[13:26] <shroomM> https://ffmpeg.org/trac/ffmpeg/ticket/1574
[13:27] <shroomM> wrong chan before :)
[13:27] <shroomM> i'll try the head git in a couple of minutes, but i'm pretty sure that it'll be the same
[13:28] <Daemon404> oh boy... mxf
[13:28] <shroomM> yeah
[13:28] <Daemon404> everybody's favorite monstrosity
[13:28] <shroomM> I know .. :(
[13:28] <shroomM> lol
[13:28] <shroomM> ok, obviously, ffmpeg won't build for me under mingw
[13:28] <Daemon404> TimNich 
[13:28] <Daemon404> would be the man
[13:28] <Daemon404> [07:28] < shroomM> ok, obviously, ffmpeg won't build for me under mingw <-- why not?
[13:28] <shroomM> bah, don't know, lemme see
[13:29] <shroomM> I haven't really changed anything since the last build
[13:29] <TimNich> what, sorry,  what have I missed..
[13:29] <Daemon404> TimNich, mxf fun
[13:29] <Daemon404> apparently.
[13:30] <TimNich> mxf and fun should not appear in the same paragraph...
[13:30] <shroomM> tell me about it ... 
[13:31] <shroomM> then you put avid into the equation .. 
[13:31] <shroomM> and you've got a winning combo :)
[13:31] <Daemon404> shroomM, is not not possible to cut a small portion of said file ?
[13:31] <Daemon404> e.g. dd
[13:31] <shroomM> that's the thing
[13:31] <shroomM> if I cut it
[13:31] <shroomM> it works
[13:31] <shroomM> i tried when I was reporting the bug
[13:32] <shroomM> 100mb, 1gb, whatever
[13:32] <shroomM> it didn't give me an error
[13:32] <shroomM> if I recall correctly
[13:32] <shroomM> I'll have to try again
[13:32] <Daemon404> "found essence prior to first PartitionPack"
[13:32] <Daemon404> eh... sure is cryptic
[13:32] <Daemon404> sounds liek mxf-specific jargon
[13:32] <TimNich> some of the mxf metadata can be at the end of the file, and you crawl backwards from the end to look for what you want, (unlike mov where you just jump over the data atom)
[13:33] <Daemon404> .. crawl back?
[13:33] <shroomM> first, I have to check what's the problem with ffmpeg not building on my mingw
[13:33] <Daemon404> really?
[13:33] <Tjoppen> it's exactly what it sounds like. the spec requires the file to start with some kind of partition
[13:33] <Tjoppen> unless the demuxer is misinterpreting something
[13:33] <Daemon404> then why does cutting it work?
[13:33] <Tjoppen> cutting off the start or the end?
[13:34] <Daemon404> i assume hes taking the first N mb
[13:34] <shroomM> yeah
[13:34] <Tjoppen> of course question #1 is: what encoded the file?
[13:34] <Tjoppen> second: what does mxfdump say?
[13:35] <TimNich> Telestream?;P
[13:35] <shroomM> i'll have to check
[13:35] <shroomM> here's my error while compiling ..
[13:35] <shroomM> https://gist.github.com/3620456
[13:36] <Tjoppen> mxf can be had via http://freemxf.org/ - it's be nice if its output were attached to the ticket
[13:36] <Tjoppen> *mxfdump
[13:36] <shroomM> allright, sec
[13:38] <shroomM> Daemon404 any ideas on the compile error?
[13:38] <Tjoppen> mxf is bad enough as it is without having to deal with broken encoders. I'd prefer if they were patched first
[13:38] <shroomM> Tjoppen not under my control, which encoder it was
[13:39] <Daemon404> shroomM, someone may have atually broken mingw :o
[13:39] <Daemon404> let me check
[13:39] <shroomM> but I believe it's safe to say there were multiple files from the same encoder
[13:39] <shroomM> I received a batch of files
[13:39] <shroomM> and all but two work ok
[13:39] <TimNich> You might find the bmxlib stuff more up to date and more useful http://sourceforge.net/bmxlib
[13:40] <shroomM> yeah, I saw that today
[13:40] <TimNich> oops http://sourceforge.net/bmxlib
[13:41] <shroomM> hm, funny thing - mediainfo shows no info on the file
[13:41] <TimNich> bother http://sourceforge.net/p/bmxlib/ paste isn't
[13:41] <ubitux> shroomM: you could check if it's a regression, and if so use git bisect
[13:41] <shroomM> I'm not the best at git :-/
[13:42] <shroomM> sec, lemme check this mxf 
[13:47] <shroomM> I believe it was MXF4mac
[13:47] <shroomM> that generated the file
[13:47] <shroomM> but that's a wild guess really
[13:47] <Daemon404> ffmpeg version N-44141-g9de7622 Copyright (c) 2000-2012 the FFmpeg developers built on Sep  4 2012 07:46:50 with gcc 4.7.1 (GCC)
[13:47] <Daemon404> builds fine on mingw for me
[13:47] <shroomM> blegh
[13:47] <shroomM> :S
[13:47] <Daemon404> where did you get your toolchain
[13:48] <shroomM> can't recall, I think it was something from the CCCP guys
[13:48] <Daemon404> gcc -v
[13:49] <shroomM> https://gist.github.com/3620537
[13:49] <Daemon404> old Komisar... bleh\
[13:50] <Tjoppen> one of the reasons for using mxfdump is because the Identification pack informs you what software wrote the file
[13:50] <Daemon404> ^
[13:50] <shroomM> Daemon404 any suggestions for building an updated toolchain ?
[13:50] <shroomM> where to start, what to use
[13:51] <Daemon404> sec
[13:51] <Daemon404> http://files.1f0.de/mingw/mingw-w64-gcc-4.7.1-stable-r3.7z
[13:52] <Tjoppen> anyway, I gotta go deal with jpeg2000-in-mxf
[13:52] <Tjoppen> let me know when you have a greenlighted sample and mxfdump output
[13:53] <Daemon404> [07:52] < Tjoppen> anyway, I gotta go deal with jpeg2000-in-mxf <-- sounds like .dcp
[13:53] <JEEB> I think after I get my next machine done I'll just update the whole msys/mingw page on CCCP's wiki to use mingw-get and I guess' nev's toolchain
[13:53] <JEEB> need a vm to see what exactly mingw-get does
[13:53] <Tjoppen> Daemon404: quoth the client: "The broadcast people see JPEG2000 as the next big codec. A lot of new standards includes J2K in MXF."
[13:53] <Tjoppen> facepalms were had
[13:53] <Daemon404> lol
[13:53] <shroomM> Tjoppen this is the mxfdump
[13:53] <Tjoppen> Y U NO AVC-INTRA!?
[13:53] <shroomM> https://gist.github.com/3620563
[13:54] <Daemon404> Tjoppen, wavelets!!!!11one
[13:54] <Tjoppen> *looks*
[13:54] <kierank> Tjoppen: well there is no serious competition to j2k
[13:54] <shroomM> you need any of the options specified ?
[13:54] <kierank> no decent avc-intra encoders
[13:54] <kierank> apart from ateme and that costs $$$$$$$$$$
[13:54] <JEEB> Tjoppen, I remember one of the  wavelet people on #ffmpeg once starting a lecture on why you might want a format that is optimized for PSNR
[13:54] <shroomM> kierank make x264 encode avcintra :P
[13:55] <JEEB> and why x264 sucks at things that jp2k is used for
[13:55] <kierank> interoperability is hard shroomM 
[13:55] <kierank> we treid
[13:55] <JEEB> yeah
[13:55] <JEEB> it seems like a hacks-on-hacks sandwich
[13:55] <TimNich> Cinegy  and Epsiode both do AVCI now....
[13:55] <Daemon404> kierank, jpeg might be better than j2k
[13:55] <Daemon404> from a visual perspective
[13:55] <Daemon404> <_<
[13:55] <JEEB> the spec not really being what was needed etc.
[13:55] <shroomM> JEEB as is everything in broadcast
[13:55] <Tjoppen> I suspect it may be a generations loss thing
[13:55] <kierank> TimNich: for realtime
[13:55] <Daemon404> Tjoppen, does j2k not suffer from generational loss?
[13:55] <shroomM> re hack on hack :)
[13:55] <TimNich> Cinegy does realtime
[13:56] <JEEB> shroomM, it'd be surprising if it wasn't to be honest
[13:56] <kierank> TimNich: i doubt their stuff is interoperable
[13:56] <Tjoppen> Daemon404: depends on how you use it I suspect
[13:56] <Daemon404> technically jpeg can be made to not suffer from it either
[13:56] <JEEB> but to get into those "specifications" at the moment is... very much unknown
[13:56] <Daemon404> if done correctly (nobody does)
[13:56] <JEEB> also not sure if all the decoders are even similar
[13:56] <shroomM> lol, nice
[13:57] <TimNich> kierank: Well after some initial issues it passed muster
[13:57] <shroomM> Tjoppen, huh, obviously mxfdump errors out too
[13:57] <shroomM> ERROR: ReadPartition() found Unknown [00000000.0000.0000.00000000.00000000] at 0x00000000 where a Partition Pack was expected
[13:57] <shroomM> so prolly a corrupted file
[13:57] <kierank> TimNich: does it follow the RP entirely?
[13:57] <kierank> or have its own bastardisation
[13:57] <shroomM> I'll get them to resend and see then
[13:57] <kierank> that probably breaks with avid
[13:57] <kierank> and other sw decoders
[13:57] <Tjoppen> shroomM: that could be run-in
[13:57] <Tjoppen> MXF allowsup to 64k of garbage before the actual header
[13:58] <TimNich> Well ffmpeg will eat it
[13:58] <shroomM> where can I find the latest windows build of the ffmpeg
[13:58] <shroomM> since my mingw is fubar and don't have the patience to start building a new one right now
[13:58] <kierank> TimNich: ah well that's wholly different to interoperability
[13:58] <TimNich> or maybe it was ffmbc ;P
[13:59] <TimNich> Well DMI were happy with it
[13:59] <JEEB> shroomM, zeronoe's building windows builds afaik
[13:59] <Tjoppen> TimNich: not likely, or I'd have heard of it
[13:59] <JEEB> *zeranoe
[14:00] <shroomM> huh, funny thing, an old mediainfo displays no info on the mxf
[14:00] <shroomM> but a new one does
[14:00] <kierank> TimNich: well the thing is if it doesn't work in avid people blame the free encoder not the fancy expensive editor
[14:00] <TimNich> Tjoppen:  whats not likely?
[14:00] <Tjoppen> wait, I forgot they tend to use ffmbc to remux every now and then
[14:00] <shroomM> Writing application                      : Hamburg Pro Audio GmbH MXF4mac D10 Export QT 1.4.2
[14:01] <Tjoppen> kierank: oh god, avid
[14:02] <Tjoppen> do something like use a track name > 32 chars -> crash
[14:04] <Tjoppen> shroomM: try looking at the file with a hex editor for the first occurance of non-zero bytes and what and where they are
[14:04] <TimNich> kierank:  First thing I used to check on a new version of Avid was import export, there was always something broken, but usually only in non US frame standards...
[14:05] <Tjoppen> avid can't import their own internal format
[14:05] <Tjoppen> which is just.. sad
[14:06] <shroomM> Tjoppen what do you mean non-zero bytes
[14:06] <shroomM> the very first one is non zero :)
[14:06] <shroomM> 06 0E 2B 34 02 05 01 01 0D 01 02 01 01 02 04 00
[14:06] <Tjoppen> but.. why does mxfdump say it found the key 00000000.0000.0000.00000000.00000000 at 0x00000000? grr
[14:07] <TimNich> well you don't need to import it as its already native.......
[14:07] <shroomM> lemme try with the bmx one
[14:07] <Tjoppen> TimNich: that depends. it's still extremely shitty
[14:07] <shroomM> huh, it's giving me a shitload of output
[14:07] <TimNich> I have a static 64 bit linux build if its anyuse....
[14:09] <shroomM> Tjoppen https://dl.dropbox.com/u/132558/mxfdump/dump.txt and https://dl.dropbox.com/u/132558/mxfdump/dump2.txt
[14:10] <shroomM> the dump.txt is the stderr, dump2.txt is the stdout
[14:10] <shroomM> or vice versa
[14:10] <Tjoppen> try tossing it at mxfsplit
[14:10] <Tjoppen> and ffplay the largest file (should be the video stream)
[14:11] <shroomM> huh, OK, the bmx's mxf2raw does not work
[14:11] <Tjoppen> looks like the file starts with a partitionpack, so.. something may be confusing the demuxe
[14:11] <shroomM> ERROR: 'essence_chunk.size >= 0' check failed
[14:11] <shroomM> ERROR:     near ..\..\..\src\mxf_reader\EssenceChunkHelper.cpp:142
[14:11] <shroomM> ERROR: BMX exception: 'essence_chunk.size >= 0' check failed
[14:11] <shroomM> ERROR: Failed to open MXF file 'SER-NO_ORDINARY_FAMILY-YR01-EP003.mxf': general error
[14:11] <Tjoppen> r
[14:12] <shroomM> lemme see the mxfsplit
[14:13] <shroomM> Tjoppen nah, doesn't work either
[14:13] <shroomM> https://dl.dropbox.com/u/132558/mxfsplit.txt
[14:14] <Tjoppen> no _0001* files written?
[14:14] <shroomM> well, they are written
[14:14] <shroomM> but only like 300mb
[14:14] <shroomM> of which I assume is video
[14:14] <Tjoppen> .. do any of them ffplay?
[14:15] <Tjoppen> I'd expect one of them to contain mpeg-2 essence
[14:15] <shroomM> sorry, let me find ffplay
[14:16] <Tjoppen> but yeah, judging from the mxfsplit output I'd say the file is corrupt somewhere in the middle
[14:16] <shroomM> works so far
[14:16] <shroomM> it does, however play the mpeg2 essence, yeah
[14:17] <shroomM> ok, thanks for all the help
[14:17] <shroomM> at least I know it's not the ffmpeg's problem
[14:18] <Tjoppen> the demuxer could possibly handle the file a little better, but it's fairly broken anyway.. try getting a new one :)
[14:19] <shroomM> yeah, probably a transfer error
[14:21] <Tjoppen> you didn't check sha1sums first of all?
[14:22] <shroomM> got it through aspera, I assumed it does some checks
[14:22] <shroomM> obviously it failed
[15:08] <Tjoppen> lol - libopenjpeg craps out if packets are padded with zeroes
[15:10] Action: Daemon404 isnt sure how one manages such a failure
[15:11] <TimNich> I don't think aspera does overall checksumming. I've seen a lot of stuff come in with separately generated md5. (I have pointed out that md5 isn't great for large files....)
[17:15] <CIA-56> ffmpeg: 03Alberto Delmás 07master * ra97ee41bee 10ffmpeg/libavcodec/ (mss1.c mss12.c mss12.h mss2.c): 
[17:15] <CIA-56> ffmpeg: mss12: move SliceContexts out of the common context into the codec contexts
[17:15] <CIA-56> ffmpeg: Signed-off-by: Kostya Shishkov <kostya.shishkov at gmail.com>
[17:15] <CIA-56> ffmpeg: 03Diego Biurrun 07master * ra84ac7a860 10ffmpeg/libavcodec/x86/h264dsp_init.c: x86: h264dsp: drop some unnecessary ifdefs around prototype declarations
[17:15] <CIA-56> ffmpeg: 03Alberto Delmás 07master * r626c1a33ed 10ffmpeg/libavcodec/ (mss1.c mss12.c mss12.h mss2.c): 
[17:15] <CIA-56> ffmpeg: mss12: reduce SliceContext size from 1067 to 164 KB
[17:15] <CIA-56> ffmpeg: Signed-off-by: Kostya Shishkov <kostya.shishkov at gmail.com>
[17:15] <CIA-56> ffmpeg: 03Martin Storsjö 07master * r6d9e74cd41 10ffmpeg/libavcodec/proresenc.c: 
[17:15] <CIA-56> ffmpeg: proresenc: Write the full value in one put_bits call
[17:15] <CIA-56> ffmpeg: Previously, the put_bits call writing the value wrote a value
[17:15] <CIA-56> ffmpeg: larger than the number of bits specified, failing asserts
[17:15] <CIA-56> ffmpeg: in debug mode. There was no actual bitstream writer corruption,
[17:15] <CIA-56> ffmpeg: since the overwritten bit already always was set to 1.
[17:15] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[17:15] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * raa264da5bf 10ffmpeg/ (libavcodec/adpcmenc.c tests/ref/fate/acodec-adpcm-ima_qt): (log message trimmed)
[17:15] <CIA-56> ffmpeg: adpcmenc: Calculate the IMA_QT predictor without overflow
[17:15] <CIA-56> ffmpeg: Previously, the value given to put_bits was 10 bits long for positive
[17:15] <CIA-56> ffmpeg: predictors, even though 9 bits were to be written. The extra bit could
[17:15] <CIA-56> ffmpeg: in some cases overwrite existing bits in the bitstream writer cache.
[17:15] <CIA-56> ffmpeg: This fixes a failed assert in put_bits.h, when running a version
[17:15] <CIA-56> ffmpeg: built with -DDEBUG.
[17:15] <CIA-56> ffmpeg: 03Martin Storsjö 07master * rcc86bd4ccc 10ffmpeg/libavcodec/proresenc.c: 
[17:15] <CIA-56> ffmpeg: proresenc: Don't free a buffer not owned by the codec
[17:15] <CIA-56> ffmpeg: The data in coded_frame isn't allocated using get_buffer, but
[17:15] <CIA-56> ffmpeg: is copied from the input frame to the encoder, so we should
[17:15] <CIA-56> ffmpeg: not try to free it ourselves.
[17:15] <CIA-56> ffmpeg: This fixes an assert failure when running in debug mode.
[17:15] <CIA-56> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[17:15] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r9dcc4c30f9 10ffmpeg/: (log message trimmed)
[17:16] <CIA-56> (17 lines omitted)
[19:02] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r172161c8db 10ffmpeg/libavfilter/sink_buffer.c: 
[19:02] <CIA-56> ffmpeg: sink_buffer: fix #ifs for FF-sinks
[19:02] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:02] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r49c230fb56 10ffmpeg/libavfilter/Makefile: 
[19:02] <CIA-56> ffmpeg: libavfilter/Makefile: add forgotten entries for the ff-sinks
[19:02] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:02] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rdaa3c28895 10ffmpeg/configure: 
[19:02] <CIA-56> ffmpeg: configure: update sinks used by ffplay/ffmpeg
[19:02] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:08] <Compn> ehe
[19:08] <Compn> rename qatar to 'ffmpeg2' 
[19:08] Action: Compn amuses himself
[20:00] <saste> ubitux: do you want to do more comments on *sendcmd?
[20:01] <saste> otherwise I'll wait a few days, will do more tests and commit
[21:46] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r8c6d651fc3 10ffmpeg/libavcodec/paf.c: 
[21:46] <CIA-56> ffmpeg: paf: avoid using expressions with sideeffects in AV_R*
[21:46] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:46] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rd83ff76ca0 10ffmpeg/libavutil/intreadwrite.h: 
[21:46] <CIA-56> ffmpeg: intreadwrite: Dont evaluate value for AV_W* multiple times.
[21:46] <CIA-56> ffmpeg: Evaluating it multiple times, can have side effects and is possibly slow.
[21:46] <CIA-56> ffmpeg: So its definitly a bad idea.
[21:46] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:07] <ubitux> saste: no I don't have any more comments in mind
[23:36] <CIA-56> ffmpeg: 03Clément BSsch 07master * r3b6e9cd7ec 10ffmpeg/libavcodec/dvdsubdec.c: lavc/dvdsubdec: parse the size from the extradata.
[23:58] <ubitux> saste: shouldn't we add a tinterlace reg test btw?
[23:59] <saste> ubitux: yes
[23:59] <saste> i'm only confused about the new "testing" framework
[23:59] <saste> i tackled a couple of times and gave up
[00:00] --- Wed Sep  5 2012