[FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer

[Michael Niedermayer]

On Mon, Oct 31, 2016 at 02:41:05PM -0300, James Almer wrote:
> On 10/31/2016 1:54 PM, Nicolas George wrote:
> > Le decadi 10 brumaire, an CCXXV, James Almer a écrit :
[...]
> > 
> >> Which so happens to be what every libav* user has to do for their projects.
> >> Write a program using the libraries' public API to read and write files.
> >>
> >> We have plenty of times refused code people wanted to dump into libavformat
> >> and libavcodec because it was the easiest way for them to get what they
> >> needed done. There was this absolutely insane youtube-dl "demuxer" that still
> >> gives me the chills.
> >> We have also plenty of times let things go in, even with several developers
> >> against it. Lets try to not do it again.
> > 
> > This argument mixes a whole lot of different cases together. Each case
> > has its own specifics that should be used to judge whether it should
> > have been accepted or not.
> > 
> > Once again: usefulness and drawbacks.
> > 
> > Having one demuxer of this kind, as powerful as possible, is useful. Do
> > you not agree with that?
> 
> It might, hence why i suggested this being implemented as a standalone tool
> and not that you should drop the whole thing.
> 
> > 
> > (Having several of them would be less useful.)
> > 
> > What are the drawbacks you see?
> 
> You presented an scenario and use case to dump media streams into a text
> file to easily alter them, analyze them and reconstruct them. You then
> declared said dumps to be an actual format so they could qualify for an
> avformat module that could digest them.
> 
> There are no technical drawbacks for this demuxer. This is a concept and
> design issue. It's a very specific need so far a single person or two
> that's being forced into the libraries because it's the easiest way to
> implement it.
> 
> This should be written as a standalone tool that uses lavf API to rebuild
> the custom xml-like dump with the hex formatted packets as created by
> ffprobe. Basically, write ffmpeg's own, more powerful and versatile
> version of oggz-dump that uses lavf instead of libogg, meaning the dumps
> can be created and rebuilt from and into any lavf supported format.

A standalone tool would make some usecases more cumbersome

for example if you are debuging a video player which uses libavformat
and libavcodec.
You would dump a testcase into the text format by whatever means.
you now could edit this text file by any text editor or grep/sed tools
and then test if a problem still occurs to "bisect" down to the spot
in the file causing it to create a small testcase or to debug and
fix it.

The difference is with a demuxer you can directly play the text file
seek in it possibly do any test you need to.
with a standalone tool you first need to convert the text file back
into a standard media file.
The additional step may be slow if the file is large,
It may be difficult or impossibly to do if the case one wants to test
is not supported by the syntax of any binary format or one does not
know which binary format supports the combination of features one wants
to test. 

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161031/d5783592/attachment.sig>