[FFmpeg-devel] [PATCH] [RFC] avformat/options_table: do not merge sidedata by default

[Reimar Döffinger]

On Wed, Nov 20, 2013 at 08:43:03PM +0100, wm4 wrote:
> On Wed, 20 Nov 2013 20:25:20 +0100
> 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).
> > So this will change behaviour of ffmpeg in a quite major way, libavformat itself has no way to correctly decide if it is e.g. safe to just discard the side data.
> 
> Uh, what? Wouldn't these AVI files then have ffmpeg specific side data
> inside of the packet data? Sounds 100% broken and non-portable.

As said "for some values of correct". "Files only playable with FFmpeg"
is a huge step up over "you can never know whether the file will
actually be playable".

> > I guess the best I can say is this sidedata thing was a braindead idea from the start, feel free to twiddle with flags (I'll try to remember to just counterfiddle on MPlayer side) but I have some doubts it will do more than annoy people. If you want it to actually work you'll need to invest a lot more time.
> 
> Side data seems like a nice way to communicate parameter changes and
> other out-of-band data to the decoder side. How else would you handle
> parameter changes?

By putting them in-band of course.
Putting data critical for decoding out-of-band, in particular when
there is no standard for doing so and thus "out-of-band" is actually
"oops, it got lost somewhere" is pretty much what I consider braindead.
That it ended up getting used for everything just because it's easy
doesn't make it better.