April 2006 - ffmpeg-devel - lists.ffmpeg.org

[PATCH] Apple Video Encoder (rpza)
by ffmpeg.php＠gmail.com 24 Jan '11

24 Jan '11

Attached is a patch to add support for Apple Video encoding (rpza). The quality settings are defined at compile time right now since I wasn't really sure how to map ffmpeg's numerous video options to the capabilities of rpza. It supports all rpza encoding opcodes but the 4-color block encoding doesn't try to do multiblock runs yet. -Todd

9 20

[PATCH] Vorbis I floor type 0 support
by eclipse7＠gmx.net 16 Mar '08

16 Mar '08

Hi, i extended the ffmpeg vorbis decoder to decode vorbis floor0 files. It is my first try at this kind of stuff. I only had one sample tho testing wasn't too exhaustive. I tested the code on linux x86 and Solaris SPARC so far. As always comments and testers welcome. Have fun, Alex (beastd)

7 17

Read from a buffer instead of a file
by raphaelh＠nist.gov 08 Mar '07

08 Mar '07

Hi, is it possible to read video from a buffer instead of a file with libav(codec/format) ? I have MPEG2-TS video in a buffer, and cannot use "av_open_input_file" and the "av_read_frame" on a buffer, it only works from a file. Anyone has an idea how to do that ? Thanks in advance, --Raphael HUCK

5 10

DVR-MS bug (MP2 decoding)
by slhomme＠divxcorp.com 27 Jan '07

27 Jan '07

Hi, A user sent us a DVR-MS file (ASF with MPEG-2 and MP2) that doesn't decode correctly in FFMPEG. The issue in DrFFMPEG (with some fixes in ASF submited on this list) is that the audio is not decoded at all. The video is decoded fine. In FFMPEG the files crashes very fast but not at the same place with the following gdb log: (gdb) run -i c:\test\divx\today.dvr-ms -vn test.wav Starting program: c:\Perso\Programmes\ffmpeg.cvs/ffmpeg_g.exe -i c:\test\divx\today.dvr-ms -vn test.wav gdb: do_initial_child_stuff: process 1336 gdb: kernel event for pid=1336 tid=1300 code=CREATE_PROCESS_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=EXCEPTION_DEBUG_EVENT) gdb: Target exception EXCEPTION_BREAKPOINT at 0x7c901230 gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=UNLOAD_DLL_DEBUG_EVENT) ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=EXCEPTION_DEBUG_EVENT) gdb: Target exception EXCEPTION_ACCESS_VIOLATION at 0x00524801 Program received signal SIGSEGV, Segmentation fault. mpeg_decode_mb (s=0x3d950, block=0x2) at mpeg12.c:1894 1894 block[0] = dc << (3 - s->intra_dc_precision); (gdb) bt #0 mpeg_decode_mb (s=0x3d950, block=0x2) at mpeg12.c:1894 #1 0x00525230 in mpeg_decode_slice (s1=0x3d950, mb_y=0, buf=0x23efe4, buf_size=101196) at mpeg12.c:2567 #2 0x00527942 in mpeg_decode_frame (avctx=0x3bf90, data=0x23f4d0, data_size=0x23f47c, buf=0x1500030 "", buf_size=101380) at mpeg12.c:3157 #3 0x00458612 in avcodec_decode_video (avctx=0x3bf90, picture=0x23f4d0, got_picture_ptr=0x23f47c, buf=0x1500030 "", buf_size=101380) at utils.c:946 #4 0x0040f44c in av_find_stream_info (ic=0x36790) at utils.c:1826 #5 0x00405c87 in opt_input_file (filename=0x0) at ffmpeg.c:2834 #6 0x00032422 in ?? () #7 0x00000000 in ?? () from #8 0x00000000 in ?? () from #9 0x0023f900 in ?? () #10 0x0023f8e4 in ?? () #11 0x7c90ee18 in strchr () from ntdll.dll #12 0x7c9106f0 in ntdll!RtlAppendStringToString () from ntdll.dll #13 0xffffffff in ?? () #14 0x7c9106eb in ntdll!RtlAppendStringToString () from ntdll.dll #15 0x77c2c3c9 in msvcrt!free () from C:\WINDOWS\system32\msvcrt.dll #16 0x00030000 in ?? () #17 0x40000060 in ?? () #18 0x77c2c3ce in msvcrt!free () from C:\WINDOWS\system32\msvcrt.dll #19 0x0000003c in ?? () #20 0x77c5fcc0 in msvcrt!_iob () #21 0x00000002 in ?? () #22 0x0023f6cc in ?? () #23 0x00000000 in ?? () from #24 0x00000000 in ?? () from #25 0x7c90ee18 in strchr () from ntdll.dll #26 0x0023f988 in ?? () #27 0x77c35c94 in msvcrt!_except_handler2 () from C:\WINDOWS\system32\msvcrt.dll (gdb) disass $pc-32 $pc+32 Dump of assembler code from 0x5247e1 to 0x524821: 0x005247e1 <mpeg_decode_mb+6625>: pusha 0x005247e2 <mpeg_decode_mb+6626>: pop %es 0x005247e3 <mpeg_decode_mb+6627>: add %al,(%eax) 0x005247e5 <mpeg_decode_mb+6629>: mov 0x1c74(%esi),%edx 0x005247eb <mpeg_decode_mb+6635>: add %edi,%eax 0x005247ed <mpeg_decode_mb+6637>: mov %eax,0x760(%esi,%ebx,4) 0x005247f4 <mpeg_decode_mb+6644>: sub %edx,%ecx 0x005247f6 <mpeg_decode_mb+6646>: mov 0xffffffcc(%ebp),%edi 0x005247f9 <mpeg_decode_mb+6649>: shl %cl,%eax 0x005247fb <mpeg_decode_mb+6651>: mov 0x1c88(%esi),%ecx 0x00524801 <mpeg_decode_mb+6657>: mov %ax,(%edi) 0x00524804 <mpeg_decode_mb+6660>: xor $0x1,%eax 0x00524807 <mpeg_decode_mb+6663>: cwtl 0x00524808 <mpeg_decode_mb+6664>: mov %eax,0xffffffbc(%ebp) 0x0052480b <mpeg_decode_mb+6667>: test %ecx,%ecx 0x0052480d <mpeg_decode_mb+6669>: mov $0x681780,%eax 0x00524812 <mpeg_decode_mb+6674>: jne 0x524819 <mpeg_decode_mb+6681> 0x00524814 <mpeg_decode_mb+6676>: mov $0x6816c0,%eax 0x00524819 <mpeg_decode_mb+6681>: mov 0xfffffff0(%ebp),%esi 0x0052481c <mpeg_decode_mb+6684>: mov 0x3c(%eax),%eax 0x0052481f <mpeg_decode_mb+6687>: mov 0x1c3c(%esi),%ebx When loaded in GraphEdit this file needs 2 filters named "Decrypt/Tag". And it doesn't decode when ffdshow is used (either with libmad or mp3lib). But it does decode when using DScaler5. Dunno what library they use, apparently libmad: http://cvs.sourceforge.net/viewcvs.py/deinterlace/DScaler5/Filters/Decoders… For those interrested in finding out what's wrong, here is the sample URL: ftp://uleguadv:refulavi at ftp.divxnetworks.com/today.dvr-ms Steve

5 14

mpegts.c cleanup patch
by danielk＠cuymedia.net 23 Jan '07

23 Jan '07

This is a cleanup patch generated with a selective diff against the mythtv fork. This patch doesn't bring in any of the bug fixes in the mythtv version, it just brings over some documentation, gets rid of the definition for the mpegts crc function (which no longer exists), changes printf's to av_log's, adds a few debugging messages on non-fatal errors and changes C++ comments to C comments. -- Daniel

5 6

Possible bug in h264 dec
by francis_labonte＠hotmail.com 23 Jan '07

23 Jan '07

Hi, Runnning valgrind on a file, I got some invlid read. It points to: H264_CHROMA_MC8_TMPL in dsputil_h264_template_mmx.c called by mc_dir_part in h264.c In my opinion, I think it could come from here: if( full_mx < 0-extra_width || full_my < 0-extra_height || full_mx + 16/*FIXME*/ > pic_width + extra_width || full_my + 16/*FIXME*/ > pic_height + extra_height) "<" should become "<=" for the 2 FIXME. An index ( mx, my) ranging from 0-... is compared to a size ranging from 1-,,, Applying my modification fix my invalid. I would like to have have some input to know if my analysis make sens or not! Thank you Francis NOTE: I'me not using the latest version of CVS, but this line didn't change in HEAD, and a friend told me he got similar result with HEAD version.

2 1

SIGSEGV in h264.c, stream is available for debugging
by dario＠ip.tv 23 Jan '07

23 Jan '07

> > I've got a SIGSEGV decoding h264, the stream was generated by x264. > > > The following stream was recorded live and begins from the middle: > > > http://www.datscom.com.br/~dario/dump.SIGSEGV.h264 > > >the following command line reproduces the fault (the source code is updated >from cvs as of 09/05/2005 08:13pm GMT-3). > >$ ./ffmpeg -i dump.SIGSEGV.h264 -f null dump.SIGSEGV.h264.null > Has anyone got any status on that subject? Anyway, I've managed to increase the number of max reference pics (at least from what I could understand from the code), from 16 to 32 in h264.c, and it seems to help a little (the stream above now decodes to the end). btw, nice symbolic constants would be nicer than things like that spread all over the code: for (i = 0; i < 16; i++) ... Picture* delayed_pics[16]; etc... :-) The above stream now decodes ok, but the following one fails with "getbuffer() failed" and consequently (no checks for the getbuffer calls) SIGSEGV. I assume there is some leak somewhere? http://bule.ip.tv/~dario/dump.SIGSEGV.1.h264 Again, I'd appreciate any help on the subject. Regards, Dario Andrade R&D IP.TV

3 2

[PATCH] MingW RTSP support
by mike＠mikekohn.net 30 Oct '06

30 Oct '06

This patch adds networking support for MingW allowing libavformat to connect to RTSP sources. The diff file was compared to CVS as of March 31, 2006 at around 8am.

7 18

PATCH: make libavformat find codecid for AAC streams in matroska container.
by elupus＠ecce.se 30 Oct '06

30 Oct '06

Hi, Here is a small patch to allow libavformat to find the codec on AAC streams in matroska containers. The defines for the AAC codec's are set like this, #define MATROSKA_CODEC_ID_AUDIO_MPEG2 "A_AAC/MPEG2/" #define MATROSKA_CODEC_ID_AUDIO_MPEG4 "A_AAC/MPEG4/" which isn't the full name for the codec's. I.e. it normally has some more extension to it like MAIN, LC... Anyway, this patch fixes so that when the codec_id is compared to these defines, only the given length is compared (which I think was the original idea). I suppose some more information could be gotten from that extra information, but I think this should be enough. Cheers /Joakim

11 16

[PATCH] qpel approximation
by lorenm＠u.washington.edu 01 Oct '06

01 Oct '06

This patch adds approximate bilinear qpel mc functions, enabled for B-frames only, with -lavdopts fast. Comments: does it look ok? should it have a separate option? 16x16 mc costs, averaged over all subpel positions: mpeg4 qpel: 1443 cycles h264 qpel: 1148 cycles bilinear qpel: 174 cycles mpeg4 hpel: 99 cycles total speedup: ~12% in mpeg4, ~5% in h264. --Loren Merritt

4 4