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

[wm4]

On Mon, 25 Nov 2013 19:39:59 +0100
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> > I fully agree. So where's the valid use for "merged" side data, other
> > than applications that work only on FFmpeg and not on Libav and thus
> > are not packaged by some major distros?
> 
> I didn't think it through so I was wrong about a few things, but first:
> You did understand my point that "refusing to mux" is exactly _not_ what FFmpeg/lavf does (the side data merging doesn't change anything in that regard)?

You mean ffmpeg generally happily muxes broken files? I think this
should be avoided as far as possible.

> And since we have no API that would provide the information necessary to do this, I am actually certain that no application using FFmpeg does this.
> However what I missed is that even with side data merging FFmpeg itself will still silently drop (possibly critical) side data, so this change neither helps nor hurts there. So I think I withdraw my objections, as long as it is still possible to enable.
> I'd also point out though that files created with embedded merged metadata most likely will be playable just fine in most players/cases (and not just lavf/lavc!): most decoders are good enough at error resilience to just throw away any additional nonsense data.

Maybe so, otherwise this it would have had to be fixed in some way. I
still think appending random data to packets potentially passed to
decoders is not really proper. So like or dislike side data, but
keeping it separate is still better.

And there's still the case that libavcodec could split side data from a
raw data packet (because it happens to have a side data footer that
wasn't added by libavformat). You could argue that this is normally not
a problem, because the probability that this happens by accident is
very low, and even specially prepared files wouldn't be a security
issue. But it certainly creates potential for annoyances. Be it only to
demonstrate that you can create files that play with Libav but not
FFmpeg (which would be a fun thing to do, unfortunately I'm too lazy),
or worse, as a way to explore new attack vectors for security holes in
side data parsing.