October 2008 - ffmpeg-devel - lists.ffmpeg.org

[Patch] Enable gpl if enabled nonfree
by cehoyos＠rainbow.studorg.tuwien.ac.at 19 Jan '09

19 Jan '09

Hi! IMO, it does not make much sense to be required to enable nonfree and gpl at the same time if one wants to use a nonfree and a gpl'ed library. Patch attached. Carl Eugen

9 17

[PATCH] Use posix_memalign() instead of memalign() (Was: [PATCH 4/4] Include stdlib.h to avoid an implicit declaration on OpenSolaris.)
by ramiro.polla＠gmail.com 07 Jan '09

07 Jan '09

Hi, On Sun, Sep 28, 2008 at 10:17 AM, M?ns Rullg?rd <mans at mansr.com> wrote: > Diego 'Flameeyes' Petten? <flameeyes at gmail.com> writes: > >> While on GLIBC the memalign() function is declared in malloc.h, on >> OpenSolaris its definiton is in stdlib.h; include the file so that an >> implicit declaration can be avoided. >> --- >> >> libavutil/mem.c | 1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/libavutil/mem.c b/libavutil/mem.c >> index 960074c..da75638 100644 >> --- a/libavutil/mem.c >> +++ b/libavutil/mem.c >> @@ -34,6 +34,7 @@ >> #ifdef HAVE_MALLOC_H >> #include <malloc.h> >> #endif >> +#include <stdlib.h> >> >> /* you can redefine av_malloc and av_free in your project to use your >> memory allocator. You do not need to suppress this file because the > > #including stdlib.h obviously can't do any harm, it being a standard > header. > There is, however, a deeper issue here: memalign() is not > defined by any standard, and some systems that have it provide no > means to free such allocations. Is there any reason we can't use the > standard posix_memalign() instead? Attached patch should spark some discussion... Ramiro Polla

3 13

[PATCH] fix cross-compilation with yasm
by mik＠it-1.ru 07 Jan '09

07 Jan '09

Yasm supports different targets out of box, there is no target-triplet-yasm. Michael

4 6

[PATCH] Define FFMPEG_PREFIX in config.h
by stefano.sabatini-lala＠poste.it 06 Jan '09

06 Jan '09

Hi, as in subject, conceived for supporting $prefix/share/ffmpeg preset paths but useful by its own. Regards. -- FFmpeg = Frightening Foolish Multipurpose Proud Erudite God

3 14

[PATCH 2/4] Define __EXTENSIONS__ to enable struct ip_mreq access on OpenSolaris.
by flameeyes＠gmail.com 06 Jan '09

06 Jan '09

Like for recent GLIBC versions, even OpenSolaris hides the ip_mreq structure by default on C99/POSIX.1-2001 code, to access it, the __EXTENSIONS__ macro has to be defined. Define it so that udp.c builds properly on OpenSolaris. --- libavformat/udp.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/libavformat/udp.c b/libavformat/udp.c index 6a2e642..7c8fef9 100644 --- a/libavformat/udp.c +++ b/libavformat/udp.c @@ -25,6 +25,7 @@ */ #define _BSD_SOURCE /* Needed for using struct ip_mreq with recent glibc */ +#define __EXTENSIONS__ /* Needed for using struct ip_mreq with OpenSolaris */ #include "avformat.h" #include <unistd.h> #include "network.h"

4 8

[PATCH] Enhance ffmpeg.c:opt_default()
by stefano.sabatini-lala＠poste.it 19 Dec '08

19 Dec '08

Hi all, actually opt_default() will keep trying to set an option even if it fails to set it in some context. The correct (or a more correct behaviour) seems to simply give up when the option is found the first time but its value is invalid for that context, in this case the program immediatly exits. Also the patch make opt_default() distinguishes if an option wasn't found in all the checked contexts or if the option was found in some context but its value was invalid. Best regards. -- FFmpeg = Frenzy and Fantastic MultiPurpose EnGine

3 46

[PATCH] Force users to specify memalign_hack in configure
by ramiro＠lisha.ufsc.br 19 Dec '08

19 Dec '08

Hello, Currently on MinGW users are required to explicitly add --enable-memalign-hack to configure. Support for FreeDOS was recently added, and memalign-hack is automatically enabled. I think we should force all users to request memalign-hack when needed. Patch attached. Ramiro Polla

7 25

[PATCH] support for ordered chapters/segment linking in Matroska
by jbfaad＠gmail.com 10 Dec '08

10 Dec '08

Sorry for thread-breaking. Some opinions in this patch: it seems to differ a bit from the "de-facto" behavior of Haali Media Splitter (the only existing implementation). I think it'd be desirable to play along the same way, specially considering this makes things much simpler implementation-wise and I think mostly addresses Michael's comments. In Haali, to accept a segment, TrackType and CodecID must match exactly, for all tracks, in the same order. Everything else is fair game. The values from the "master" segment are used and the ones from the linked segments discarded. This includes CodecPrivate, TrackVideo's childern, TrackAudio's children, etc... Needless to say, the demuxer doesn't handle the case of changing stream parameters: it just passes the frames to the decoder, and doesn't care for anything else. IMHO this is sufficient and even desirable.

6 38

[PATCH] Add a CODEC_CAP_USE_INPUT_BUFFER capabilities flag
by stefano.sabatini-lala＠poste.it 08 Dec '08

08 Dec '08

Hi all, the new flag will be useful for example in libavfilter when the output frame is accessed *after* the call to av_packet_free(). For example it could be used like this: if (is->video_st->codec->codec->capabilities & CODEC_CAP_USE_INPUT_BUFFER) pkt->destruct = av_destruct_packet_nofree; av_free_packet(pkt); This looks nicer than the use of a codec id check, even in the case of rawdec being the only codec having this capability (I don't know if there are other ones like this). I'm omitting minor version bump in the patch. Regards. -- FFmpeg = Faboulous & Fiendish Merciful Portentous Energized Game

5 15

[PATCH] Simplify v4l.c: remove unnecessary ret variable
by stefano.sabatini-lala＠poste.it 07 Dec '08

07 Dec '08

Hi, as in subject, regards. -- FFmpeg = Fiendish and Frenzy Meaningless Purposeless Extended Glue

2 2