October 2008 - ffmpeg-devel - lists.ffmpeg.org

[PATCH] fix infinite loop in mpegts_read_header() / pmt_cb()
by bjorn.axelsson＠intinor.se 12 Apr '09

12 Apr '09

(roundup errored out on me when submitting this so I'm submitting it here instead.) The sample uploaded in incoming/bjorn/hang_read_header.h264.ts causes an infinite loop when opened. To reproduce: ./ffplay hang_read_header.h264.ts FFplay version SVN-r15589, Copyright (c) 2003-2008 Fabrice Bellard, et al. configuration: libavutil 49.11. 0 / 49.11. 0 libavcodec 52. 0. 0 / 52. 0. 0 libavformat 52.22. 1 / 52.22. 1 libavdevice 52. 1. 0 / 52. 1. 0 built on Oct 9 2008 10:30:18, gcc: 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Nothing more happens, Ctrl-c doesn't work... I have several more examples encoded and muxed with Mainconcept codecs and muxer which all have the same problem. I have not looked for the root cause, but the attached path Works For Me (tm). -- Bj?rn Axelsson Phone: +46-(0)90-349 39 02 Intinor AB Fax: +46-(0)90-349 39 04 www.intinor.se Interactive Television & Digital Media Distribution

3 4

[patch] 6 channel raw audio input results in invalid PCM packet error
by philr＠modsystems.com 12 Apr '09

12 Apr '09

Raw audio input fails with SVN- r15760 when the number of channels times the number of bytes per sample isn't an integer divisor of 1024. Example: $ ffmpeg -ac 6 -ar 48000 -f s16le -i /dev/zero -t 10 silence.wav FFmpeg version SVN-r15760, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --enable-postproc --enable-libfaac --enable-libx264 --enable-pt hreads --enable-pthreads --enable-gpl --enable-libfaad --extra-libs=-L/usr/local /lib --enable-libmp3lame libavutil 49.12. 0 / 49.12. 0 libavcodec 52. 1. 0 / 52. 1. 0 libavformat 52.23. 1 / 52.23. 1 libavdevice 52. 1. 0 / 52. 1. 0 libpostproc 51. 2. 0 / 51. 2. 0 built on Oct 31 2008 11:11:46, gcc: 4.1.2 20071124 (Red Hat 4.1.2-42) Input #0, s16le, from '/dev/zero': Duration: N/A, start: 0.000000, bitrate: N/A Stream #0.0: Audio: pcm_s16le, 48000 Hz, 5:1, s16, 4608 kb/s Output #0, wav, to 'silence.wav': Stream #0.0: Audio: pcm_s16le, 48000 Hz, 5:1, s16, 4608 kb/s Stream mapping: Stream #0.0 -> #0.0 Press [q] to stop encoding [pcm_s16le @ 0xa53b410]invalid PCM packet Error while decoding stream #0.0 [pcm_s16le @ 0xa53b410]invalid PCM packet Error while decoding stream #0.0 [pcm_s16le @ 0xa53b410]invalid PCM packet Error while decoding stream #0.0 (repeats) The problem seems to be that raw_read_audio_packet in libavformat/raw.c always uses a 1024-byte packet size (RAW_PACKET_SIZE), but pcm_decode_frame in libavcodec/pcm.c expects a whole number of audio frames in the packet. With 6 input channels of 16 bit samples this is 12 bytes, which doesn't divide evenly into 1024. I took a first stab at a patch to raw_read_audio_packet which peeks inside the AVFormatContext to get the number of channels and bytes per sample from the codec structure and adjusts the packet size to be an integer multiple of bytes*channels. It fixes the problem for me, but I'm not at all familiar with the code base so I don't know if this is a legitimate operation or the best way to fix this. Feedback on a better approach would be welcome.

5 29

h264 multithreading, chapter 2
by andreas＠olebyn.nu 01 Apr '09

01 Apr '09

Hi, Even though I previously dismissed speeding up h264 decoding by splitting entropy decoding from the rest in two threads I decided to take a quick shot at it. The attach patch gives ~20-30% speedup on single sliced CABAC content. Basically, the code decodes up to 128 macroblocks in one thread while doing prediction+idct+deblock of the previously decoded 128 blocks in another thread. 20-30% is not exceptionally much, I would have expected a bit more. If you have a look in the patch you'll notice that it brutally copies the relevant fields back and forth from the H264Context. I tried embedding the H264mb into H264Context so i could reduce it into one single memcpy(), this does not make any difference (expect that it makes the patch about 3000 lines longer :-) I also tried passing an additional pointer around to all functions to entirely get rid of the memcpy()ing. This does not make any significant change either (And I know from my first attempts with slice-level multi threading that this slows down the single threaded case). All this kind of makes sense (i think) if you ponder that the data needs to be transfered from CPU1's cache to CPU2's cache (if it's even still around in CPU1's cache). Even with some type of shared cache mechanism (I'm not actually sure how core2 duo does this) the probability that the data from the previous 128 macroblocks still is in place is probably minimal. I tried lowering the number of macroblocks processed per round, but the overhead of thread synchronization quickly defeats any gain (If you only do one macroblock per round, it's about 7-8 times as slow :-) well well... It is (obviously) not intended/ready for any formal review. MBAFF support is lacking, there is some code-duplication and other ugliness. But rather before I spend any more time on it I'd like to know if people think it is worth finishing. If we in the future also add frame based parallelism we would end up with three different techniques, (== bloated == hard to maintain), then again, perhaps one of them can be removed when we've got the full picture. I dunno... Ideas, hints, test-results, flames are welcome..

5 8

[PATCH]Add RoQ regression tests - stddev improved
by cehoyos＠rainbow.studorg.tuwien.ac.at 12 Mar '09

12 Mar '09

Hi! Attached is a hopefully correct version of the RoQ regression test patch, I added -pix_fmt yuv420p -r 25, and stddev has clearly improved. Carl Eugen

5 12

Memory leak using bitstream filters with shared libs
by mans＠mansr.com 19 Feb '09

19 Feb '09

Baptiste discovered a rather nasty memory leak when using a bitstream filter with shared libraries. In ffmpeg.c:write_frame() the output of bitstream filters is stored in an AVPacket, and its destruct function is set like this (line 417): new_pkt.destruct= av_destruct_packet; Later on, in av_interleave_packet_per_dts(), AVPacket.destruct is compared against av_destruct_packet, like this (utils.c:2439): if(pkt->destruct == av_destruct_packet) The trouble here is that with shared libraries, the address of av_destruct_packet when used in the main executable or libs other than the one defining it resolves to a trampoline that calls the real function using a GOT entry. As a result, this comparison is always false when the destruct pointer was assigned outside libavformat. Does anyone have an idea for fixing this? -- M?ns Rullg?rd mans at mansr.com

7 47

[PATCH] DVB LATM parser
by paul＠kcbbs.gen.nz 16 Feb '09

16 Feb '09

Hi attached is a patch that provides a AAC LATM parser CODEC_ID_AAC_LATM I have been working on. The libfaad decoder is also patched to provide another codec the decoding for this codec id. There are minor patches to mpeg.c & mpegts.c to send stream id 0x11 to this codec id. With this patch I can get audio working perfectly for NZ DVB-T using the stock unpatched libfaad2 library. I would welcome comments and suggestions so this can be included in the ffmpeg codebase. Cheers, Paul Kendall

6 21

[PATCH] support FCP IMX/D-10 30/40/50 mov muxing
by baptiste.coudurier＠smartjog.com 12 Feb '09

12 Feb '09

Hi, This patch will correctly mux IMX/D-10 essences into a FCP compatible mov. This patch is not really meant to be included in svn (if people are against it), but since too many people are contacting me to get it, Im publishing it here. Feedback very welcome especially when muxing NTSC material. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312

4 3

[PATCH] Add versioning information to dlls
by jkolb＠wsi.com 12 Feb '09

12 Feb '09

This patch adds support for generating .rc files and then linking them with the dlls created by ffmpeg. This information can be used to identify the product version by the user and is also available to installer programs for ease of updating etc. Jeremy

10 102

[PATCH] change the order of params for av_init_random()
by justinruggles＠bellsouth.net 05 Feb '09

05 Feb '09

$subject includes lavu minor version bump. -Justin

6 26

[PATCH] DV timecode
by baptiste.coudurier＠smartjog.com 02 Feb '09

02 Feb '09

Hi 3 patches: - add timecode.h to avoid code duplication for drop frame timecode adjustment - use new lavc timecode api to set timecode in DV. Regression tests change because now default behaviour is non drop frame timecode, you can still activate it by using -flags2 +drop_frame_timecode - timecode helper function for ffmpeg to set timecode. Maybe moving brktimegm to lavu and using it is better ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312

5 14