February 2010 - ffmpeg-devel - lists.ffmpeg.org

[PATCH] FLIC demuxer fix for the first two X-COM games (also adds audio)
by tomas.hardin＠codemill.se 22 Apr '10

22 Apr '10

Good morning Last christmas I reverse-engineered the video format used in the first two X-COM games ("UFO: Enemy Unknown" and "X-COM: Terror from the Deep"). It turned out to simply be normal FLIC files with extra audio chunks. This patch detects the presence of such a chunk at the start of the file, and adds a 22050 Hz mono 8-bit audio stream in that case. It also calculates the proper framerate, since these videos appear to have been created in a two-step process (audio added later, thus altering the frame rate). In order to detect these videos I had to peek at the first preamble in the file, which means reading and rewinding six bytes. This should hopefully not be a problem since I'm fairly sure ByteIOContext has a small buffer for these sort of things. A similar trick is used in the Magic Carpet case, so I've figured it's OK anyway. Regarding audio, the code assumes all audio chunks contain the same number of samples and sets block_align accordingly. One final thing is that these audio chunks have an extra 10 B header not accounted for in the chunk header, which caused the old demuxer to "derail". I ran the regression test for good measure. They still pass. Samples uploaded to incoming/xcom/ (*.VID). Works for all five videos in the second game, but I haven't been able to test it on those in the first game. /Tomas

4 7

[PATCH] SHOUTcast HTTP Support
by micahgalizia＠gmail.com 09 Apr '10

09 Apr '10

Greetings, I've attached a patch adds support for SHOUTcast metadata. This patch attempts to connect via HTTP with icy metadata enabled. If the connection fails, connection is attempted again without icy metadata (in case the server doesn't support it). As new metadata is received, it is updated in the HTTPContext, and a flag is set to indicate that the metadata has been updated. URLProtocol has two new methods that indicate that the metadata has changed, and pass the new metadata (not a copy, but the actual pointer) back to the AVFormatContext through the ByteIOContext. Note, that the definition of AVMetadata and AVMetadataConv has been moved from avformat.h to avio.h so that they are defined before the definition of URLProtocol. ByteIOContext has been updated to wrap the new URLProtocol methods so that as packets are read the metadata can be returned. If the ByteIOContext reports new metadata, then the updated fields are added to the AVFormatContext. A new method has been added to metadata API to allow applications to monitor changes in metadata (av_metadata_updated), and ffplay has been updated to use it. One point I would like to note is that I was never able to find a server that didn't like the icy-metadata request, so I haven't really verified that reconnection without icy-metadata works. If someone knows a server that will respond with an error, I would like to know. Thanks in advance! -- Micah F. Galizia micahgalizia at gmail.com "The mark of an immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one." --W. Stekel

4 53

[PATCH] Rename ffmpeg.c:av_encode() -> av_transcode()
by stefano.sabatini-lala＠poste.it 04 Apr '10

04 Apr '10

The new name looks more adequate, also if we want to save chars a simple "transcode()" should be fine. Regards. -- FFmpeg = Frenzy Faithful Miracolous Peaceless Elastic God

1 3

Fwd: [PATCH] Psygnosis YOP demuxer
by yadudoc1729＠gmail.com 30 Mar '10

30 Mar '10

?Hi, Attached patch is a cleaned up variant of the one submitted by Thomas Higdon [1] and includes the demuxer only. The decoder patch will follow once (hopefully) this is in. Comments appreciated. [1] http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/95133/focus=95474 -- Regards, Yadu Nand B

11 83

[PATCH] Document avio.h:url_exist()
by stefano.sabatini-lala＠poste.it 30 Mar '10

30 Mar '10

Hi, as in subject. -- FFmpeg = Faithful and Freak MultiPurpose Enhanced Ghost

2 9

AC3 bitrate not set if container is Matroska / issue 807
by christian.cier＠tu-dortmund.de 26 Mar '10

26 Mar '10

Hi, I have several Matroska Test-Files where the bitrate of the AC3 streams is not getting set in ffmpeg at all. This causes problems when generating timestamps for the MPEG-TS muxer for example. The attached patch fixes this. But I am not sure if this is the right place to fix this (matroskadec.c). Another possibility would be to modify the function has_codec_parameters() in libavformat/utils.c and add a condition that tests if the bitrate is set in case of CODEC_ID_AC3. I have tried that and it would also work. This would mean a general approach and is not specific to Matroska. I presume that the bitrate should always be set in case of an AC3 stream. If the container does not deliver this information then the codec headers need to be parsed. I would appreciate some comments about this. Regards, Christian

2 1

[PATCH] Implement PAFF in H.264
by heydowns＠borg.com 26 Mar '10

26 Mar '10

Attached is a patch that implements PAFF in H.264. I don't expect this to be accepted right away, due to size and complexity, but I want to get it out there for review and for people to try out and comment on. It is working stable for me on a number of samples, including ones that mix PAFF with progressive and/or MBAFF. Basic overview of how it works: 1. Fields are decoded and deinterlaced. 2. If non-paired fields are encountered, they are not output, but are used for reference if so marked. 3. Reference lists are kept as they were before, but now may also contain unmatched field pairs. Reference list construction splits field pairs out to fields as needed. There is a major shortcoming/known issue with this patch; it disables the error concealing calls for field pictures. This is because the error concealer needs slices to be contiguous regions of the picture buffers. I'd appreciate input on how best to augment the error concealer to handle interlaced slices (or if I am just missing something....) Also interested in hearing how this should be split into smaller patches (I know that at least the addition/changes to header documentation should come out). -Jeff

15 101

[PATCH] Port VDPAU to AVHWAccel infrastructure
by gbeauchesne＠splitted-desktop.com 25 Mar '10

25 Mar '10

Hi, This patch moves VDPAU code to AVHWAccel. An older version (without MPEG-4 ASP) was already tested by NVIDIA. However, - A separate patch would remove vdpau_internal.h - I don't know what to do with older pixfmts since they are now completely obsolete and useless (the hwaccel v2 proposal nukes all pixfmts anyway) - It's a plain and straightforward port, no effort was made to fix current bugs in the VDPAU code (including the memory leaks) Regards, Gwenole.

7 11

segfaults: Internal buffer inconsistency. flushbits <> ResvSizebit reservoir error
by abodera＠gmail.com 24 Mar '10

24 Mar '10

Hi! When transcoding another MP4 I've just received: "Internal buffer inconsistency. flushbits <> ResvSizebit reservoir error:". FFmpeg is throwing french at me? :-) It happens on this particular mp4 file (encoded with handbrake, plain default settings). Any ideas what could be the cause and how to work around it? # ffmpeg -y -v 1 -i file.mp4 -b 1024k -bt 1024k -g 40 -acodec libmp3lame -ac 2 -ab 96k -ar 44100 -vfilters "movie=0:png:logo.png [wm];movie=0:png:236.png [awm];[in][wm] overlay=15:mainH-overlayH-15:1 [int];[int][awm] overlay=mainW-overlayW-15:mainH-overlayH-15:1 [out]" -f flv ./video.flv 2>&1 FFmpeg version SVN-r20880, Copyright (c) 2000-2009 Fabrice Bellard, et al. built on Dec 20 2009 13:52:13 with gcc 4.3.2 20081105 (Red Hat 4.3.2-7) configuration: --prefix=/usr --incdir=/usr/include --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --shlibdir=/usr/lib64 --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --enable-libfaac --enable-libfaad --enable-libgsm --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-postproc --enable-pthreads --enable-gpl --enable-debug --enable-avfilter --enable-avfilter-lavf --enable-nonfree libavutil 50. 7. 0 / 50. 7. 0 libavcodec 52.43. 0 / 52.43. 0 libavformat 52.43. 0 / 52.43. 0 libavdevice 52. 2. 0 / 52. 2. 0 libavfilter 1.12. 0 / 1.12. 0 libswscale 0. 7. 2 / 0. 7. 2 libpostproc 51. 2. 0 / 51. 2. 0 Seems stream 0 codec frame rate differs from container frame rate: 30.00 (30/1) -> 15.00 (15/1) Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'file.mp4': Metadata: major_brand : mp42 minor_version : 0 compatible_brands: mp42isomavc1 encoder : HandBrake 0.9.4 2009112300 Duration: 09:46:06.86, start: 0.000000, bitrate: 561 kb/s Stream #0.0(und): Video: h264, yuv420p, 964x900, 423 kb/s, 30 fps, 15 tbr, 90k tbn, 30 tbc Stream #0.1(und): Audio: aac, 48000 Hz, stereo, s16, 134 kb/s [overlay @ 0x10adc60]auto-inserting filter 'scale' [overlay @ 0x109f5e0]auto-inserting filter 'scale' [scale @ 0x10a7e90]w:135 h:35 fmt:yuva420p [scale @ 0x10a8010]w:132 h:35 fmt:yuva420p Output #0, flv, to './video.flv': Stream #0.0(und): Video: flv, yuv420p, 964x900, q=2-31, 1024 kb/s, 1k tbn, 15 tbc Stream #0.1(und): Audio: libmp3lame, 44100 Hz, stereo, s16, 96 kb/s Stream mapping: Stream #0.0 -> #0.0 Stream #0.1 -> #0.1 Press [q] to stop encoding [...] frame=213938 fps= 58 q=2.0 size= 1956798kB time=14262.86 bitrate=1123.9kbits/s dup=0 drop=1 frame=213967 fps= 58 q=2.0 size= 1956878kB time=14264.82 bitrate=1123.8kbits/s dup=0 drop=1 Internal buffer inconsistency. flushbits <> ResvSizebit reservoir error: l3_side->main_data_begin: 3096 Resvoir size: -96720 resv drain (post) -7 resv drain (pre) 0 header and sideinfo: 288 data bits: 1949 total bits: 2230 (remainder: 6) bitsperframe: 2504 This is a fatal error. It has several possible causes:90 0X0.00000000000012P-14437ME compiled with buggy version of gcc using advanced optimizations 9% Your system is overclocked 1% bug in LAME encoding libraryInternal buffer inconsistency. flushbits <> ResvSizeInternal buffer inconsistency. flushbits <> ResvSize Segmentation fault Thanks! -- __ /.)\ +48 695 600 936 \(./ abodera at gmail.com -- -- __ /.)\ +48 695 600 936 \(./ abodera at gmail.com

6 11

Awakening of FFH264
by kvide＠scilla.tv 23 Mar '10

23 Mar '10

Floks, We have been working on the native FFmpeg H.264 encoder that University of Hasselt started developing in 2007... With some updates to macroblock iterations, patches to NAL generation, addition of VUI data, better rate control etc., the codec produces ?fair" quality baseline profile video using 16x16 macroblocks and the generated streams are decodable with FFmpeg's H.264 decoder, QuickTime 7 and the reference implementation (JM 16.something). Before I submit patches (against r20511 or later) I?d just like check some minor issues: 1. From an FFmpeg point of view the codec uses identically same settings as x264. Should it still use its own codec id; CODEC_ID_FFH264 or can we use same codec id as x264; CODEC_ID_H264? The previous implies lots of these? - if (st->codec->codec_id == CODEC_ID_H264) + if ((st->codec->codec_id == CODEC_ID_H264) || (st->codec->codec_id == CODEC_ID_FFH264)) 2. I haven?t found any documentation on how to add regressions tests. Are there any summaries or docs available? 3. Main changes to current code base would be to h264dspenc.c Are there any already available options not to have to add these to h264enc.c? (or some suggestions on where they should be added) void h264_hadamard_mult_2x2 (DCTELEM Y [2] [2] ); void (*h264_idct_notranspose_add) (uint8_t *dst, DCTELEM *block, int stride); void (*h264_hadamard_mult_4x4) (DCTELEM Y [4] [4]); With or without comments I try to have the patches cleaned up and posted during the weekend. Mvh, Christian

8 19