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

[RFC] better ogg seeking, keyframes only
by Reimar.Doeffinger＠stud.uni-karlsruhe.de 01 Dec '08

01 Dec '08

Hello, I admit this is a rather ugly patch, but it improves things a lot, so maybe you can have a look and get it committable. There are several issues with seeking: for audio, PKT_FLAG_KEY is never set, so the patch ignores it there, the data_offset set by the code in util.c is wrong, so this code overrides it, and the most annoying thing: a keyframe most likely is split over multiple ogg pages, so this code just returns the start of the last page read by the last get_packet as start offset for the keyframe - this means we might actually end up a few frames before the key frame (in theory up to 255), if the encoded frames are very small. Greetings, Reimar D?ffinger

4 10

[RFC] ratecontrol buffer size magic
by baptiste.coudurier＠smartjog.com 29 Nov '08

29 Nov '08

Hi, I stumbed accross a weird behaviour of the CBR ratecontrol lately, basically doing: ffmpeg -i file.mpg -vcodec mpeg2video -minrate 30000k -maxrate 30000k -b 30000k -intra -flags +ildct+low_delay -dc 10 -flags2 +ivlc+non_linear_q -ps 1 -qmin 1 -qmax 12 -top 1 -vglobal 4 -acodec pcm_s16be -f mov -bufsize 1200000 -rc_init_occupancy 1200000 cbr.mov Constraints are so in order to achieve vbv delay as 3600. Now ffmpeg will only give me qp as 24. While tweaking I changed some magic in ratecontrol.c (see patch attached) and now qp have decent/good values. I dig into svn history and found out that r2601 bumped */2 to */3 to improve CBR ratecontrol. Can anyone explain in detail why that magic does improve behaviour ? Can that parameter be user setable ? Or is it really hardcoded everywhere ? Am I doing something terribly wrong ? Thanks for comments. -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312

4 19

[PATCH] Implement an option in ffmpeg to make it print the output SDP and exit
by stefano.sabatini-lala＠poste.it 29 Nov '08

29 Nov '08

Hi all, this patch changes the current behavious of ffmpeg which currently print if needed the SDP of the output streams. This patch implements a behaviour which could result useful when scripting things like this: ffmpeg -i ~/test.avi -vn -sdp -f rtp rtp://localhost:5004 > test.sdp ffplay test.sdp ffmpeg -i ~/test.avi -vn -f rtp rtp://localhost:5004 > test.sdp Since I think this is the assumed use for the SDP output then I think this behaviour is preferable since it doesn't require the user to invoke a transcoding just to print out the SDP. Note that this breaks compatibility with the previous behaviour, now when ffmpeg is invoked without -sdp it won't print the SDP anymore. Also the SDP printed won't be prefixed by "SDP:\n" as before. Comments/suggestions are welcome as always. Regards. -- FFmpeg = Furious & Friendly Martial Proud Elitarian God

5 32

[RFC] Eliminate -re and make -rate_emu set by AVOption
by stefano.sabatini-lala＠poste.it 27 Nov '08

27 Nov '08

Hi all, currently ffmpeg -re -i ... doesn't work with only audio files, which makes for example tricky to stream with RTP audio streams. This is because rate_emu is currently set in opt_input() only for video streams, and is ignored if there is only an audio stream to transcode (for example if you're using -vn). My solution is to make -rate_emu settable through AVOption options using rate_emu, then remove the -re option. This alone doesn't fix the problems for audio-only multimedia streams streaming, there are still timestamp issues to be addressed. I'm not sure this is the best solution, so I'm posting it here to foster ideas and suggestions. To test the patch: stefano at geppetto ~/s/ffmpeg> ffmpeg -rate_emu 1 -i ~/test2.flv -vn -f avi -y /dev/null FFmpeg version SVN-r14225, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --prefix=/home/stefano --disable-shared --enable-libschroedinger --enable-libx264 --enable-pthreads --enable-gpl --enable-debug=3 --enable-libtheora --enable-libvorbis --enable-avfilter --enable-libamr-nb --enable-libamr-wb --enable-nonfree --enable-libfaad --enable-libfaac --enable-x11grab --enable-libmp3lame --disable-optimizations --disable-mmx libavutil version: 49.7.0 libavcodec version: 51.60.0 libavformat version: 52.17.0 libavdevice version: 52.0.0 libavfilter version: 0.0.0 built on Jul 14 2008 00:56:52, gcc: 4.2.3 20071014 (prerelease) (Debian 4.2.2-3) Seems stream 0 codec frame rate differs from container frame rate: 1000.00 (1000/1) -> 25.00 (25/1) Input #0, flv, from '/home/stefano/test2.flv': Duration: 00:00:30.01, start: 0.000000, bitrate: 96 kb/s Stream #0.0: Video: vp6f, yuv420p, 320x240, 25.00 tb(r) Stream #0.1: Audio: mp3, 44100 Hz, mono, 96 kb/s Output #0, avi, to '/dev/null': Stream #0.0: Audio: mp2, 44100 Hz, mono, 64 kb/s Stream mapping: Stream #0.1 -> #0.0 Press [q] to stop encoding size= 0kB time=29.68 bitrate= 0.0kbits/s video:0kB audio:232kB global headers:0kB muxing overhead -99.999579% Note that (at least in my case) I don't get frame rate emulation since the codec time base for the audio is set to {0,0}, nonetheless now ffmpeg will execute this part of code within output_packet(): /* frame rate emulation */ if (ist->st->codec->rate_emu) { int64_t pts = av_rescale((int64_t) ist->frame * ist->st->codec->time_base.num, 1000000, ist->st->codec->time_base.den); int64_t now = av_gettime() - ist->start; if (pts > now) usleep(pts - now); ist->frame++; } Regards. -- FFmpeg = Forgiving & Funny MultiPurpose Extended Genius

4 29

[HACK] parse m4a metadata
by Reimar.Doeffinger＠stud.uni-karlsruhe.de 16 Nov '08

16 Nov '08

Hello, with attached patch FFmpeg can read the metadata from http://samples.mplayerhq.hu/A-codecs/lossless/luckynight.m4a It is still quite ugly, and I do not want to spend any time on it, so cleaning up is something that someone else must do. There is also a problem that the existing metadata code probably has, too: The strings might contain linebreaks, which are coded mac-style as \r whereas IMO FFmpeg should use \n instead. Greetings, Reimar D?ffinger

3 2

I have discovered why many MinGW installs can no longer build ffmpeg
by ccormie＠aussiemail.com.au 08 Nov '08

08 Nov '08

Hi, I'm new to ffmpeg development; hello everyone! Back in April the ffmpeg makefiles were splendidly re-engineered by M?ns Rullg?rd to be non-recursive (and and much rejoicing was heard throughout the land, apparently.) http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-April/045168.html At the time testers reported current MinGW installs failing to build with the new makefiles. The poster's problem was resolved by changing their version of make to a specific version: mingw32-make-3.81-2 (not the current version). The cause of the problem wasn't found. I have discovered a cause: MinGW make version 3.79.1 (and earlier?) cannot handle calling a macro within a foreach statement. And this construct is used by the new non-recursive makefiles. Specifically: define DOSUBDIR $(foreach V,$(SUBDIR_VARS),$(eval $(call RESET,$(V)))) SUBDIR := $(1)/ include $(1)/Makefile endef $(foreach D,$(FFLIBS),$(eval $(call DOSUBDIR,lib$(D)))) Fails silently (ouch) -- the include statement is never executed. The new system depends on the above code: the Makefiles in the subdirectories include the toplevel subdir.mak where the rules for building the libraries are located. This is why Axel Holzinger was reporting "make: *** No rule to make target `libavdevice/libavdevice.a', needed by `all'. Stop." This is a bit of an issue because the (complex, error prone) official MinGW installation instructions yield make 3.79.1 Some later versions of MinGW make can be shown not have this bug: mingw32-make-3.81-2 make-3.81-MSYS-1.0.11-2.tar.bz2 But apparently the current release has different (breaking) bugs: mingw32-make-3.81-20080326 This is a horrible situation for those of us trying to build ffmpeg on MinGW. It would be good if we could put a note about the issue somewhere -- perhaps in the README? I think a lot of people could be wasting time over this one, given the "standard" MinGW install is affected. I've also got a patch for configure that catches the 3.79.1 bug and warns the developer (below.) Could this be considered for testing and merging in? Regards, Chris Cormie Index: configure =================================================================== --- configure (revision 14784) +++ configure (working copy) @@ -221,7 +221,7 @@ solving the problem. EOF fi - rm -f $TMPC $TMPE $TMPH $TMPO $TMPS $TMPSH + rm -f $TMPC $TMPE $TMPH $TMPO $TMPS $TMPSH $TMPM exit 1 } @@ -592,6 +592,13 @@ EOF } +check_make(){ + log check_make "$@" + cat >$TMPM + log_file $TMPM + check_cmd make -f $TMPM +} + require(){ name="$1" header="$2" @@ -1124,6 +1131,7 @@ TMPO="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.o" TMPS="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.S" TMPSH="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.sh" +TMPM="${TMPDIR1}/ffmpeg-conf-${RANDOM}-$$-${RANDOM}.mak" check_cflags -fasm check_cflags -std=c99 @@ -1262,6 +1270,7 @@ SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME).$(LIBMAJOR)$(SLIBSUF)' FFSERVERLDFLAGS=-Wl,-bind_at_load objformat="macho" + enabled x86_64 && objformat="macho64" ;; mingw32*) target_os=mingw32 @@ -1561,6 +1570,7 @@ enabled_all x86_64 shared && append YASMFLAGS "-DPIC" case "$objformat" in elf) enabled debug && append YASMFLAGS "-g dwarf2" ;; + macho64) append YASMFLAGS "-DPIC -DPREFIX" ;; *) append YASMFLAGS "-DPREFIX" ;; esac check_yasm "pabsw xmm0, xmm0" && enable yasm @@ -1693,6 +1703,22 @@ EOF done +# Check for broken MinGW make +check_make <<'EOF' || die "Broken make utility. If using MinGW try a later version of make. make-3.81-MSYS-1.0.11-2 is known to work." +define a + $(eval var = val) +endef +TEST_LIST = a b +$(foreach D, $(TEST_LIST),$(eval($(call a)))) +all: +ifeq ($(var),val) + @exit 0 +else + @exit 1 +endif +EOF + + # these are off by default, so fail if requested and not available enabled avisynth && require2 vfw32 "windows.h vfw.h" AVIFileInit -lvfw32 enabled liba52 && require liba52 a52dec/a52.h a52_init -la52

9 23

[RFC] Channel layouts
by pross＠xvid.org 04 Nov '08

04 Nov '08

Hi. This patch adds the notion of channel layouts to libavcodec. Summary of new concepts: * Channel IDs: We give each speaker a notional bit index. e.g. CHANNEL_FRONT_LEFT=0, CHANNEL_FRONT_RIGHT=1, CHANNEL_BACK_CENTER=9 * Channel Layout: An ORing together of Channel IDs. e.g. ((1<<CHANNEL_FRONT_LEFT)|(1<<CHANNEL_FRONT_RIGHT)) The resulting layout is identical to the dwChannelMask value found in WAVEFORMATEXTENSIBLE. A channel layout of zero implies 'no statement'. * Chanels are stored with the FFmpeg 'samples' array according to ID order e.g. left comes before right. * Encoders will indicate their supported channel layouts in AVCodec, in the same way we do for pixel and sample formats. -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)

16 68

[PATCH] split-radix FFT
by lorenm＠u.washington.edu 03 Nov '08

03 Nov '08

$subject, vaguely based on djbfft. Changed from djb: * added simd. * removed the hand-scheduled pentium-pro code. gcc's output from simple C is better on all cpus I have access to. * removed the distinction between fft and ifft. they're just permutations of eachother, so the difference belongs in revtab[] and not in the code. * removed the distinction between pass() and pass_big(). C can always use the memory-efficient version, and simd never does because the shuffles are too costly. * made an entirely different pass_big(), to avoid store->load aliasing. I tried the tangent FFT, but I couldn't make it faster than split-radix. Tangent has asymptotically 5% fewer arithmetic ops, but only 1-2% for sizes typical of audio codecs, and even a couple extra shuffles or other overhead pushes it over. I tried an in-place fft_permute, but it wasn't any faster than out-of-place + memcpy, and quite a bit more complex. benchmarks (cycles): 2^4 2^5 2^6 2^7 2^8 2^9 2^10 2^11 2^12 2^13 2^14 2^15 2^16 fft size 368 1204 2925 6958 15864 35742 79907 176930 391877 954522 2582623 7027105 15979384 k8.svn.c 201 641 1666 4168 9730 22360 49814 111063 245835 551301 2140560 5449270 14161100 k8.djb.c 194 627 1656 4169 9923 22881 51998 116276 257871 577594 1983282 4926132 12508115 k8.split.c 148 526 1546 3537 7757 17209 38176 85052 189656 461192 1180269 2665751 6856414 k8.svn.sse 122 459 1380 3111 6687 14719 32318 71412 165771 418068 1112945 2575784 6684035 k8.svn.3dn2 173 478 1208 2832 6397 14097 30816 66861 145040 327352 1163446 2907148 7465755 k8.split.3dn2 114 363 934 2206 5190 11527 25515 55826 122329 272338 821973 1974221 4931610 k8.split.sse 298 870 2196 4998 11462 25954 58196 129402 290652 652258 1515451 3379696 7337748 conroe.svn.c 138 396 1016 2453 5703 13080 29542 72980 166937 382352 852779 1965809 4289844 conroe.djb.c 132 383 959 2443 5691 12957 29167 64625 141885 310046 670222 1449479 3131753 conroe.split.c 114 390 926 1978 4112 8825 19316 42252 94760 214178 462689 994594 2200585 conroe.svn.sse 82 216 498 1221 2630 5715 12265 26415 58853 126274 269532 568314 1220458 conroe.split.sse 318 932 2430 5578 12857 29093 65321 145709 327347 745524 1763483 3977390 8756696 penryn.svn.c 129 420 1146 2824 6670 15907 35248 87700 199251 454614 1015788 2309352 5068660 penryn.djb.c 151 424 1094 2746 6369 14604 32945 73085 161065 354042 768205 1672258 3601885 penryn.split.c 72 335 834 1776 3626 7733 17273 38134 88629 204577 449889 982217 2171035 penryn.svn.sse 36 144 418 1054 2343 5127 11289 24670 56975 124178 268514 578586 1262736 penryn.split.sse 729 1869 4909 12412 28876 65702 147951 337286 786350 1770779 3988037 10739966 42763027 prescott.svn.c 463 1224 3179 7644 18052 41395 91632 206204 450451 985720 2173172 4685558 10307042 prescott.djb.c 434 1155 2894 6963 16356 37468 87928 202304 457022 1012743 2257329 5002317 10999607 prescott.split.c 222 522 1208 2909 6858 15517 34318 83046 193854 465508 1221169 5221734 17064482 prescott.svn.sse 124 370 850 2003 4377 10050 22798 51432 113311 254526 590618 1548052 3930814 prescott.split.sse --Loren Merritt

14 86

Visibility implementation
by uoti.urpala＠pp1.inet.fi 01 Nov '08

01 Nov '08

The attached patch adds visibility information for lots of symbols in libavcodec. I used the following macros to mark visibility: HIDDEN Used in a declaration or definition to indicate that the symbol is internal to the currently compiled library. extern HIDDEN int libavcodec_internal_int; HIDDEN void libavcodec_internal_function(void); START_HIDDEN_VISIBILITY_SECTION END_VISIBILITY_SECTION Declarations and definitions between these 2 macros have hidden visibility by default. EXTERNALLY_VISIBLE Used in a declaration/definition between the above 2 macros to indicate that some symbol should NOT have hidden visibility, but should behave as normal. These macros are defined in libavutil/internal.h. Currently they're defined unconditionally; a compiler check should be added for production code. Some other names for the macros could also be used. Visibility information matters in 2 cases: when a symbol is defined (to make the compiler place it in the correct section) and when any other code accesses it (knowing that a symbol has hidden visibility helps avoid the overhead of -fPIC). If a declaration which marks the symbol hidden is visible then it is not necessary to indicate the visibility information again where the symbol is defined. So in most cases marking the declarations in internal headers hidden is enough (if the file defining the symbol and all files using it include the header). Most of the patch is adding START_HIDDEN_VISIBILITY_SECTION at the start and END_VISIBILITY_SECTION at the end of various internal headers. If some .c file has a global definition which does not appear in a public header, and another file has its own internal declaration for that symbol, then it's necessary to mark those hidden separately. See ff_flac_compute_autocorr for an example of this in the patch. When adding START_HIDDEN_VISIBILITY_SECTION/END_VISIBILITY_SECTION in headers one thing to watch out for is to make sure you don't put it around #include statements. Other headers included between those macros would also use hidden visibility by default, which would likely lead to breakage. The following symbols were used outside libavcodec and caused compilation errors when everything in their corresponding headers was declared hidden: ff_cropTbl (used in vhook), ff_frame_rate_tab, ff_mpa_decode_header, ff_mpa_bitrate_tab, ff_mpa_freq_tab, ff_find_start_code (used in libavformat). I added the EXTERNALLY_VISIBLE macro to their definitions to turn them back to publicly available outside the library. In my test compilation this patch lowered the amount of public symbols in libavcodec.so that are exported for use by external programs from 1100 to 378 (counted with "nm -D libavcodec.so | grep -c '^[^ ]'"). Even though I didn't add HIDDEN macros to the various xxx_decoder, xxx_encoder etc definitions referring to them as external hidden symbols in allcodecs.o seems to be enough to prevent the linker from making them publicly available in the final library.

8 34

[silviapfeiffer1@gmail.com: [foms] FOMS 2009 CFP deadline extension]
by diego＠biurrun.de 01 Nov '08

01 Nov '08

I thought I'd forward this in case anybody is interested in attending... ----- Forwarded message from Silvia Pfeiffer <silviapfeiffer1 at gmail.com> ----- From: Silvia Pfeiffer <silviapfeiffer1 at gmail.com> Date: Fri, 15 Aug 2008 10:42:22 +1000 To: Foundations of Open Media Software <foms at lists.annodex.net>, FOMS organising committee <foms-committee at lists.annodex.net> Subject: [foms] FOMS 2009 CFP deadline extension Hi all, FOMS 2009 is approaching - have you thought about attending? We want to get a varied mix of people there, from all across the open media software space and would be particularly keen to have people attend from the ffmpeg, gstreamer, vlc, and xine communities. So far we have registrations from Mozilla, Xiph, BBC, ALSA and user communities - 15 people already. Key topics this year are: * open audio & video codecs * open audio & media frameworks * audio infrastructure * web video (HTML5 audio/video) and crossover with open source * mobile video * open audio & video applications * open metadata * open media standards As in previous years, we have financial sponsorship for a few developers, none of which have been distributed yet, so think about an awesome trip into the summer of January 2008 to Hobart, Tasmania (yes, it's summer there in January)! We've just extended the submission deadline for indicating your interest in a travel sponsorship to 31st August. Just email foms-committee at lists.annodex.net. Go for it! Cheers, Silvia. _______________________________________________ foms mailing list foms at lists.annodex.net http://lists.annodex.net/cgi-bin/mailman/listinfo/foms ----- End forwarded message -----

5 7