[FFmpeg-trac] #8465(avcodec:new): avformat_find_stream_info does not fill MPEG2-TS/HEVC resolution with HEVC decoder disabled
FFmpeg
trac at avcodec.org
Mon Jan 13 11:54:48 EET 2020
#8465: avformat_find_stream_info does not fill MPEG2-TS/HEVC resolution with HEVC
decoder disabled
-------------------------------------+-----------------------------------
Reporter: ddyndo | Owner:
Type: enhancement | Status: new
Priority: wish | Component: avcodec
Version: git-master | Resolution:
Keywords: hevc | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-----------------------------------
Changes (by ddyndo):
* cc: ddyndo@… (added)
Comment:
Hi @cehoyos,
Thanks for the answer. Could you explain two things:
1. Why is this considered "intended behavior"? For me, it seems that
demuxers and parsers should be enough to parse high-level metadata such as
color-related metadata and stream resolution just from the parsers.
Furthermore, this information *is* already parsed, just not passed higher
(if not present from the other sources). Lastly, it is possibly a
performance degradation to require to decode samples just to get
information during the `avformat_find_stream_info()` call (when you don't
really need to decode anything, the information is just there for
"parsing").
2. What would be the intended way to get such metadata (having just
demuxers and parsers) then?
----
What is even stranged and makes it totally non-consistent is that when I
disable H264/AVC decoder (and leave only demuxer and parser) I get
perfectly well metadata from `avformat_find_stream_info()`. This can be
observed for example on this stream
(http://www.avalpa.com/assets/video/OC3.demo.ts) (randomly found on the
internet) where it correctly gives me metadata for H264 tracks like:
{{{
Stream 7: Video: h264 (High), 1 reference frame ([27][0][0][0] / 0x001B),
none(progressive), 720x576 (0x0)
Stream 8: Video: h264 (High), 1 reference frame ([27][0][0][0] / 0x001B),
none(progressive), 1920x1080 (0x0)
}}}
and the color-related metadata are also correctly filled (although not
printed in this log here). As such this really looks like a bug/lack of
implementation from my point of view.
Best regards,
Damian Dyńdo.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/8465#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list