Giters

bluenviron / mediamtx

Ready-to-use SRT / WebRTC / RTSP / RTMP / LL-HLS media server and media proxy that allows to read, publish, proxy, record and playback video and audio streams.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

read SRT not work with interlaced video

calanor opened this issue · comments

commented

Which version are you using?

v1.6.0

Which operating system are you using?

  • [x ] 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

I am testing mediamtx to use as a SRT relay.
If I use a progressive h.264 video it works fine and the srt clients correctly receive the video and audios.
But if I send an interlaced video, the SRT clients cannot decode the video stream. The same happens if it is published with rtsp, rtmp or udp and the source is interlaced, it cannot be decoded with srt clients. RTSP clients correctly read the same interleaved streams.

Describe how to replicate the issue

  1. start the server
  2. publish with srt-live-transmit <udp h264 mpgts source> srt://localhost:10099?streamid=publish:mystream&pkt_size=1316
  3. read with ffprobe srt://xxxxxxxx.xx:10099?streamid=read:mystream

Did you attach the server logs?

yes

ffprobe receibed by SRT client with progressive video (work fine):

Input #0, mpegts, from 'srt://xxxxxxxx.xx:10099?streamid=read:mystream':
  Duration: N/A, start: 17.877322, bitrate: N/A
  Program 1
  Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn
  Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 128 kb/s
  Stream #0:2[0x102]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 128 kb/s

ffprobe received by SRT client with interlaced video fails (observe the "none" in codec descritption):

Input #0, mpegts, from 'srt://xxxxxxxx.xx:10099?streamid=read:mystream':
  Duration: N/A, start: 657.450656, bitrate: 256 kb/s
  Program 1
  Stream #0:0[0x100]: Video: h264 ([27][0][0][0] / 0x001B), none, 90k tbr, 90k tbn
  Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 128 kb/s
  Stream #0:2[0x102]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 127 kb/s

ffprobe received by RTSP client with the same interlaced video works fine:

Input #0, rtsp, from 'rtsp://xxxxxxxx.xxx:8554/mystream':
  Metadata:
    title           :
  Duration: N/A, start: -0.080000, bitrate: N/A
  Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, top first), 1920x1080, 25 fps, 25 tbr, 90k tbn
  Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp
  Stream #0:2: Audio: aac (LC), 48000 Hz, stereo, fltp

Did you attach a network dump?

no

commented

Aditional info.
I copy part of the mediamtx log where receive an SRT with interlaced video while connect a srt request wit commandline:

srt-live-transmit -s 1000 'srt://localhost:10099?streamid=#!::m=request,r=mystream' udp://@239.1.1.1:1234

The connection its closed by package mediacommon/blob/main/pkg/codecs/h264/dts_extractor.go and reconnect by srt-live-transmit continuously.

2024/04/19 15:30:07 INF [SRT] [conn xx.xxx.xxx.xx:57299] opened
2024/04/19 15:30:07 INF [SRT] [conn xx.xxx.xxx.xx:57299] is reading from path 'mystream', 3 tracks (H264, MPEG-4 Audio, MPEG-4 Audio)
2024/04/19 15:30:07 INF [SRT] [conn xx.xxx.xxx.xx:57299] closed: DTS is not monotonically increasing, was 16.16s, now is 16.08s
2024/04/19 15:30:07 INF [SRT] [conn xx.xxx.xxx.xx:53672] opened
2024/04/19 15:30:07 INF [SRT] [conn xx.xxx.xxx.xx:53672] is reading from path 'mystream', 3 tracks (H264, MPEG-4 Audio, MPEG-4 Audio)
2024/04/19 15:30:09 INF [SRT] [conn xx.xxx.xxx.xx:53672] closed: DTS is not monotonically increasing, was 18.16s, now is 18.08s
2024/04/19 15:30:09 INF [SRT] [conn xx.xxx.xxx.xx:60571] opened
2024/04/19 15:30:09 INF [SRT] [conn xx.xxx.xxx.xx:60571] is reading from path 'mystream', 3 tracks (H264, MPEG-4 Audio, MPEG-4 Audio)

If I use an RTSP reader there are no errors in the mediamtx log, ffmpeg correctly detects the format (size, pix_fmt, field_order,...), mediamtx not closes the connection but some DTS errors appear in the ffmpeg log.

ffmpeg -i rtsp://localhost:8554/mystream -c copy -f null /dev/null

Input #0, rtsp, from 'rtsp://localhost:8554/mystream':
  Metadata:
    title           :  
  Duration: N/A, start: 0.000000, bitrate: N/A
  Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, top first), 1920x1080, 25 fps, 25 tbr, 90k tbn
  Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp
  Stream #0:2: Audio: aac (LC), 48000 Hz, stereo, fltp
Output #0, null, to '/dev/null':
  Metadata:
    title           :  
    encoder         : Lavf59.34.102
  Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, top first), 1920x1080, q=2-31, 25 fps, 25 tbr, 90k tbn
  Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[null @ 0x5594e8e3ef00] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 481279 >= 480254
[null @ 0x5594e8e3ef00] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 481279 >= 481278
[null @ 0x5594e8e3ef00] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1802225 >= 1802207
[null @ 0x5594e8e3ef00] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1816625 >= 1816607
[null @ 0x5594e8e3ef00] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1444762 >= 1443325
[null @ 0x5594e8e3ef00] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1444762 >= 1444349

With VLC reading RTMP from SRT interlaced input also fails after 1 second of playing.

It seems that all requests for signals ingested with h264 interlaced fails.