Opened 4 years ago
Closed 4 years ago
#4588 closed defect (fixed)
MPEG-TS private streams are not labeled as AVMEDIA_TYPE_DATA
Reported by: | wolfgang | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | git-master | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
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.
Change History (4)
comment:1 Changed 4 years ago by wolfgang
comment:2 Changed 4 years ago by 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.
comment:3 Changed 4 years ago by wolfgang
- Summary changed from MPEG-TS private streams are not labeled as AVMEDIA_DATA to MPEG-TS private streams are not labeled as AVMEDIA_TYPE_DATA
comment:4 Changed 4 years ago by wolfgang
- Resolution set to fixed
- Status changed from new to closed
This has been resolved in git-master: d59a033a69c4856c664b546a7e2905f733dfb544
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.