[vlc-devel] Invalid DTS in RTSP stream (Axis camera)
remi at remlab.net
Mon Oct 9 22:14:19 CEST 2017
Le maanantaina 9. lokakuuta 2017, 16.04.50 EEST Jeremy Vignelles a écrit :
> After digging into the code, I found that DTS = 0 all the time, which causes
> that hang. That invalid DTS is set by this piece of code:
> /*FIXME: for h264 you should check that packetization-mode=1 in sdp-file
> */ switch( tk->fmt.i_codec )
> case VLC_CODEC_MPGV:
> case VLC_CODEC_H264:
> case VLC_CODEC_HEVC:
> case VLC_CODEC_VP8:
> p_block->i_dts = VLC_TS_INVALID;
> p_block->i_dts = VLC_TS_0 + i_pts;
> Commenting out `VLC_CODEC_H264` does what I want.
The standard RTP packetization format for AVC does not carry DTS's, only the
PTS's. The code seems correct to me.
> This code has been introduced in may (fcb7347 by fcartegnie), and I'm sure
> it's there for a good reason. Could you tell me why? How can I fix my
> I have then been distracted by the `FIXME` comment above. The original
> commit said:
> it seems that most of h264 streams are
> with packetization-mode=1 eg. in decoding order (thou it should be
> checked here, and FIXME is for that).
AFAIK, the RTP sequence number MUST follow decoding order, while the RTP
timestamp field MUST represent the presentation time. So again, this comment
seems (mostly) correct.
> Should we keep that assumption or should we replace that, and check for that
> at initialization?
> `b_packetized` is set to false. What's its purpose? Should we set this to
> `true` if `packetization-mode == 1` ?
AFAIK, the b_packetized cannot depend on the packetization mode. Depending on
the convention followed by the packetizer module, it should either be always
true or always false.
So that does *not* seem correct, but I am not sure I understand your
> Last question:
> tk->fmt.p_extra is set but never seems to be used, at least not by the
> access_demux. What is it used for?
It conveys the out-of-band parameter sets from the SDP to the packetizer and
More information about the vlc-devel