November 2008 - ffmpeg-devel - lists.ffmpeg.org

[PATCH] minor update to MPEGTS to handle yet another DCA stream type
by kirill.belokurov＠gmail.com 20 Oct '09

20 Oct '09

Hi! Recently there was a thread about the sample with the 0x82 stream_type identifying the DCA and corresponding patch to mpegts demuxer handling this: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-February/042129.html I would like to propose a minor patch to handle yet another DCA stream type, found in the wild: 0x86, which is called "DTS-HD audio stream for the primary audio" in the following document (grep for the "0x86"), related to HD movies: http://www.wipo.int/pctdb/en/wo.jsp?wo=2007058444&IA=WO2007058444&DISPLAY=D… Briefly - there are extra types mentioned there, missing in the mpegts.h : 0xEB - video "SMPTE VC-I" 0x80 - audio "HDMV LPCM" 0x83 - audio "Dolby lossless, primary audio" 0x84 - audio "Dolby Digital plus, primary audio" 0x85 - audio "DTS-HD except XXL, primary audio" 0x86 - audio "DTS-HD, primary audio" 0xA1 - audio "Dolby Digital plus, secondary audio" 0xA2 - audio "DTS-HD, secondary audio" The 0x86 will be handled by the attached patch, the name of macro STREAM_TYPE_AUDIO_HDMV_DTS_HD_PRIMARY was selected to match the list above. Does it make sense to add other types as well? There is some sample file "eragon.m2ts" in the samples incoming, that uses the 0x86 type for the DCA. Best regards, Kirill

4 7

DaVinci DSP optimizations
by ramiro＠lisha.ufsc.br 28 Sep '09

28 Sep '09

Hello, Those that can access the GSoC applications have seen that I applied one for DaVinci DSP optimizations. I wrote it quickly on Sunday: --------------- The Texas Instrument DaVinci technology combines a general purpose processor (ARM) and, depending on the model, a few DSPs aimed at complete multimedia processing on a single chip. It is currently being used by some Set-Top Boxes and Personal Video Recording devices. Most devices depend on proprietary codec packages, and there is no open-source library that can use all the power of the DaVinci chips. This project aims at writing such optimizations to FFmpeg, and for that possibly write an infrastructure that can be used by other recent heterogeneous processor architectures, such as the PS3 CELL. --------------- Neuros Technology uses DaVinci chips for their OSD2.0 devices. I'll elaborate on the idea: I don't have a PS3 nor have ever worked with one to know how it works with its DSPs, but I have worked some time with DaVinci. I have contacted the folks at Neuros Technology for more information about helping out the possible mentor of such task with hardware or more information on the chip itself. One problem that they pointed out (and I think just might be the show-stopper) is that there are yet no free compilers for the DM6446 DSP used by DaVinci. There was a port of GCC for the earlier DSPs, but I don't know how that's going with the new ones. This is part of a reply I got from Joey Born and Ugo Riboni from Neuros Technology: ---------- JB: There is no free compiler for the c64x DSP, although there are a number JB: of efforts to create one. Your best bet is to try to get a loaner copy JB: of the developer tools from TI. We have arranged some of these and can JB: probably help if you are selected. You say DSP optimizations for which JB: codec? The problem is, the optimized code Ramiro will produce will be compilable only with these loaner versions of the compiler, and "normal" people can't use these, so they can't compile it. Thus getting that code in ffmpeg source feels pretty weird to me. Or is this not a concern ? One alternative may be lobby TI to release some stripped open-source-only version of that compiler, that can be freely used by OSS projects only. Just like they did with the c54x compiler. ---------- This is a white paper about the Codec Engine interface TI supplies, and that I would use as a basis in dsputils to manage the load on different DSPs: http://focus.ti.com/lit/wp/spry091/spry091.pdf Ramiro Polla

8 13

Understanding motion vectors from ff_print_debug_info()
by pro＠cs.washington.edu 12 Aug '09

12 Aug '09

Hey All- A while back Paolo suggested that people looking to extract motion vectors in ffmpeg should look at the method ff_print_debug_info() in libavcodec/mpegvideo.c. This advice turned out to be very useful in my case. Thx Paolo. However, I have a couple of questions about the constants being used ff_print_debug_info() that would really help noobs like myself really understand what is going on. Please consider posting a reply if you are familiar with this part of ffmpeg. # It looks like you have to divide by 2 (or a higher power of 2) the values in the motion_val array to obtain the true motion vectors. Why is this so? For example ff_print_debug_info() processes the motion_val vectors in the following manner: motion_val[direction][xy][0]>>shift where shift = 1 + s->quarter_sample. The 'quarter_sample' variable makes sense. It's accounting for some sort of mode where the video is sub-sampled by 2 in the X and Y axis. But I don't understand why the '1' is added to 'shift' in effect dividing all motion vectors by 2. # For computing the 'mv_stride' variable avcodec.h suggests the following formula: mv_stride= (mb_width << mv_sample_log2) + 1 While I don't understand why that '1' is added mv_stride. What worries me is that the addition of that '1' is conditional and I don't understand when not to add that '1'. For example ff_print_debug_info() uses the following formula: (s->mb_width << mv_sample_log2) + (s->codec_id == CODEC_ID_H264 ? 0 : 1) # Finally, is there any way to populate the AVFrame.motion_val array with the motion vectors without having the motion vectors visualized on the decoded video frame? I'm setting AVCodecContext.debug_mv = 1 to obtain the motion vectors but as a side effect that flag also draws the motion vectors. It looks like ff_print_debug_info() always draws the motion vectors when the debug_mv flag is set. It seems wasteful to have to decode the video twice in order to obtain the motion vectors and the video frames without the visualization. Thank you for your time. -pro

4 5

[PATCH] recover from truncated aiff
by verem＠m1stereo.tv 19 Apr '09

19 Apr '09

Hi! During transcoding aiff files that is been truncated for 4 or 2 bytes i get a message from pcm encoder: [pcm_s24be @ 0x93b4c70]invalid PCM packet Error while decoding stream #0.0 This output happens on last audio packet because it size is not divisible by sample size. This situation could be handled by two ways: patch *aiff_handle_broken_sample.patch* fix packet size and notify about that. patch *aiff_save_broken_sample.patch* fix packet size and seek back to position where broken sample start. Any of fixes are correct? If not, how such situation should be handled? -- ________________________________________ Maksym Veremeyenko Senior System Administrator IT Department Ukrainian Music Television Channel "M1" DDI. +380 44 205-44-92 Tel. +380 44 205-44-80 Fax. +380 44 205-44-82 Cell. +380-67-447-22-43 E-mail : Maksym.Veremeyenko at m1stereo.tv Web site: www.m1stereo.tv

3 21

[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