Honor PIDs after proxying MPEG-TS source

[Canta]

Which version are you using?

latest

Which operating system are you using?

Linux amd64 standard

Describe how to replicate the issue

1. start the server with configs like this

paths:
  stream:
    source: udp://127.0.0.1:50176

2. publish a mpegts stream to that URL with custom PIDs, like this one:

# ffprobe 'udp://127.0.0.1:50176'
(...)
Input #0, mpegts, from 'udp://127.0.0.1:50176':
  Duration: N/A, start: 695.000000, bitrate: N/A
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
  Stream #0:0[0x31]: Video: h264 ([27][0][0][0] / 0x001B), none, 29.97 fps, 29.97 tbr, 90k tbn
  Stream #0:1[0x33]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 384 kb/s
  Stream #0:2[0x34]: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s

3. read your path, like this:

Input #0, rtsp, from 'rtsp://127.0.0.1:10176/stream':
  Metadata:
    title           :  
  Duration: N/A, start: -0.022400, bitrate: N/A
  Stream #0:0: Video: h264 (Constrained Baseline), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn
  Stream #0:1: Audio: ac3, 48000 Hz, stereo, fltp, 384 kb/s
  Stream #0:2: Audio: mp2, 48000 Hz, stereo, fltp, 192 kb/s

It can be seen that the RTSP output from mediamtx does not contain the input's MPEG-TS data, such as PIDs.
This way, consumers of the RTSP can not discern which PES is which one. For example: having an ffmpeg instance looking for i:0x33 PID will fail because it can not be found.
I'm not sure if this is a consequence of using RTSP as output instead of MPEG-TS, or if it's something else the problem.

I would like to consume mediamtx's output honoring its inputs MPEG-TS data. That could be achieved either by stating output PIDs, or using something like MPEG-TS UDP output, both things I did not found a howto in the docs. A way to achieve such output would be a sollution to my problem. But not having any, I consider this to be a bug in input/output handling, unless it's formally stated as some kind of limitation.

In case it's helpful for someone, here's a ffmpeg command to start an input MPEG-TS stream for the mediamtx source such as the one I'm using:

ffmpeg -hide_banner -loglevel fatal -f lavfi -re -i
'testsrc=s=1920x1080:r=30000/1001,format=yuv420p'
-f lavfi -re -i
'anullsrc'
-f lavfi -re -i
'anullsrc'
-map 0:v -map 1:a -map 2:a
-c:v h264 -preset ultrafast -r 30000/1001
-c:a:0 ac3 -b:a:0 384k -ac:0 2
-c:a:1 mp2 -b:a:1 192k -ac:1 2
-ar 48k -streamid 0:0x31 -streamid 1:0x33 -streamid 2:0x34
-f mpegts 'udp://127.0.0.1:50176?pkt_size=1316&overrun_nonfatal=1&fifo_size=10000000&buffer_size=10000000'

Thanks.

Server logs

No response

Network dump

No response

[Canta]

I've done an extra test, removing RTSP from the way and using SRT instead.
Here's the mediamtx input, generated with ffmpeg as shown in my previous comment:

Input #0, mpegts, from 'udp://127.0.0.1:60176':
  Duration: N/A, start: 137.240000, bitrate: N/A
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
  Stream #0:0[0x31]: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn
  Stream #0:1[0x33]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 384 kb/s
  Stream #0:2[0x34]: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s

However, this is what I get from mediamtx SRT output:

# ffprobe "srt://127.0.0.1:10176?streamid=read:streams/mystream"
(...)
Input #0, mpegts, from 'srt://127.0.0.1:10176?streamid=read:streams/mystream':
  Duration: N/A, start: 259.899311, bitrate: N/A
  Program 1 
  Stream #0:0[0x100]: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn
  Stream #0:1[0x101]: Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, fltp, 384 kb/s
  Stream #0:2[0x102]: Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 192 kb/s

What can be seen is:

• The input PIDs are not honored in the output.
• The output PIDs seems to be the ffmpeg/libav default PIDs. I don't know if mediamtx uses ffmpeg/libav as part of their code, or if this is some standard behaviour.

I believe this to be some kind of bug. In any case, it's a problem if I need to configure anything reading mediamtx's output looking for MPEG-TS parameters. Can't find any workaround so far using mediamtx.