December 2009 - ffmpeg-devel - lists.ffmpeg.org

[PATCH] Default to using libraries when enabled
by lessen42＠gmail.com 25 Jun '10

25 Jun '10

Hi, This changes the order of initialization so that external libraries that are enabled are used by default over native codecs. My main motivation in moving these is to be able to have the ogg and mkv muxers default to encoding via libvorbis if it's enabled; currently, specifying CODEC_ID_VORBIS will use the native encoder regardless, which is much worse quality. However, this also affects faad and xvid. IMO, faad should be preferred anyway until the native decoder supports SBR, then dropped soon after. My only argument for xvid is that it's probably what users want to use when they --enable-libxvid.

11 37

IEC61937 compatible muxer
by bartek.wolowiec＠gmail.com 16 Jun '10

16 Jun '10

Hi, Here is IEC61937 compatible muxer. It can be used for sending compressed data over S/PDIF link. It's currently not very useful, but can be tested by: ./ffmpeg -y -i test_48khz.dts -acodec copy -f spdif test.spdif && ./ffmpeg -ar 48000 -f s16le -ac 2 -i test.spdif -f alsa plughw:0 -- Bartlomiej Wolowiec

7 23

[PATCH] -fs parameter human friendly
by stefano.sabatini-lala＠poste.it 09 Jun '10

09 Jun '10

Hi all, addresses issue 551. It exports the av_strtod() function to eval.h and uses it in ffmpeg.c (minor bump missing for easying the maintainance of the patch). Regards. -- FFmpeg = Funny and Fiendish Meaningless Patchable Embarassing Guide

3 18

a violation of license
by nail＠nodomain.sk 30 May '10

30 May '10

Hello, just for case: I downloaded software for uploading/converting videos/pictures to server rajce.net [1] (developer notes: [2] english translation [3]) which containing ffmpeg and ffplay binaries for win32, without licence and ffmpeg source code. This is testing release. ~/.wine/drive_c/Program Files/rajce_test$ ls ffmpeg.exe ffplay.exe FreeImage.dll FreeImagePlus.ver rajce-cs.lng rajce-en-us.lng rajce-it-it.lng rajce_proxy_setting.ini rajce-uk.lng unins000.dat updater.exe ffmpeg.ver ffplay.ver FreeImagePlus.dll FreeImage.ver rajce-de-de.lng rajce.exe rajce-pl.lng rajce-sk.lng SDL.dll unins000.exe updater.ver wine ffplay.exe FFplay version SVN-r18133, Copyright (c) 2003-2009 Fabrice Bellard, et al. configuration: --enable-memalign-hack --extra-cflags=-fno-common --enable-gpl --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libxvid --enable-avfilter --enable-libamr-nb --enable-libamr-wb --enable-nonfree libavutil 50. 1. 0 / 50. 1. 0 libavcodec 52.22. 2 / 52.22. 2 libavformat 52.32. 0 / 52.32. 0 libavdevice 52. 1. 0 / 52. 1. 0 libavfilter 0. 4. 0 / 0. 4. 0 libswscale 0. 7. 1 / 0. 7. 1 built on Mar 31 2009 22:08:09, gcc: 4.2.1-sjlj (mingw32-2) An input file must be specified wine ffmpeg.exe FFmpeg version SVN-r18133, Copyright (c) 2000-2009 Fabrice Bellard, et al. configuration: --enable-memalign-hack --extra-cflags=-fno-common --enable-gpl --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libxvid --enable-avfilter --enable-libamr-nb --enable-libamr-wb --enable-nonfree libavutil 50. 1. 0 / 50. 1. 0 libavcodec 52.22. 2 / 52.22. 2 libavformat 52.32. 0 / 52.32. 0 libavdevice 52. 1. 0 / 52. 1. 0 libavfilter 0. 4. 0 / 0. 4. 0 libswscale 0. 7. 1 / 0. 7. 1 built on Mar 31 2009 22:08:09, gcc: 4.2.1-sjlj (mingw32-2) At least one output file must be specified [1] http://www.rajce.idnes.cz/stahnout/test/rajce_test56v-129.exe [2] https://docs.google.com/Doc?docid=ajkd99k8zcw6_186vg5dccfp [3] http://translate.google.com/translate?hl=en&sl=cs&tl=en&u=http%3A%2F%2Fdocs…

3 4

[PATCH] add md5 muxer
by Reimar.Doeffinger＠gmx.de 25 May '10

25 May '10

Hello, we have -f crc, but IMO 32 bit crc are a bit little for a whole file and also we use md5sum in the regression tests, so I'd propose to add a -f md5 as in attached patch.

11 32

Again problems with lavfi/swscale
by stefano.sabatini-lala＠poste.it 16 May '10

16 May '10

I'm experiencing problems with commands of the kind: ffplay in.avi -vfilters "slicify=20, format=FORMAT" yuv444p,yuv411p,yuv422p,monow -> crash in RENAME(hScale) rgba,argb,rgb24,bgr24,rgb555 -> crash in YUV2RGBFUNC()/LOADCHROMA yuv410p -> chroma artefacts rgb8 -> crash in PUTRGB8 Formats which work fine: yuv420p, yuvj420p, monob nv12, nv21 (with the patch by Ramiro) gray, gray16 The commands without the slicify filter work just fine, so the problem seems to depend on the slicification of the image (yes at this point is clear that we need some testing system for spotting all these problems). If someone with more experience with libswscale wants to give some hint it would be cool. Regards. -- FFmpeg = Fundamental and Frenzy Merciful Ponderous Extreme Guide

7 49

Fwd: [PATCH] Psygnosis YOP demuxer
by yadudoc1729＠gmail.com 30 Mar '10

30 Mar '10

?Hi, Attached patch is a cleaned up variant of the one submitted by Thomas Higdon [1] and includes the demuxer only. The decoder patch will follow once (hopefully) this is in. Comments appreciated. [1] http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/95133/focus=95474 -- Regards, Yadu Nand B

11 83

[PATCH] Implement PAFF in H.264
by heydowns＠borg.com 26 Mar '10

26 Mar '10

Attached is a patch that implements PAFF in H.264. I don't expect this to be accepted right away, due to size and complexity, but I want to get it out there for review and for people to try out and comment on. It is working stable for me on a number of samples, including ones that mix PAFF with progressive and/or MBAFF. Basic overview of how it works: 1. Fields are decoded and deinterlaced. 2. If non-paired fields are encountered, they are not output, but are used for reference if so marked. 3. Reference lists are kept as they were before, but now may also contain unmatched field pairs. Reference list construction splits field pairs out to fields as needed. There is a major shortcoming/known issue with this patch; it disables the error concealing calls for field pictures. This is because the error concealer needs slices to be contiguous regions of the picture buffers. I'd appreciate input on how best to augment the error concealer to handle interlaced slices (or if I am just missing something....) Also interested in hearing how this should be split into smaller patches (I know that at least the addition/changes to header documentation should come out). -Jeff

15 101

[PATCH] Port VDPAU to AVHWAccel infrastructure
by gbeauchesne＠splitted-desktop.com 25 Mar '10

25 Mar '10

Hi, This patch moves VDPAU code to AVHWAccel. An older version (without MPEG-4 ASP) was already tested by NVIDIA. However, - A separate patch would remove vdpau_internal.h - I don't know what to do with older pixfmts since they are now completely obsolete and useless (the hwaccel v2 proposal nukes all pixfmts anyway) - It's a plain and straightforward port, no effort was made to fix current bugs in the VDPAU code (including the memory leaks) Regards, Gwenole.

7 11

Awakening of FFH264
by kvide＠scilla.tv 23 Mar '10

23 Mar '10

Floks, We have been working on the native FFmpeg H.264 encoder that University of Hasselt started developing in 2007... With some updates to macroblock iterations, patches to NAL generation, addition of VUI data, better rate control etc., the codec produces ?fair" quality baseline profile video using 16x16 macroblocks and the generated streams are decodable with FFmpeg's H.264 decoder, QuickTime 7 and the reference implementation (JM 16.something). Before I submit patches (against r20511 or later) I?d just like check some minor issues: 1. From an FFmpeg point of view the codec uses identically same settings as x264. Should it still use its own codec id; CODEC_ID_FFH264 or can we use same codec id as x264; CODEC_ID_H264? The previous implies lots of these? - if (st->codec->codec_id == CODEC_ID_H264) + if ((st->codec->codec_id == CODEC_ID_H264) || (st->codec->codec_id == CODEC_ID_FFH264)) 2. I haven?t found any documentation on how to add regressions tests. Are there any summaries or docs available? 3. Main changes to current code base would be to h264dspenc.c Are there any already available options not to have to add these to h264enc.c? (or some suggestions on where they should be added) void h264_hadamard_mult_2x2 (DCTELEM Y [2] [2] ); void (*h264_idct_notranspose_add) (uint8_t *dst, DCTELEM *block, int stride); void (*h264_hadamard_mult_4x4) (DCTELEM Y [4] [4]); With or without comments I try to have the patches cleaned up and posted during the weekend. Mvh, Christian

8 19