[FFmpeg-devel] [PATCH] RealMedia muxer: support audio codecs other than AC-3

[Michael Niedermayer]

On Mon, May 03, 2010 at 03:47:12PM +0100, M?ns Rullg?rd wrote:
> "Ronald S. Bultje" <rsbultje at gmail.com> writes:
> 
> >> i think stream copy of codecs which we dont support should work.
> >> for that though we must accept "unknown" codec tags without codec id
> 
> There is no reason whatsoever to believe that codec_tag from an
> unknown codec/container will be at all meaningful in the target
> container.
> 
> >> an actual example where someone wanted it and i fixed it was nellymoser
> >> in flv before we had nelly support
> 
> And how did you fix that?  FLV uses completely different codec
> identifiers, so blindly copying the AVI tag could not have worked.

i dont remember but it was about stream copy of nellymoser from flv->flv


> 
> > I'm OK with doing it if codec_id is unset (CODEC_ID_NONE). In any
> > other case, codec_tag should be ignored (imo) and if codec_id is not
> > in our table, we should error out. This way, we force ourselves to add
> > the *correct* tag for each codec_id, rather than taking the AVI fourcc
> > and probably ending up creating files only mplayer can playback.
> 
> +1

this breaks stream copy of old xvid and some mpeg4 variants like XVIX
and ump4
iam thus not in favor of it
what you 2 can do if you like to improve the situation is to implement the
FIXME below from libavformat/utils.c

 if(s->oformat->codec_tag){
    if(st->codec->codec_tag){
        //FIXME
        //check that tag + id is in the table
        //if neither is in the table -> OK
        //if tag is in the table with another id -> FAIL
        //if id is in the table with another tag -> FAIL unless strict < ?
    }else
        st->codec->codec_tag= av_codec_get_tag(s->oformat->codec_tag, st->codec->codec_id);
}

I understand you want to fail in a broader set of cases and iam not
even saying iam neccessarily against that but i think we first should
implement the cases we agree about. Once thats done we can discuss
the remaining cases



[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100503/b908ce7a/attachment.pgp>