On Fri, 27 Jan 2017 12:35:25 +0100 Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 2017-01-27 11:55 GMT+01:00 wm4 <nfx...@googlemail.com>: > > 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. > > 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
