[FFmpeg-devel] [PATCH] [RFC] avformat/options_table: do not merge sidedata by default
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Thu Nov 21 00:39:12 CET 2013
On Wed, Nov 20, 2013 at 11:41:40PM +0100, Hendrik Leppkes wrote:
> On Wed, Nov 20, 2013 at 8:25 PM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> >> I'd say libavcodec shouldn't attempt to split side data by default
> >> either. A flag should be added for it, and it should be off by default.
> >> Applications which for some reason don't want to pass along side data
> >> (MPlayer?) can enable this hack explicitly.
> >
> > Without this feature you cannot remux certain files into e.g. AVI or other containers without support for sidedata correctly (for some values of correct I admit).
>
> This is just terrible, in fact, its one of the worst things i've read
> here for a while.
Maybe that should be a hint that what you read is not fully what I meant :-P
> If a codec needs out-of-band data, and the container does not support
> it, those two should simply not go together, and FFmpeg should not
> allow their creation.
>
> We complain all the time when a commercial software invents a new hack
> to store a random codec into a container format that it was not
> designed for, and invent new proprietary ways to screw with data.
> And you want FFmpeg to do the same? For shame.
>
> Muxers should produce compliant files, or not produce them at all.
> Anything else is just plain and simple, wrong.
I think you completely missed my point.
Refusing to mux > muxing non-standard, but FFmpeg-playable files >
muxing broken stuff without a warning or any other hint and depending
on features of the input file the user cannot see
You complain about the first one, and I did in fact say that we
should be moving there (when I was talking about the muxers knowing
what they absolutely cannot discard), but I did also say that
I very much don't think moving to the last one is not an improvement.
Overall it was just part of my argument that all this is just putting
lipstick on a pig so far from my POV.
More information about the ffmpeg-devel
mailing list