Jean-Baptiste Kempf: > ffprobe is not a video/audio format. > It has no public specification, is made up and completely arbitrary > format. > It will not be used by the large majority of applications.
Indeed. The same goes for a lot of obscure formats used to decode game cutscene data. At least, with ffprobe, we did not have to reverse-engineer the format. > I understand very well the need, Thanks. > I disagree it should go inside the > (de)muxing library. Why? Is it just a matter of taste for you, or do you see practical drawbacks? James Almer: > Afaics, the cons argumented were that this "demuxer" doesn't fit the > criteria of a libavformat module. I do not know the criteria of a libavformat module. Can you enlighten me? > It's not demultiplexing a multimedia > file. Uh? I think this is exactly what all demuxers do. They can not do anything else. > It, unless i misread it, is just reconstructing one out of a non-binary > dump. The "dump" is a file, it contains multimedia data: it is a multimedia file. > This should be implemented as a separate tool using libavformat, and > not as a libavformat module. It could be done. But, once again: why? Is it just a matter of taste for you, or do you see practical drawbacks? Making a tool to build a real file from the text dump allows to get the feature without intruding lavf, that is true. But it would require exactly the same amount of code to parse the dump, plus the code to mux the file: more code, more maintenance. Plus, in terms of debugging, it adds three extra points of failure: the muxer for the intermediate format (used in the conversion tool), the demuxer for the intermediate format (used in ffmpeg.c) and the limitations of the intermediate format itself. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
