NVC4000 [record] too many reordered frames

[svk23]

Which version are you using?

v1.5.1

Which operating system are you using?

• Linux amd64 standard
• Linux amd64 Docker
• Linux arm64 standard
• Linux arm64 Docker
• Linux arm7 standard
• Linux arm7 Docker
• Linux arm6 standard
• Linux arm6 Docker
• Windows amd64 standard
• Windows amd64 Docker (WSL backend)
• macOS amd64 standard
• macOS amd64 Docker
• Other (please describe)

Describe the issue

Recording RTSP from a NVC4000 H.264 Network Video Encoder to MpegTS does not produce any valid segments. The server repeatedly logs ERR [path test] [record] too many reordered frames and restarts the recording. The server reads the sps and idr units correctly, but the fails on a non idr unit. In the getPictureOrderCount method of dts_extractor.go the following positions are read:

• first_mb_in_slice: 0
• slice_type: 1
• pic_parameter_set_id: 2
• frame_num: 3
• order_cnt: 18

Describe how to replicate the issue

1. configure a recording path with a RTSP uri from a NVC4000 encoder
2. start the server
3. observe path restarting

Did you attach the server logs?

yes

mediamtx.log

Did you attach a network dump?

yes

20240226_NVC4000.pcap.gz

[Build2NU]

Do you think this is the same error I'm running into? I submitted #3091 A few days ago. Its been making doing any kind of production level streams impossible. I'll have to use something else for the next while if it can't be fixed. Other than this one issue, mediamtx has been my all time favorite video streaming engine to use.

[svk23]

It could be. In my case the error occurs almost instantly, whereas your stream seems to be fine for a while (20 minutes?). I'm not familiar enough with H.264 to understand the code used by MediaMTX and estimate if this has the same cause.

[svk23]

As suggested: decoding the stream via ffmpeg.

$ ffmpeg -rtsp_transport tcp  -i rtsp://user:[email protected]/ch0_unicast_firststream -f null -
ffmpeg version 4.2.7-0ubuntu0.1 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 9 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
  configuration: --prefix=/usr --extra-version=0ubuntu0.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-nvenc --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
Input #0, rtsp, from 'rtsp://user:[email protected]/ch0_unicast_firststream':
  Metadata:
    title           : Session of first stream
    comment         : First Codec Stream
  Duration: N/A, start: 0.080000, bitrate: N/A
    Stream #0:0: Video: h264 (Baseline), yuv420p(progressive), 720x576, 25 tbr, 90k tbn, 180k tbc
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
  Metadata:
    title           : Session of first stream
    comment         : First Codec Stream
    encoder         : Lavf58.29.100
    Stream #0:0: Video: wrapped_avframe, yuv420p, 720x576, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
      encoder         : Lavc58.54.100 wrapped_avframe
frame=  418 fps= 10 q=-0.0 Lsize=N/A time=00:00:41.56 bitrate=N/A speed=1.03x
video:219kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Exiting normally, received signal 2.

[aler9]

Hello, the network dump you provided is not enough to replicate the bug since it contains exchanged data between your NVR and FFmpeg, not between your NVR and the server. When the network dump is inserted into a camera simulator, the simulator gets stuck with an unrelated error.

Please provide a network dump that contains exchanged data between the server and the NVR, from the moment the server is started to the moment the error occurs, as mentioned in the issue instructions.

[Build2NU]

Hello, the network dump you provided is not enough to replicate the bug since it contains exchanged data between your NVR and FFmpeg, not between your NVR and the server. When the network dump is inserted into a camera simulator, the simulator gets stuck with an unrelated error.

Please provide a network dump that contains exchanged data between the server and the NVR, from the moment the server is started to the moment the error occurs, as mentioned in the issue instructions.

Hey there, I've also been having this issue as I reported in #3091 when reading an SRT stream using vMix.

I'd be willing to go get a network dump of this error happening as it is very easy to replicate.

Do you need the network dump from the server perspective? Or from the client perspective? Or both.

[aler9]

@Build2NU your issue is unrelated from this and happens under different circumstances. Instructions on how to generate network dumps are present in the issue template.

[svk23]

Hello, the network dump you provided is not enough to replicate the bug since it contains exchanged data between your NVR and FFmpeg, not between your NVR and the server. When the network dump is inserted into a camera simulator, the simulator gets stuck with an unrelated error.

Please provide a network dump that contains exchanged data between the server and the NVR, from the moment the server is started to the moment the error occurs, as mentioned in the issue instructions.

Weird, I must have attached the wrong files by accident. Here's a fresh dump and the corresponding log. Please note that this is version 1.8.3 of mediamtx and no longer 1.5.1.

20240624_NVC4000.pcap.gz

mediamtx.log

[MengLi619]

Face the same problem, the recording stopped after the RTSP packet lost

MediaMTX 1.5.1

[aler9]

@svk23 thanks for providing the network dump, what i noticed from your stream is that IDR frames have a pic_order_cnt that is not zero, while the server assume they have. I removed the assumption here: bluenviron/mediacommon@e55da57

Please try this nightly release and let me know if it fixes the issue:
https://github.com/bluenviron/mediamtx/actions/runs/9735086910

[svk23]

Please try this nightly release and let me know if it fixes the issue: https://github.com/bluenviron/mediamtx/actions/runs/9735086910

@aler9 I did a go get github.com/bluenviron/mediacommon@e55da57278f3f1bade0bdf89fafcf3a02a1774a4 in my Mediamtx checkout and ran the server against the NVC4000 encoder. It been running (like a dream) for a couple of minutes without producing a single error about reordered frames. I say that fixed the issue. Thanks! :-D

[aler9]

@svk23 that's wonderful, just one thing before merging - i noticed that recordings of the network dump you provided were blank - are you able to verify whether recordings of the NVC4000 can be read correctly?

[svk23]

@aler9 True, I didn't connect any camera's during the creation of the dump, so the recording was of blank video. During the most recent test I did attach a camera and the resulting segments showed the video as expected and could be played back with ffmpeg and vlc.