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

[Michael Niedermayer]

On Mon, Oct 31, 2016 at 07:22:58PM +0100, Michael Niedermayer wrote:
> 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. 

Another case where a standalone tool would have a problem is the
case where we dont have a muxer.

To show a specific example:
Consider a bethsoftvid file, converting it to "text" and editing it
one is stuck as we have no muxer for bethsoftvid and the video codec
in it is not supported by any other muxer



[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/95d6f9c7/attachment.sig>