August 2008 - ffmpeg-devel - lists.ffmpeg.org

[PATCH] Make ffplay define in the encoder the number of threads *before* to open it
by stefano.sabatini-lala＠poste.it 28 Dec '09

28 Dec '09

Hi, as in $subject. If threads support is not enabled and threads count is set to a value greater than MAX_THREADS (currently is 8), then encoder is initialized with a value of thread_count equal to 1, then enc->threads_count is set to the value set by the user, finally libavcodec crashes when it tryies to free the first thread beyond MAX_THREADS (this happens when quitting ffplay). Check it with: ffplay -threads 1000 FILE.flv (crashes in libavcodec/mpegvideo.c:MPV_common_end) With the patch we get: stefano at geppetto ~> ~/src/ffmpeg/ffplay -threads 1000 FILE.flv Warning: not compiled with thread support, using thread emulation [flv @ 0x83fba40]too many threads then ffplay reproduces the file with no video. Best regards. -- Stefano Sabatini Linux user number 337176 (see http://counter.li.org)

3 18

[PATCH] estimate stream durations using read_timestamp
by elupus＠ecce.se 27 Dec '09

27 Dec '09

Hi, Here is a patch for libavformat to estimate stream durations using the read_timestamp interface. This could most likely replace the special casing for mpeg using read_packet. Thou i've not yet checked that. Joakim Ps. Patch probably applies at an offset, but it's not against latest svn. Will resend with that after inital comments.

3 7

[PATCH] 'vorbis_residue_decode' optimizations
by siarhei.siamashka＠gmail.com 20 Dec '09

20 Dec '09

Hi, This trivial patch improves overall vorbis decoding performance by ~3% on Pentium-M with gcc 4.2.3 Maybe some variations of it can provide even more improvement (more separate implementations for the typical values of 'ch' and 'vlen'). Respecting CONFIG_SMALL would be also a good idea. Anyway, 'vorbis_residue_decode' is currently one of the parts of ffvorbis decoder that takes quite a lot of time, adding some optimizations to it (including those that are already mentioned as FIXME in the sources) should help quite a lot. -- Best regards, Siarhei Siamashka

4 18

compressed v4l2 images
by ramiro＠lisha.ufsc.br 10 Dec '09

10 Dec '09

Hello, I have a webcam running the zc0301 driver. On the VIDIOC_S_FMT ioctl call, it always sets the pixel format to V4L2_PIX_FMT_JPEG. The current code doesn't take into account when the pixel format is changed on that call. Also, it doesn't support the compressed JPEG stream even if the pixel format is changed according to the result of the ioctl. What's the best way to make it support compressed JPEG? Just check for compressed and set appropriate codec_id? Ramiro Polla

6 16

[PATCH] libavdevice/x11grab.c XFixesGetCursorImage support
by roxis＠list.ru 27 Nov '09

27 Nov '09

I made a patch to add real cursor support in x11grab. But i'm not a c programmer, patch is far from ideal but works for me. I would like, if someone made it proper, add alpha blending and made command line options for no cursor / dummy cursor / real cursor. Thanks.

2 3

[PATCH] another AC3 descriptor for MPEG-TS
by Nicola.Sabbi＠poste.it 20 Oct '09

20 Oct '09

Somewhere in incoming there's a sample (whose name I forgot, uploaded by a user < 2 months ago) that has a stream_type == 0x8N and a registration descriptor==AC-3, that is a valid AC3 identifier. Attached patch supports it

4 3

[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

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