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

[Wolfgang Lorenz]

Am Thu, 4 Jun 2015 03:18:20 +0200
schrieb Michael Niedermayer <michaelni at gmx.at>:

> 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.

You are right, there. Ich should at least add some magic number to each
packet, and I will. This wouldn't solve my original problem though.

> Also the S302 in fate is identified by a registration descriptor
> there should be nothing unreliable in its detection
> 
> 
> [...]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150604/28d75313/attachment.asc>