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

Michael Niedermayer michaelni at gmx.at
Thu Jun 4 03:18:20 CEST 2015

On Sun, May 31, 2015 at 06:35:18PM +0200, Wolfgang Lorenz wrote:
> 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?

Do i understand correctly that you put data in a mpegts file and
you leave absolutely no way to identify this data except that its
a private stream ?

I think its a very bad idea not to add some reliable method to
identify your data.

Also the S302 in fate is identified by a registration descriptor
there should be nothing unreliable in its detection

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150604/89192c70/attachment.asc>

More information about the ffmpeg-devel mailing list