[FFmpeg-devel] [PATCH] * mpegts demuxer should recognize private streams

[Wolfgang Lorenz]

Am Sat, 30 May 2015 12:58:38 +0200
schrieb Hendrik Leppkes <h.leppkes at gmail.com>:

> On Sat, May 30, 2015 at 12:39 PM, Wolfgang Lorenz <wl-chmw at gmx.de> wrote:
> > Am Sat, 30 May 2015 11:00:18 +0200
> > schrieb Wolfgang Lorenz <wl-chmw at gmx.de>:
> >
> > [...]
> >
> > Okay. Now I get the same errors Michael had, after the first version of
> > the patch, but with the second version:
> >
> > Test aac-latm_000000001180bc60 failed. Look at tests/data/fate/aac-latm_000000001180bc60.err for details.
> > make: *** [fate-aac-latm_000000001180bc60] Error 1
> > make: *** Waiting for unfinished jobs....
> > Test aac-latm_stereo_to_51 failed. Look at tests/data/fate/aac-latm_stereo_to_51.err for details.
> > make: *** [fate-aac-latm_stereo_to_51] Error 1

Okay, that was due to some old library versions, that were still
lingering in my LD_LIBRARY_PATH.

Now, also acodec-s302m fails.

> You should check out the .err files it mentions and actually see what
> its complaining about.

That didn't help much. There doesn't seem to be much information
available, but as I understand it s302m is some kind of codec defined
by SMPTE, that writes PCM data into a private stream of an MPEG-TS.

Without the patch the stream is identified as an AVMEDIA_UNKNOWN and
AV_CODEC_NONE by mpegts.c. Later the missing codec leads to probing the
stream for a codec id. The type is set to AVMEDIA_AUDIO and the codec
id is set accordingly. All is well.

With the patch the stream is identified as AVMEDIA_DATA and
AV_CODEC_ID_BIN_DATA. In this case ffmpeg doesn't find any audio data
to transcode and the fate test fails.

This may be too bold, but I think the acodec-s302m test is broken. I
think, that trying to decode private data is a bad idea. There's no way
to see whether the chosen coder is the correct one. In my case FFMPEG
thought AAC might be a good choice to decode random data.

I'm not sure, what can be done about this, though. Just applying the
patch, since the standard says so, might break other people's code.
Maybe it is possible to implement a function, that changes the codec
of a stream after probing for one that works. This could then be used
by someone who knows what to expect in a private stream. Also, this
would break other people's code. A third idea is to add a flag to each
stream, that states whether FFPEG should still probe the stream, even if
it is defined as a data stream. If this flag is set to true by default,
this would not break other people's code. I've been trying to implement
something like this for the last couple of hours, but it just doesn't
work. :-( Well, I just don't know the internals of FFMPEG well enough.

I guess the best I can do now, is to open a bug report describing my
problem. What do you think?

Greetings,
  Wolfgang