[vlc-devel] Invalid DTS in RTSP stream (Axis camera)

[Jeremy Vignelles]

Hi,
Thanks for your answer.

If I understand correctly, setting DTS to VLC_TS_INVALID is intentional and says "Hey, the source didn't gave me the DTS!".

That's fine, but there is another assumption in src/stream_output/stream_output.c in function sout_MuxSendBuffer:

        if( p_mux->i_add_stream_start < 0 )
            p_mux->i_add_stream_start = i_dts;

Here, i_add_stream_start = 0

        /* Wait until we have enough data before muxing */
        if( p_mux->i_add_stream_start < 0 ||
            i_dts < p_mux->i_add_stream_start + i_caching )
            return VLC_SUCCESS;

This condition is always met since i_dts = 0, i_add_stream_start = 0 and i_caching is > 0.

We never have enough data to start streaming, and my file doesn't grow.

When trying to stop VLC (ctrl+c or by closing the window). The file starts to grow incredibly fast (several megabytes per seconds), and I need to kill the process before the file takes all the space left on my device. Of course, the file generated cannot be played.

How could this be fixed? Should access_demux be modified to introduce a fake DTS, should stream_output be changed to accept 0 dts or should the packetizer modify the DTS?

> Le 9 octobre 2017 à 22:14, Rémi Denis-Courmont <remi at remlab.net> a écrit :
> 
> 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;
> >  break;
> >  default:
> >  p_block->i_dts = VLC_TS_0 + i_pts;
> >  break;
> >  }
> > 
> > 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
> > issue?
> > 
> > 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?
> > 
> > sub->attrVal_bool("packetization-mode")
> > 
> > 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
> statement.
> 
> > 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
> decoder.
> 
> --
> 雷米‧德尼-库尔蒙
> https://www.remlab.net/