On Fri, 27 Jan 2017 11:21:08 +0100 Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 2017-01-27 10:42 GMT+01:00 wm4 <nfx...@googlemail.com>: > > On Fri, 27 Jan 2017 10:38:23 +0100 > > Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > > >> 2017-01-27 10:29 GMT+01:00 wm4 <nfx...@googlemail.com>: > >> > On Fri, 27 Jan 2017 10:19:32 +0100 > >> > Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > >> > > >> >> 2017-01-27 10:09 GMT+01:00 wm4 <nfx...@googlemail.com>: > >> >> > On Fri, 27 Jan 2017 09:39:03 +0100 > >> >> > Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > >> >> > > >> >> >> 2017-01-27 9:17 GMT+01:00 wm4 <nfx...@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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
