Opened 9 years ago
Closed 9 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:2 by , 9 years ago
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 by , 9 years ago
Summary: | MPEG-TS private streams are not labeled as AVMEDIA_DATA → MPEG-TS private streams are not labeled as AVMEDIA_TYPE_DATA |
---|
comment:4 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → 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.