[FFmpeg-devel] [PATCH]lavf/mov: Export vendor metadata

wm4 nfxjfg at googlemail.com
Fri Jan 27 12:55:02 EET 2017


On Fri, 27 Jan 2017 11:21:08 +0100
Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:

> 2017-01-27 10:42 GMT+01:00 wm4 <nfxjfg at googlemail.com>:
> > On Fri, 27 Jan 2017 10:38:23 +0100
> > Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> >  
> >> 2017-01-27 10:29 GMT+01:00 wm4 <nfxjfg at googlemail.com>:  
> >> > On Fri, 27 Jan 2017 10:19:32 +0100
> >> > Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> >> >  
> >> >> 2017-01-27 10:09 GMT+01:00 wm4 <nfxjfg at googlemail.com>:  
> >> >> > On Fri, 27 Jan 2017 09:39:03 +0100
> >> >> > Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> >> >> >  
> >> >> >> 2017-01-27 9:17 GMT+01:00 wm4 <nfxjfg at googlemail.com>:
> >> >> >>  
> >> >> >> > You're completely misunderstanding.  
> >> >> >>
> >> >> >> Would you mind to elaborate?  
> >> >> >
> >> >> > FFmpeg shouldn't mux codec-specific tags into a different
> >> >> > container.  
> >> >>
> >> >> This is not codec-specific, at least not in the sense that
> >> >> would make a difference for other containers.
> >> >>  
> >> >> > Your ffmpeg.c patch works for transcoding only, not remuxing.  
> >> >>
> >> >> That's because it makes sense to remux "vendor" metadata.  
> >> >
> >> > No, technical metadata that is "hidden" is different from user-visible
> >> > tags that contain non-technical information about the media.  
> >>
> >> This is non-technical information that should be user-visible.  
> >
> > The vendor tag in your fate change has the value "appl". How should
> > that be user-visible?  
> 
> You mean the information is encoded in such a difficult manner
> that no user will be able to decipher it?

That too. It's essentially a FourCC. Most people don't know what to do
with FourCC. It's something for developers or otherwise technically
inclined people.

While this strengthens my argument, it's not really the main point.

> I really wish you were a little more serious when trying to slow down
> FFmpeg development.

Please refrain from personal attacks. I'm not trying to slow down
development, I'm trying to improve the general quality of FFmpeg. In
fact, that's the main point of patch reviews: point out weak spots,
request improvements, and so on.

In this specific case, you're exporting a technical details as
user tags. This is a practice that should stop. Also, writing
essentially random garbage as tags or writing it to files in a manner
that doesn't make sense is not what I associate with quality. What
sense does it make to write a stringified FourCC as user-tag to, say,
a mkv file?

Last but not least, it's questionable whether this is a meaningful
feature at all. Why not use a tool that's more suited for the job, like
a mp4-specific file dumper? (Why did you not do the same for audio?)

To put this into perspective, mediainfo -f doesn't seem to export this
value.

> > You can't seriously tell me that this should show
> > up in a non-technical UI view.  
> 
> Since you are blocking much more important patches, I should
> probably not spend so much time discussing this one. But the
> fact that I needed this patch for debugging and that I found  out
> afterwards that other developers need it too sufficiently indicates
> to me showing, exporting and remuxing the vendor tag makes sense.

For debugging you probably want to use a tool like boxdumper. FFmpeg
can't and won't be able to do "everything" a more suited tool can do,
because it's simply out of scope, and would flood us with thousands of
normally useless details.

I'm also sad to see that you consider discussing patches an annoyance.

Besides, aren't you one of the main offenders when it comes to
stubbornly blocking certain changes?


More information about the ffmpeg-devel mailing list