[vlc-devel] [PATCH 4/9] demux: mkv: fix DTS of outgoing blocks
Rémi Denis-Courmont
remi at remlab.net
Mon Jul 16 19:22:34 CEST 2018
Le maanantaina 16. heinäkuuta 2018, 12.30.07 EEST Francois Cartegnie a écrit :
> Le 16/07/2018 à 11:15, Denis Charmet a écrit :
> DTS = PTS on I-Frame isn't even correct, only B-frames not being
> reference can be considered DTS = PTS in the case of H264.
>
> That does not even work for H265 where I couldn't find any easy way
> without computing the POC...
>
> One dumb algorithm would be:
> - Store the first N frames >= max_num_reorder/DPB
> - On N, find the min PTS
> - use min PTS it as DTS for the first block in decoding order
> - increase PTS for each frame
> but
> - that also requires to handle drift (frame length can differ)
> - there's some streams which are not packetized, so there's no "frames"
> - possibly no pts on some block for the previous reason
>
> We're in the same situation as RTSP where:
> - we need DTS for PCR and correct buffering/timing
> - we can't compute DTS without packetizer's work
Moving the packetizer before the buffering sounds very sensible to me,
actually.
> An that would mean running packetizer before sending to es_out, rising
> new issues with 1 frame delay and low fps.
It only incurs a frame delay if the codec profile allows B-frames *and* the
demuxer does not fill the DTS. That is a perfectly reasonable limitation.
That is actually how video over RT(S)P is supposed to work even:
- use lower low-latency codec or codec profiles for interactive use cases,
- use higher high-latency codec or codec profiles for regular streaming.
--
Реми Дёни-Курмон
http://www.remlab.net/
More information about the vlc-devel
mailing list