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

Fri Apr 20 02:05:03 CEST 2012

[02:17] <CIA-17> ffmpeg: 03Mohamed Naufal 07master * r7b915a4045 10ffmpeg/ (3 files in 3 dirs): libstagefright: explicitly set positive timestamps as stagefright expects them so
[02:17] <CIA-17> ffmpeg: 03Mohamed Naufal 07master * re46b625dd0 10ffmpeg/: Merge branches 'stagefright' and 'stagefright-test' into stagefright-test
[02:17] <CIA-17> ffmpeg: 03Mohamed Naufal 07master * r1d48e88d41 10ffmpeg/libavcodec/libstagefright.cpp: 
[02:17] <CIA-17> ffmpeg: libstagefright: avoid potential deadlock on output MediaBuffer
[02:17] <CIA-17> ffmpeg: Maintain an output queue of AVFrames instead of MediaBuffers
[02:17] <CIA-17> ffmpeg: so that the latter can be released early. This avoids a potential deadlock
[02:17] <CIA-17> ffmpeg: between the stagefright decoder::read() and Stagefright_decode_frame()
[02:17] <CIA-17> ffmpeg: 03Mohamed Naufal 07master * r2343a99cf2 10ffmpeg/libavcodec/libstagefright.cpp: libstagefright: support more output pixel formats
[02:17] <CIA-17> ffmpeg: 03Mohamed Naufal 07master * rf51b7e52a6 10ffmpeg/libavcodec/libstagefright.cpp: libstagefright: avoid memory leak
[02:17] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r74e4bb6912 10ffmpeg/: (log message trimmed)
[02:17] <CIA-17> ffmpeg: Merge remote-tracking branch 'hexene/stagefright'
[02:17] <CIA-17> ffmpeg: * hexene/stagefright:
[02:17] <CIA-17> ffmpeg:  libstagefright: avoid memory leak
[02:17] <CIA-17> ffmpeg:  libstagefright: support more output pixel formats
[02:17] <CIA-17> ffmpeg:  libstagefright: avoid potential deadlock on output MediaBuffer
[10:05] <j-b> good moroning
[10:15] <michaelni> j-b, good moroning to you too
[11:21] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rdf23d64e07 10ffmpeg/libavcodec/h263dec.c: 
[11:21] <CIA-17> ffmpeg: h263dec: always enable picture dimensions reverting check.
[11:21] <CIA-17> ffmpeg: This does not need to be limited to threads and may help with error
[11:21] <CIA-17> ffmpeg: resilience on single thread
[11:21] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[11:21] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r5e59a77cec 10ffmpeg/libavcodec/vc1dec.c: 
[11:21] <CIA-17> ffmpeg: vc1dec: check that coded slice positions and interlacing match.
[11:21] <CIA-17> ffmpeg: This fixes out of array writes
[11:21] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[11:21] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[11:30] <cbsrobot> j-b: about the dcp beamers ....
[11:31] <cbsrobot> I had a freind who connected a bluray to a dcp beamer and he said the colors looked like crap
[11:31] <cbsrobot> *friend
[11:31] <cbsrobot> so I'm not sure where the xyz -> rgb converstion happens exactly
[11:42] <Digidog> Hi! I am here on the latest ffmperg from git on Windows 7 and ask if there is any chance to set the pixel aspect ratio in ffmpeg while encoding video, or is just setting -aspect allone ok enough? I just registered that some video stream show off also PAR info in ffprobe, but some which I had encoded before sadly not. But they should, since the source had PAL widescreen pixels which I wanted to keep.
[11:44] <Digidog> Maybe its imagination only, but I think I see some distortion while the player streches the 16:9 flagged videoclip wihtout the PAR info, while the one with the correct PAR info stretches teh videoclip some better. But maybe it's just in my mind ...
[11:44] <Digidog> arg ... sorry for my typo
[11:46] <Digidog> Does anyone has any idea if the PAR flag for PAL widescreen pixels ( PAR=1.42 or 64/45 ) is really needed when the -aspect flag is set already to 16:9 ?
[11:46] <Digidog> I can'T find any mentioning of setting PAR in ffmpeg docs ....
[12:27] <Digidog> hm, it seems it is a codec problem here, some other codecs show off all info correctly but ffvhuff keeps restraining infos about PAR and colorspace, even if it says yuv420p correctly. A littel bit confusing for a qualtiy control freak like me ;-)
[12:29] <Digidog> Does anyone tested UtVideo for lossless video compression in an NLE workflow ?
[12:30] <michaelni> i thought we store and read aspect for avi, so this is a bit odd
[12:30] <michaelni> its ffvhuff in avi ?
[12:30] <michaelni> or something else
[12:30] <Digidog> no, your are right, its ffvhuff in avi
[12:32] <michaelni> just tried ... -aspect 2 -vcodec ffvhuff test.avi
[12:32] <Digidog> I know that the aspect info is enough actually, since the PAR is a math myth just summarising SAR/DAR, but I wonder why ffprobe doesn'T show it off like on others. Also colorspace info is missing on both, ffprobe and media info
[12:32] <michaelni> and aspect is in there
[12:32] <michaelni> ffprobe ?
[12:33] <michaelni> ffprobe says SAR 8:5 DAR 2:1 for the example aboive
[12:33] <Digidog> I know that the aspect info is enough actually, since the PAR is a math myth just summarising SAR/DAR, but I wonder why ffprobe doesn'T show it off like on others wher it mentions PAR additionally. Also colorspace info is missing on both, ffprobe and media info
[12:34] <Digidog> not a big deal actually, I just asked myself it there is sth going on behind. (<- control freak :) )
[12:34] <Tjoppen> uhm, PAR (aka sample aspect) is usually encoded explicitly in the essence. sometimes in the container too
[12:35] <Tjoppen> some containers, like MXF, list DAR though
[12:37] <michaelni> Hi Tjoppen
[12:37] <michaelni> can you take a look at "[FFmpeg-devel] [PATCH]: mxf: Fix frame layout values" 
[12:37] <michaelni> ?
[12:37] <michaelni> it looks ok to me ...
[12:38] <michaelni> but i didnt check the spec and you know the code better and as you are already heree
[12:39] <michaelni> also theres: Reimar Döffinge (5.5K) [FFmpeg-devel] [PATCH] [HACK] mxfdec: support EIA-608 (closed caption subtitles).
[12:39] <Digidog> hm, I only know MXF from footage exchange between editing rooms. Can I encode this "shitty" (sorry) MPEG-PS footage here i help out somebody with into MXF containers to edit it in Avid? instead of into avi? But somehow this makes no sense, there will be no difference, right?
[12:39] <j-b> cbsrobot: not suprised, to be honest.
[12:41] <Compn> Digidog : mpeg video doesnt fit very well in avi container
[12:41] <Digidog> Compn: no, its encoded before (ffvhuff)
[12:42] <Compn> well then i dunno what formats avid supports that would be good for you :)
[12:43] <Digidog> Tjoppen: I would like to come back to what you sad: "PAR (aka sample aspect) is usually encoded explicitly in the essence. sometimes in the container too" ... that makes no sense to me, since this is only a flag, isn't it? a PAL widescreen frame with PAR of 1,4sth... sill onyl has the 720 color informations (called pixel) stored and stretches them on the computer screen
[12:43] <Digidog> *still only (typo)
[12:45] <Digidog> Compn: well :) thanks for helping, but I think I am a little bit to pushing here with my problem behind ;) All I wnat to make sure is, that I don't have additional conversion steps involved causing aliasing of the stored footage. I would like to have the most possible "discret" work flow for this crappy footage here :-P
[12:47] <Digidog> Another lesson I learned: "Don't say yes to people asking you to help them out with editing, before you have seen the footage" *facepalm*
[12:51] <Digidog> Hm ... no I guess I get what you mean, Tjoppen. Adobe Premiere and Avid still interpret the footage as PAR 1,09 but it should be 1,4587 instead ... damn ...
[12:52] <Digidog> I thought I could prevent another resizing step before editing, but maybe I must encode it to square pixels after deintelacing (QTGMC) thru .avs
[12:54] <av500> from random sampling all the people I know, nobody cares for aspect ratio
[12:54] <av500> they all happily watch 4:3 stretched to 16:9
[12:56] <kierank> i would have to agree there
[12:57] <Digidog> av500: the problem is, there is already a timeline where some of footage needs to get exchanged. SO it is sadly very important that the NLE interprets teh footage correctly as PAL widescreen PAR (1,4587...) The aspect ratio allone doesn't make it here. It only makes it play correctly in video players. It seems that avi or ffvhuff doesnt support additional PAR info set or maybe Tjoppen is right with what he sad.
[12:57] <kierank> people say i'm complaining unnecessarily when i fix the aspect ratio
[12:57] <av500> or the oversharping
[12:57] <av500> or the soap mode
[12:57] <Digidog> av500: kierank: ^^^
[12:57] <av500> I dont think AVI supports aspect ratio
[12:58] <av500> it assumed square pixels
[12:58] <av500> assumes
[12:59] <Digidog> av500: thats what I thought but maybe that's not correct. As I described above it already has assumed 1,09 pixels so it should have no problem to assume 1,4587 pixels. I think it 
[13:00] <Digidog> I think I already did it with another codec before so I think the problem lies here under ffvhuff
[13:00] <Digidog> Let'S make sure we talk about PAR, not DAR.
[13:01] <Digidog> the encoded material is flagged correctly DAR 16:9 and all the players behave correctly. But NLE's give priority to PAR
[13:02] <Digidog> Thats why I cant exchange the footage easely in the timeline, which is set to PAR 1,4587 (PAL widescreen)
[13:12] <Compn> your problem is avid
[13:12] <Compn> use some other software
[13:13] <Compn> so easy to edit software with open source tools
[13:13] <av500> sed and dd 
[13:34] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rb7c2358f62 10ffmpeg/libavcodec/error_resilience.c: 
[13:34] <CIA-17> ffmpeg: error_concealment: switch asserts mostly to av_asserts.
[13:34] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[13:34] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rb066046046 10ffmpeg/libavcodec/error_resilience.c: 
[13:34] <CIA-17> ffmpeg: error_concealment: make sure mbaff flags are 0 as interlaced is not supported.
[13:34] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[13:34] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r903ccf71b7 10ffmpeg/libavcodec/error_resilience.c: (log message trimmed)
[13:34] <CIA-17> ffmpeg: error_concealment: Check that the reference is not NULL
[13:34] <CIA-17> ffmpeg: In normal picture decoding this does not need to be checked but as
[13:34] <CIA-17> ffmpeg: error concealment is run in the case of errors the availability of
[13:34] <CIA-17> ffmpeg: references is less certain. This may be fixed differently at some
[13:34] <CIA-17> ffmpeg: point so that all references are always filled in before the EC
[13:34] <CIA-17> ffmpeg: code, in which case this should then be changed to an assert()
[14:24] <Digidog> the problem isnt avid because it is reproducable in premiere, fcp, kdenlive, kino, cinelerra and such
[14:25] <Digidog> A professional workflow can't change an NLE in the middle if the work, this advice makes no sense
[14:25] <Digidog> thx anyway. bye
[15:07] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rc90b8a7480 10ffmpeg/libavcodec/h263dec.c: 
[15:07] <CIA-17> ffmpeg: h263dec: Check for width/height changes on frame skips too.
[15:07] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[15:07] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:11] <mateo`> hi, is there a particular reason for using the first version of the klv fill key in mxfenc ? (maybe avid compat ?)
[15:53] <CIA-17> ffmpeg: 03Matthieu Bouron 07master * r70ca163bc5 10ffmpeg/libavformat/mxf.h: 
[15:53] <CIA-17> ffmpeg: mxf: Fix frame layout values
[15:53] <CIA-17> ffmpeg: Reviewed-by: Tomas Härdin <tomas.hardin at codemill.se>
[15:53] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:54] <CIA-17> ffmpeg: 03Matthieu Bouron 07master * rcbda76c7c6 10ffmpeg/libavformat/mxfdec.c: 
[15:54] <CIA-17> ffmpeg: mxfdec: Add missing break in frame layout parsing
[15:54] <CIA-17> ffmpeg: Reviewed-by: Tomas Härdin <tomas.hardin at codemill.se>
[15:54] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[16:08] <CIA-17> ffmpeg: 03Carl Eugen Hoyos 07master * rb4043ef504 10ffmpeg/libavcodec/flicvideo.c: Print unexpected length of flicvideo extradata.
[17:20] <CIA-17> ffmpeg: 03Nico Weber 07master * ra4a88fd42c 10ffmpeg/libavutil/x86/x86inc.asm: (log message trimmed)
[17:20] <CIA-17> ffmpeg: Remove .rodata alignment kludge for Mach-O if a recent enough yasm is used.
[17:20] <CIA-17> ffmpeg: Yasm was fixed in its r2161 and yasm 0.8.0 (Apr 2010) contained this fix.
[17:20] <CIA-17> ffmpeg: Nasm was fixed in 2.06 (Jun 2009):
[17:20] <CIA-17> ffmpeg: https://groups.google.com/group/alt.lang.asm/browse_thread/thread/fcc85bbc3745d893
[17:20] <CIA-17> ffmpeg: I tested with yasm 0.7.99 and yasm 1.2.0.7, where this works fine.
[17:20] <CIA-17> ffmpeg: I also tested with nasm. The nasm shipping with Xcode is too old to understand
[17:54] <steeve> hey guys
[17:55] <steeve> anyone familiar with dvb-t mpegts ? thanks!
[18:03] <kierank> what exactly
[18:06] <steeve> the PTS for a packet
[18:06] <steeve> i'm trying to find it's time origin
[18:10] <kierank> what time origin
[18:10] <kierank> there is no such thing
[18:11] <kierank> the pts wraps round
[18:11] <steeve> ohhhh
[18:11] <steeve> that i didn't know
[18:11] <steeve> so is I record a TS stream
[18:11] <steeve> it's not possible to know the time it was recorded
[18:12] <steeve> except if i read TDT/TOT tables
[18:12] <av500> it wraps around every 26h
[18:12] <av500> roughly
[18:12] <steeve> good to know, thanks
[18:13] <av500> but
[18:13] <steeve> is there any way i can get the time when that packet was supposed to be displayed ?
[18:13] <av500> it could wrap any time
[18:13] <steeve> maybe not with the pts, but some other information ?
[18:13] <av500> broadcasters are free to wrap the time at any time
[18:13] <steeve> i see
[18:14] <steeve> they don't talk about that in the etsi documents i've read
[18:14] <kierank> timestamps are an mpeg thing
[18:14] <kierank> etsi is more implementation/metadata
[18:14] <kierank> why do you need to know the time it was recoreded
[18:15] <steeve> i'm dumping screenshots
[18:15] <steeve> from a stream
[18:15] <av500> then note the start time
[18:15] <steeve> and I want to name with datetime information
[18:15] <kierank> if there is a teletext stream you can pull the time out of that
[18:15] <Daemon404> steeve, are you just trying to, say "seek to 1 minute in from teh start of this .ts" ?
[18:15] <av500> or keep track during recording
[18:15] <av500> or teletext
[18:15] <steeve> av500: i'm pulling it from TDT/TOT frames
[18:16] <steeve> but the pts is unique for each program it seems
[18:16] <kierank> tdt is ok a as rought measure
[18:16] <kierank> rough*
[18:16] <steeve> well, unique... i mean the increments
[18:16] <steeve> Daemon404: i'm trying to get the absolute timestamp for each decoded frame
[18:16] <steeve> from a live TS stream
[18:16] <Daemon404> relative to what
[18:17] <av500> relative to the dawn of time
[18:17] <steeve> well, not relative, absolute, as in 2012-04-19-xx-xx-xx
[18:17] <steeve> yes
[18:17] <steeve> what i'm doing atm is using the current timestamp of the machine, but obviously that is not okay
[18:18] <kierank> well if your machine is recording the stream then it;s ok
[18:18] <steeve> indeed, but i was wondering is there was a "cleaner" solution
[18:19] <steeve> but I didn't know the pts was wrapping around
[18:19] <kierank> the teletext is theoretically the cleanest
[18:19] <kierank> because there should be one teletext packet per frame
[18:19] <steeve> oh
[18:19] <kierank> though they will be offset in the ts a bit
[18:20] <steeve> now the question being
[18:20] <steeve> how can i access the teletext packet?
[18:20] <steeve> from libav ?
[18:20] <kierank> doubt it
[18:20] <steeve> crap
[18:20] <kierank> you'd need a decoder
[18:20] <kierank> libzvbi has one i think
[18:20] <steeve> i'm using libdvbpsi to dump the EPG data
[18:22] <steeve> hum
[18:22] <steeve> i'm seeing CODEC_ID_VBI_TELETEXT and CODEC_ID_VBI_DATA in libavcodec
[18:23] <kierank> yes but you can't do anything with the data afaik
[18:23] <steeve> ohhh okay
[18:23] <kierank> you need an external decoder like libzvbi
[18:23] <steeve> ok so according to you the easiest way is to use the datetime.now()
[18:24] <kierank> well as you receive the mpegts
[18:24] <steeve> yes indeed
[18:24] <av500> while you record, note the file size every minute or so
[18:24] <av500> then, from the pos and pts in lavf, you can get absolute time
[18:25] <steeve> av500: hahaha, tricky, but smart !
[18:25] <av500> that's how I am :)
[18:25] <kierank> steeve: av500 is a smart man you know
[18:25] <av500> if you only have the ~26h wrap, you need only the start time of the recording
[18:25] <kierank> padding bits are no match for av500
[18:25] <steeve> well, both of you are smart men to me
[18:26] <av500> since you can unwrap
[18:26] <steeve> av500: so that means keeping count of pts wraps
[18:26] <steeve> but doable
[18:26] <av500> well, do you record for days?
[18:26] <steeve> hum... months :)
[18:26] <av500> in one file?
[18:26] <steeve> no no
[18:27] <av500> see
[18:27] <steeve> i'm not actually dumping the .ts
[18:27] <steeve> i'm only dumping epg and screenshots
[18:27] <av500> but then you are "live"
[18:27] <steeve> well, epg tdt tot, and screenshots
[18:27] <av500> use wallclock
[18:27] <steeve> yes
[18:27] <steeve> wallclock ?
[18:27] <av500> gettimeofday()
[18:27] <steeve> yep, I think i'm gonna do just that
[18:27] <av500> solved, next!
[18:28] <steeve> is the offset between dts and pts negligeable ?
[18:28] <steeve> negligible
[18:29] <steeve> the risk of gettimeofday() being ahead of the actual display
[18:29] <steeve> if it's < 500ms it's fine
[18:30] <av500> yes
[18:30] <steeve> sweet
[18:30] <steeve> you rock guys, thanks a bunch
[18:32] <CIA-17> ffmpeg: 03Carl Eugen Hoyos 07master * rab75ad0116 10ffmpeg/libavcodec/targaenc.c: 
[18:32] <CIA-17> ffmpeg: Make targa-in-mov QuickTime-compatible for more colour-spaces.
[18:32] <CIA-17> ffmpeg: See ticket #1228.
[20:06] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * ra9cd12ee2a 10ffmpeg/libavcodec/mlpdec.c: 
[20:06] <CIA-17> ffmpeg: mlpdec: set channel variables after checking them
[20:06] <CIA-17> ffmpeg: This fixes out of array reads
[20:06] <CIA-17> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[20:06] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:06] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r2ff935f4bb 10ffmpeg/configure: (log message trimmed)
[20:06] <CIA-17> ffmpeg: build system: remove -wcast-qual
[20:06] <CIA-17> ffmpeg: Generating warnings when casting const away leads to tight constraints
[20:06] <CIA-17> ffmpeg: on the code if one wants to avoid warnings. This is especially true for
[20:06] <CIA-17> ffmpeg: generic code that is supposed to work with both const and non const.
[20:06] <CIA-17> ffmpeg: These tight constrains cause people to waste time trying to find a
[20:06] <CIA-17> ffmpeg: way to write code so it doesnt generate any warning, while people
[21:45] <CIA-17> ffmpeg: 03Justin Ruggles 07master * rc755b1fbbc 10ffmpeg/tests/fate-run.sh: 
[21:45] <CIA-17> ffmpeg: FATE: specify the input format when decoding in enc_dec_pcm()
[21:45] <CIA-17> ffmpeg: The output format is not always the same as the file extension,
[21:45] <CIA-17> ffmpeg: which is sometimes required for correct probing. We can avoid
[21:45] <CIA-17> ffmpeg: probing by specifying the format since it is already known.
[21:45] <CIA-17> ffmpeg: 03Mans Rullgard 07master * r6208313aeb 10ffmpeg/libavformat/avio.h: 
[21:45] <CIA-17> ffmpeg: avio: make AVIOContext.av_class pointer to const
[21:45] <CIA-17> ffmpeg: Fix this warning:
[21:46] <CIA-17> ffmpeg: libavformat/aviobuf.c:663:20: warning: assignment discards qualifiers from pointer target type
[21:46] <CIA-17> ffmpeg: Although this is a public header, it should remain source and
[21:46] <CIA-17> ffmpeg: binary compatible.
[21:46] <CIA-17> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:46] <CIA-17> ffmpeg: 03Mans Rullgard 07master * re73ec9216b 10ffmpeg/configure: 
[21:46] <CIA-17> ffmpeg: configure: detect PGI compiler and set suitable flags
[21:46] <CIA-17> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:46] <CIA-17> ffmpeg: 03Mans Rullgard 07master * r9d72c0527c 10ffmpeg/libavformat/nutdec.c: 
[21:46] <CIA-17> ffmpeg: nutdec: add malloc check and fix const to non-const conversion warnings
[21:46] <CIA-17> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:46] <CIA-17> ffmpeg: 03Justin Ruggles 07master * rd8b06521a9 10ffmpeg/avconv.c: 
[21:46] <CIA-17> ffmpeg: but currently we only validate that the two are compatible when opening
[21:46] <CIA-17> ffmpeg: the codec. This checks for incompatibilities after each decoded frame.
[21:46] <CIA-17> ffmpeg: 03Diego Biurrun 07master * r2b98377935 10ffmpeg/libavcodec/dv.c: dv: Initialize encoder tables during encoder init.
[21:46] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r2a976debc1 10ffmpeg/: (log message trimmed)
[21:46] <CIA-17> ffmpeg: Merge remote-tracking branch 'qatar/master'
[21:46] <CIA-17> ffmpeg: * qatar/master:
[21:46] <CIA-17> ffmpeg:  dv: Initialize encoder tables during encoder init.
[21:46] <CIA-17> ffmpeg:  dv: Replace some magic numbers by the appropriate #define.
[21:46] <CIA-17> ffmpeg:  FATE: pass the decoded output format and audio source file to enc_dec_pcm
[21:46] <CIA-17> ffmpeg:  FATE: specify the input format when decoding in enc_dec_pcm()
[21:47] <CIA-17> (10 lines omitted)
[22:26] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r2a70d8304d 10ffmpeg/libavformat/jvdec.c: 
[22:26] <CIA-17> ffmpeg: jvdec: Make sure there is enough data for the id string.
[22:26] <CIA-17> ffmpeg: Previously too little data could lead to a false detection.
[22:26] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:26] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * ree402df9a2 10ffmpeg/libavformat/mtv.c: 
[22:26] <CIA-17> ffmpeg: mtvdec: check that the buf is large enough for probing
[22:26] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:00] --- Fri Apr 20 2012