Open calanor opened 2 months ago
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.
Which version are you using?
v1.6.0
Which operating system are you using?
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
srt-live-transmit <udp h264 mpgts source> srt://localhost:10099?streamid=publish:mystream&pkt_size=1316
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):
ffprobe received by SRT client with interlaced video fails (observe the "none" in codec descritption):
ffprobe received by RTSP client with the same interlaced video works fine:
Did you attach a network dump?
no