MPEG-TS private streams are not labeled as AVMEDIA_TYPE_DATA

[wolfgang]

When decoding an MPEG-TS file, private streams in this file are not recognized as data streams.

• After calling avformat_open_input(), the stream type of the private stream is AVMEDIA_UNKNOWN and the codec id is AV_CODEC_ID_NONE.
• After further calling avformat_find_stream_info() the stream type and codec id change to whatever fits best.

This becomes a problem, if there is neither audio- nor video data within the stream but rather some private data.

[wolfgang]

Some sample code, demonstrating the problem can be found here:
​https://lists.ffmpeg.org/pipermail/libav-user/2014-September/007475.html

A patch addressing this problem, was send to the ffmpeg-devel mailing list:
​https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-May/173594.html
This patch, though cleanly fixing the original problem, as the avformat_open_input() now delivers codec type AVMEDIA_TYPE_DATA and codec id AV_CODEC_ID_BIN_DATA, breaks the fate test acodec-s302m. I opened this ticket, because I don't know how to address this. But I'm willing to help, if someone pushes me into the right direction.

[wolfgang]

As far as I understand it, "SMPTE 302m" embeds some kind of non-MPEG-codec into the MPEG-TS, using a private stream. So the problem occurs, as soon as the avformat_find_stream_info() finds, that the stream already has some codec id assigned.

Would it be a valid course of action, if the ffmpeg command line tool reassigned all private streams (AVMEDIA_TYPE_DATA, AV_CODEC_ID_BIN_DATA) to be of unknown content (AVMEDIA_TYPE_UNKNOWN, AV_CODEC_ID_NONE), and reset the AVStream::request_probe value, to indicate, that the stream should be tested for a usable codec?

That way, users of libavformat would be dignified with correct stream identification for MPEG-TS and users of the ffmpeg tool could still use their "SMPTE 302m" files.

[wolfgang]

This has been resolved in git-master: d59a033a69c4856c664b546a7e2905f733dfb544