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

[wm4]

On Fri, 27 Jan 2017 12:35:25 +0100
Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:

> 2017-01-27 11:55 GMT+01:00 wm4 <nfxjfg at googlemail.com>:
> > 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.  
> 
> I disagree.
> (And so do other developers it seems.)

Which other developers?

> > 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 do not consider this a personal attack: People you seem to respect
> have often requested (publically and in private) that FFmpeg development
> has to slow down - I strongly disagree with them but you have said in the
> past that you agree with them.

Where did they say this? Do you have a link or an example?

> > 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.  
> 
> But that is not how you started this thread, or was it?

Did you?

> And that's apart from the fact that you have threatened contributors
> away in the past.

How many people have you chased away from the bug tracker?

> > 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?  
> 
> I do not understand in which way the vendor tag "doesn't make sense"
> in any container.

See the paragraph you quoted.

Let me ask you again: how does an Apple-specific FourCC make sense in
mkv (except maybe the Qt muxing support)?

> > 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?)  
> 
> I would really, really prefer if all necessary debug information would be
> printed by FFmpeg, not a third-party toold.

Adding user-visible changes "for debugging" is usually a bad argument.

You could output it with an av_log with debug log level if you must.

> > To put this into perspective, mediainfo -f doesn't seem to export this
> > value.  
> 
> This does not sound like a useful argument to me.

It does to me.

> >> > 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.  
> 
> See above.

See above.

> > 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.  
> 
> How is exporting properties of a media file out-of-scope for FFmpeg?

Don't twist my words. I wasn't talking about "exporting properties",
but this specific case.

> > I'm also sad to see that you consider discussing patches an annoyance.  
> 
> I wish you would have commented earlier, the way you did it gave me
> the impression you were only interested in annoying me.

Oh look, a personal attack mixed with plenty of mind-bending bullshit
again.

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

I'm less stubborn than you. Because I give in when I see that I'm
wrong, or if the opposition is too large.