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

[Carl Eugen Hoyos]

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.)

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

> 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?

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

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

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

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

This does not sound like a useful argument 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.

> 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?

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

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

Compared to you?

Carl Eugen