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

[Jeremy Vignelles]

Hi,

I have a video camera that I'd like to record using the following command line:

   ./vlc -vv --rtsp-tcp --sout="#std{access=file,mux=ts,dst=/home/user/Desktop/rec.ts}" rtsp://192.168.0.3/axis-media/media.amp

However VLC is stuck in an infinite loop and even after closing the window, it doesn't stops.

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.

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).

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` ?

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?