Ronald S. Bultje <rsbultje <at> gmail.com> writes: > On Sun, Sep 6, 2015 at 8:46 AM, Carl Eugen Hoyos wrote: > > > Ronald S. Bultje <rsbultje <at> gmail.com> writes: > > > > > Are there users that care about this feature? > > > > > Why didn't they complain that it didn't work? > > > > Why do you think it doesn't work? > > "(Just for reference, I tested running avconv's FATE > with FFmpeg's libraries: > a lot of tests fail, without surprise (the libraries > do not behave the same, that is the whole point; and > apparently avconv thinks that EOF is a filtering error), > but quite a few succeed, and I have not seen crashes. > That means the compatibility is pretty good right now.)"
(To repeat: This exactly matches my memory of testing the above and realising that using fate for such a setup would be a large effort.) I have no idea why you believe any of this indicates that the option does not work, I can assure you that the sentence meant "it seems to work as far as a very quick test allows to indicate it". > I want you to imagine for a second that a user downloads > one of these UIs that is essentially ffmpeg.exe or > avconv.exe with some extras, and tries to use it, and > sees a user-equivalent of the above. (I have no idea how the option would be useful for a Windows user, but this is certainly unrelated. Imo, the option only makes sense for users of distributions shipping vlc and friends using avconv's libraries.) > Media files don't load, colors display incorrectly, you Why would this happen? Do you have an example? (vlc doesn't load - at least some - RGB0 files because they don't support it but I guess this isn't what you mean, or is it?) > keep getting error dialogs telling you that something > has gone wrong, with specifics that nobody really > understands, with "unknown error" or "invalid argument" > in the "details" section. The about box says that this > software uses FFmpeg version a.b.c with libavcodec x.y.z. I don't really understand this but note that I consider it *very* difficult to find out what vlc uses because the message you write about does not exist. (I had to find out from time to time because of Microsoft crash reports.) > To be fair, it might not crash, and from a technical > perspective, maybe compatibility _is_ actually not > terrible, depending on how you measure it. > But it doesn't work from a user perspective. An Ubuntu 14.4 user plays a media file with vlc and it shows artefacts / doesn't show anything / is silent / plays with audible artefacts. He tries with system FFplay and it works fine. He installs dmo (maybe not the correct way but he succeeds in exchanging lavc), tries again with vlc and it crashes. (The last step is important to understand what "does not work" can mean in this context.) He then compiles FFmpeg himself with the compatibility option, replaces lavc with the newly compiled version and vlc (does not crash and) plays the original file correctly. Please understand that just because nobody wanted to invest time in creating (and testing) a specific set of fate references there is no automatic indication that anything is broken. I believe you wrote earlier that "since nobody reported a bug it is probably not used". This is obviously not formally correct but I agree. You now claim that "since nobody reported a bug it must be broken". This is neither formally correct nor - as such - true. Now please somebody fix the commit message and add a line to the Changelog so this completely unneeded discussion ends. Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
