Publish by MPEG-TS over UDP to SRS. about srs HOT 12 CLOSED

MPEG-TS over UDP push to local machine.
Configuration
srs2.0

listen              1690;
max_connections     1000;
stream_caster {
    enabled         on;
    caster          mpegts_over_udp;
    output          rtmp://127.0.0.1/live/livestream;
    listen          1935;
}
vhost __defaultVhost__ {
}

When playing the above configuration of SRS on the local PotPlayer, you will find that the content is all distorted, and only occasionally can you see one or two recognizable frames of the image.

If I use another encoder to encode and stream separately with the command "-vcodec copy", it works normally without any distortion.

It seems to be a problem with this feature of SRS. I hope it can be fixed.

TRANS_BY_GPT3

from srs.

Where is the log? Can you record a TS segment?

TRANS_BY_GPT3

from srs.

I would like to ask: Currently, I am able to push H.264 streams to SRS using ffmpeg. However, I want to directly receive UDP streams using SRS, for example, udp://238.1.1.1:1234. The problem I have now is, how can I run the SRS command to make SRS receive udp://238.1.1.1:1234 and convert it to rtmp://localhost/live/livestream/238-1-1-1-1234?

TRANS_BY_GPT3

from srs.

Previously, I used the command to run SRS directly, listening on port 1234, and I was able to receive the stream. But this process can only run one at a time! What should I do if I have dozens of streams?

TRANS_BY_GPT3

from srs.

An process can open multiple stream casters.

TRANS_BY_GPT3

from srs.

I'm really sorry, but I don't have enough understanding. How should I write "一个进程可以开多个stream caster" in the conf file?
Additionally, in one of my use cases, the content of my stream will change. For example, the output to SRS is 238.1.1.1:1234, and my input source ProgramID, VIDEO\AUDIO PID will change. Currently, what I see in SRS is that when my stream content changes, SRS exits unexpectedly.

TRANS_BY_GPT3

from srs.

Hello, I encountered this problem when using the MPEG-TS over UDP feature in SRS 2.0.
[2019-04-16 15:50:02.374][warn][3136][102][11] mpegts: ignore parse ts packet failed. ret=4013
[2019-04-16 15:50:02.374][error][3136][102][11] ts: sync_bytes must be 0x47, actual=0x18. ret=4013(Resource temporarily unavailable)
[2019-04-16 15:50:02.374][error][3136][102][11] mpegts: decode ts packet failed. ret=4013(Resource temporarily unavailable)
My settings are:
listen 1935;
max_connections 1000;
daemon off;
srs_log_tank console;
stream_caster {
enabled on;
caster mpegts_over_udp;
output rtmp://172.16.233.130/live/livestream;
listen 1234;
}
Using ffmpeg for live streaming:
for((;;)); do
ffmpeg -re -i ./srs/srs-gitlab-2.0release/trunk/doc/123.ts
-vcodec copy -f mpegts udp:/172.16.233.130:1234;
sleep 1;
done

TRANS_BY_GPT3

from srs.

Hello. My configuration is as follows:

listen 1935;

max_connections 1000;

daemon off;

srs_log_tank console;

stream_caster {

enabled         on;

caster          mpegts_over_udp;

output          rtmp://127.0.0.1/live/01;

listen          6001;

}

stream_caster
{

enabled         on;

caster          mpegts_over_udp;

output          rtmp://127.0.0.1/live/02;

listen          6002;

}

stream_caster
{

enabled         on;

caster          mpegts_over_udp;

output          rtmp://127.0.0.1/live/03;

listen          6003;

}

vhost defaultVhost {
}

I have set up three casters to stream output: 0.0.0.0:6001, 0.0.0.0:6002, 0.0.0.0:6003. After these three streams are outputted, SRS can automatically convert them to RTMP.

My question is: Can I only output addresses like 0.0.0.0? Where can I configure it to use standard multicast, such as 238.1.1.1:6001? Currently, when I output the stream using multicast 238, SRS does not receive it. It seems that I need to run VLC on Linux to play it and then SRS can receive it, but there are a lot of errors.

May I ask if there is something wrong with my configuration?

Thank you.

TRANS_BY_GPT3

from srs.

Hello,

I would like to ask if stream_caster supports multicast addresses? For example, 238.0.0.1:1234. If it does, how should I set the listen option?

TRANS_BY_GPT3

from srs.

Hello, I encountered this problem when using the mpeg-ts over UDP feature of srs2.0:
[2019-04-16 15:50:02.374][warn][3136][102][11] mpegts: ignore parse ts packet failed. ret=4013
[2019-04-16 15:50:02.374][error][3136][102][11] ts: sync_bytes must be 0x47, actual=0x18. ret=4013(Resource temporarily unavailable)
[2019-04-16 15:50:02.374][error][3136][102][11] mpegts: decode ts packet failed. ret=4013(Resource temporarily unavailable)
My settings are:
listen 1935;
max_connections 1000;
daemon off;
srs_log_tank console;
stream_caster {
enabled on;
caster mpegts_over_udp;
output rtmp://172.16.233.130/live/livestream;
listen 1234;
}
Using ffmpeg for streaming:
for((;;)); do
ffmpeg -re -i ./srs/srs-gitlab-2.0release/trunk/doc/123.ts
-vcodec copy -f mpegts udp:/172.16.233.130:1234;
sleep 1;
done

Hello, may I ask how you solved this problem? Could you please share the solution? Thank you very much~

TRANS_BY_GPT3

from srs.

Using ffmpeg to push UDP streams often causes SRS to fail to play.

ffmpeg push command:
ffmpeg -re -stream_loop 1 -i "D:\test.mp4" -codec copy -bsf:v h264_mp4toannexb -f mpegts udp://127.0.0.1:8935?pkt_size=1316

Configuration file:
stream_caster {
enabled on;
caster mpegts_over_udp;
output rtmp://127.0.0.1:1935/live/line1;
listen 8935;
}

Error message when a problem occurs:
parse ts packet err=code=4019 : ts: ts packet decode : ts: demux payload : ts: PES fresh packet length=0, us=0, cc=11
parse ts packet err=code=1009 : ts: handle ts message : ts: consume audio : write audio raw frame : send messages : send messages : send iovs : writev : writev
decode() [src/kernel/srs_kernel_ts.cpp:258][errno=11]

TRANS_BY_GPT3

from srs.

Using ffmpeg to push UDP streams often causes SRS to fail to play.

ffmpeg push command: ffmpeg -re -stream_loop 1 -i "D:\test.mp4" -codec copy -bsf:v h264_mp4toannexb -f mpegts udp://127.0.0.1:8935?pkt_size=1316

Configuration file: stream_caster { enabled on; caster mpegts_over_udp; output rtmp://127.0.0.1:1935/live/line1; listen 8935; }

Error message when encountering a problem: parse ts packet err=code=4019 : ts: ts packet decode : ts: demux payload : ts: PES fresh packet length=0, us=0, cc=11 parse ts packet err=code=1009 : ts: handle ts message : ts: consume audio : write audio raw frame : send messages : send messages : send iovs : writev : writev decode() [src/kernel/srs_kernel_ts.cpp:258][errno=11]

The cause of the problem has been roughly identified. It is due to the configuration of firstpkt_timeout and normal_timeout. The video stream push is interrupted for a long time, but the UDP port is reused, causing the channel to be reclaimed by SRS and unable to be used again for receiving UDP on that port. It is recommended to enable port reuse for the UDP receiving service.

TRANS_BY_GPT3

from srs.