[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