February 2010 - ffmpeg-devel - lists.ffmpeg.org

[PATCH] AVHWAccel infrastructure v2
by gbeauchesne＠splitted-desktop.com 24 Nov '10

24 Nov '10

Hi, This patch updates the AVHWAccel infrastructure to make it possible to: - Get rid of the PixelFormat hacks - Get pixels back from GPU memory when the user requested it - Fallback implicitly to SW decoding - Handle multiple hardware accelerators (e.g. different chips in a single system) - Enable user-applications very easily As a bonus, it's backwards compatible with the v1 infrastructure. On a user point of view, everything is now controlled with HWAccelAttributes. - HW specific context that is initialized by the user (e.g. a VAAPI context: HWACCEL_ATTR_VAAPI_DISPLAY) - HWACCEL_ATTR_GET_PIXELS: controls whether the user wants decoded pixels in Picture.data[0-2] as usual (off by default for performance) - HWACCEL_ATTR_FORCE_ID: controls whether the user wants a specific HW accelerator No get_buffer() override. Nothing but AVCodecContext.hwaccel_attrs to be filled in. It's an array of uintptr_t that is HWACCEL_ATTR_NONE terminated. As a result, enabling ffplay for VAAPI was a very simple operation. On the MPlayer side, the usual VO (x11, xv, gl2) can be kept with very minimal changes too. Regards, Gwenole.

6 39

[RFC] WC3 decoder without AVPaletteControl
by Reimar.Doeffinger＠gmx.de 21 Nov '10

21 Nov '10

Hello, attached patch implements this. It is a bit ugly because it adds a lot of seeking to the demuxer, but I think for such a fringe format there is no point in extra work for avoiding it. The patch also adds two helper functions, one to increase the size of a packet and one that appends data read from a file to a possibly already filled packet. I expect that there will be more that a few bugs still, e.g. while the video looks visually ok in ffplay the FATE regressions do not match at all.

3 52

using usb hardware h264 encoders
by piratfm＠gmail.com 11 Nov '10

11 Nov '10

Hi all. I wrote a little library, designed to control hardware h264 codec, based on MG1264. Also I integrate it with ffmpeg as libcrusher264, it's in very beta state, but usable. It was tested in mpeg2->h264 transcoding, and patched ffmpeg can encode video in real-time (or faster) up to 640x480. Here is library and patch: http://tipok.org.ua/node/13

5 19

Handling dual language mono audio encoded as stereo
by anssi.hannula＠iki.fi 10 Nov '10

10 Nov '10

Hi all! Some nordic DVB channels encode e.g. four mono tracks with different languages into two stereo tracks (mpeg layer 2). The ISO639 language descriptor then has both language codes, separated by a null byte. This is probably a remnant from pre-DVB era, but we should somehow handle it nevertheless. How should we handle this, what do you think? Attached is a patch which simply sets language tag to e.g. "nor+fin" for dual- language stereo tracks. Seems to show up correctly in ffplay (though of course there doesn't seem to be a way to choose a single channel from stereo track in ffplay). -- Anssi Hannula

2 7

[PATCH] Document url_write()
by stefano.sabatini-lala＠poste.it 31 Oct '10

31 Oct '10

As in subject, docs partially stolen from the GNU libc write() docs. Regards. -- FFmpeg = Fantastic and Fiendish Minimal Prodigious Excellent Gargoyle

2 6

[PATCH] H.264: reinitialize context on aspect ratio change as well
by jkrzyszt＠tis.icnet.pl 22 Oct '10

22 Oct '10

Hi, While using ffmpeg based vdr softdevice plugin for watching h.264 encoded live tv, I found that after correct picture aspect ratio setup on a new stream startup, any following picture aspect ratio changes were not processed. This patch corrects the problem for me by reinitializing the decoder context on every aspect ratio change in addition to geometry changes. Created and tested against gentoo ffmpeg-0.4.9_p20090201 ebuild (0.5 did not yet work for me with vdr softdevice plugin flawlessly enough). Refreshed and compile tested on top of svn revision 22026 dated 2010-02-24. Signed-off-by: Janusz Krzysztofik <jkrzyszt at tis.icnet.pl> --- --- ffmpeg/libavcodec/h264.c.orig 2009-02-24 15:55:12.000000000 +0100 +++ ffmpeg/libavcodec/h264.c 2010-02-27 13:34:33.000000000 +0100 @@ -1776,7 +1776,9 @@ static int decode_slice_header(H264Conte s->height= 16*s->mb_height - 4*FFMIN(h->sps.crop_bottom, 3); if (s->context_initialized - && ( s->width != s->avctx->width || s->height != s->avctx->height)) { + && ( s->width != s->avctx->width || s->height != s->avctx->height + || h->sps.sar.num != s->avctx->sample_aspect_ratio.num + || h->sps.sar.den != s->avctx->sample_aspect_ratio.den)) { if(h != h0) return -1; // width / height changed during parallelized decoding free_tables(h);

3 6

url_exists function in avio.c opens instead of checking existence
by maker.py＠gmail.com 30 Sep '10

30 Sep '10

hello. This is my first post, so sorry for my bad English and for whatever wrong i will do. I started playing with ffmpeg code in order to try to fix this bug: http://thread.gmane.org/gmane.comp.video.ffmpeg.user/24644/focus=24707 In few words, in avio.c uses url_open to check if an url exists (libavformat/avio.c : 199). This is semantically wrong becouse it tries to _open_ that file (in read-only) instead of checking his real existence. This maybe create bugs if the target file is fifo (it loops), has 000 permissions (fails), etc. This can happen with whatever protocol. so, I would like to receive some advice before starting: my original idea was to extend the original URLProtocol structure ( doc here<http://cekirdek.pardus.org.tr/%7Eismail/ffmpeg-docs/structURLProtocol.html#…>) with something like " int(* url_exists )(URLContext *h, const char *filename) " and create some functions to check if filename exists using stats. It's a clear solution, but I would make URLProtocol a little bigger. Then I would make a parse_url function (this actually is done by url_open [111:135 lines], but it's not its job) and edit url_exists in order to use proto->url_exists. Is this solution ok for you, or there's something better I could do?

5 11

Close Thread Handle in avcodec_thread_free
by shehzadsalim＠gmail.com 13 Sep '10

13 Sep '10

Hi guy's I am willing to post a patch for avcodec_thread_free. When using multi threaded video decoding and upon closure in avcodec_thread_free thread handle are not being closed But I have no idea to how to create a diff file or patch file on windows OS. Only one line is added in avcodec_thread_free function which is CloseHandle(c[i].thread); void avcodec_thread_free(AVCodecContext *s){ ThreadContext *c= s->thread_opaque; int i; for(i=0; i<s->thread_count; i++){ c[i].func= NULL; ReleaseSemaphore(c[i].work_sem, 1, 0); WaitForSingleObject(c[i].thread, INFINITE); if(c[i].work_sem) CloseHandle(c[i].work_sem); if(c[i].done_sem) CloseHandle(c[i].done_sem); CloseHandle(c[i].thread); } av_freep(&s->thread_opaque); } Thanks -- ?????? ????? ????? ???? ?????? Best Regards Shehzad Salim

8 17

[PATCH] Implement libavcodec/opt.[ch] generic options handling
by stefano.sabatini-lala＠poste.it 10 Sep '10

10 Sep '10

Hi all, this is my first attempt to move the option handling code from the applications to the library, it also should make possible to remove the deprecated lavf AVFormatParameters. Please comment. Regards. -- FFmpeg = Furious Faboulous Majestic Picky Encoding/decoding Gangster

2 12

[PATCH] g722 decoder, no licensing fame
by kenan.gillet＠gmail.com 10 Sep '10

10 Sep '10

On Wed, Mar 25, 2009 at 2:39 PM, Michael Niedermayer <michaelni at gmx.at> wrote: > On Wed, Mar 25, 2009 at 09:57:51AM -0700, Kenan Gillet wrote: >> Hi, >> >> On Mar 21, 2009, at 1:34 PM, Michael Niedermayer wrote: >> >>> On Sat, Mar 21, 2009 at 12:43:35AM -0700, Kenan Gillet wrote: > [...] >>> >>> >>>> @@ -2819,6 +2822,7 @@ >>>> memset(ap, 0, sizeof(*ap)); >>>> ap->prealloced_context = 1; >>>> ap->sample_rate = audio_sample_rate; >>>> + ap->bit_rate = audio_bit_rate; >>>> ap->channels = audio_channels; >>>> ap->time_base.den = frame_rate.num; >>>> ap->time_base.num = frame_rate.den; >>>> @@ -2892,6 +2896,7 @@ >>>> channel_layout = enc->channel_layout; >>>> audio_channels = enc->channels; >>>> audio_sample_rate = enc->sample_rate; >>>> + audio_bit_rate = enc->bit_rate; >>>> audio_sample_fmt = enc->sample_fmt; >>>> input_codecs[nb_icodecs++] = >>>> avcodec_find_decoder_by_name(audio_codec_name); >>>> if(audio_disable) >>>> @@ -3211,6 +3216,7 @@ >>>> } >>>> nb_ocodecs++; >>>> audio_enc->sample_rate = audio_sample_rate; >>>> + audio_enc->bit_rate = audio_bit_rate; >>>> audio_enc->time_base= (AVRational){1, audio_sample_rate}; >>>> if (audio_language) { >>>> av_metadata_set(&st->metadata, "language", audio_language); >>> >>>> Index: libavformat/avformat.h >>>> =================================================================== >>>> --- libavformat/avformat.h (revision 18096) >>>> +++ libavformat/avformat.h (working copy) >>>> @@ -261,6 +261,7 @@ >>>> enum CodecID video_codec_id; >>>> enum CodecID audio_codec_id; >>>> #endif >>>> + int bit_rate; >>>> } AVFormatParameters; >>>> >>>> //! Demuxer will use url_fopen, no opened file should be provided by the >>>> caller. >>> >>> the whole struct is pretty much deprecated and iam not happy if people >>> add new things to it. >> >> any hint on to "do it the right way" ? > > AVFormatContext.bit_rate maybe but i am not sure if this might cause some > issues > actually a much simpler solution would be to change the -ab options to set in the AVCodecContext.bitrate for decoder too like in the patch attached but it would change the behavior of ffmpeg but that's exactly what is needed, to be able to give the g722 decoder a bit_rate would that be acceptable? Kenan

7 46