video delivery without delay. not a local network. need help

Igor T

video delivery without delay. not a local network. need help
Hi friends. I do not speak English well, but I will try to ask you for help
i have tvheadend. I accept video streams from the Internet and distribute them back to combine several remote computers
network diagram:
internet speed 500 \ 500 mb \ s
remote computer running dvbdream --- internet ---> my router (192.168.88.1) ---> server tvheadend (192.168.88.3)
the remote computer has a dvbdream program that can send a video stream to the network via udp.

the problem is that through the Internet a stream with a speed of ~ 15-20mb \ s cannot be delivered efficiently. the picture does not crumble, but simply stands still.

I tried to solve this with ffmpeg and on the remote machine I ran the command

ffmpeg -i "udp: //127.0.0.1: 1235? overrun_nonfatal = 1" -preset ultrafast -tune zerolatency -f rtp_mpegts "rtp: // my_server_ip: 1238"

now I can see the given channel through tvheadend, but there is a big delay.
ping between remote computer and tvheadend ~ 50ms
I was counting on the fact that if the remote computer sends its stream to tvheadend and watches it through vlc using the m3u sheet from tvheadend, then the delay will be a ping to the server 50ms plus 50ms back. 100ms was fine for me, but in practice it turned out 2000-3000ms.
what could be a problem? ffmpeg needs a different command? is this command wasting time transcoding? How can I deliver content as quickly as possible, avoiding all delays and buffering?
vlc with the option to view video from the network with 0ms buffering
dvbdream can only send a stream via udp. but udp scatters channels via the Internet, please tell me what to do?

Anonymous

Igor T wrote:

> video delivery without delay. not a local network. need help

Not a local network means not within your control.

> I tried to solve this with ffmpeg and on the remote machine I ran the command
> ffmpeg -i "udp: //127.0.0.1: 1235? overrun_nonfatal = 1" -preset ultrafast -tune zerolatency -f rtp_mpegts "rtp: // my_server_ip: 1238"
>
> now I can see the given channel through tvheadend, but there is a big delay.
> ping between remote computer and tvheadend ~ 50ms
> I was counting on the fact that if the remote computer sends its stream to tvheadend and watches it through vlc using the m3u sheet from tvheadend, then the delay will be a ping to the server 50ms plus 50ms back. 100ms was fine for me, but in practice it turned out 2000-3000ms.
> what could be a problem? ffmpeg needs a different command? is this command wasting time transcoding? How can I deliver content as quickly as possible, avoiding all delays and buffering?
> vlc with the option to view video from the network with 0ms buffering

> dvbdream can only send a stream via udp. but udp scatters channels via the Internet, please tell me what to do

This has nothing to do with thv or descrambling. Goto dvbdream community

Saen Acro

Guess is involved feeds from 7E/9E
Disable cache in player.

Anonymous

saen acro wrote:
> Guess is involved feeds from 7E/9E

> Disable cache in player.

What problem will be solved with this recommendation?

Saen Acro

Der Depp vom Dienst wrote:
> saen acro wrote:
> > Guess is involved feeds from 7E/9E
> > Disable cache in player.
>

> What problem will be solved with this recommendation?

Try for yourself before coment, and learn what do IPB frames in stream and when picture come visualised.

He need low delay picture from "feed to screen" in sport events.

Anonymous

saen acro wrote:
> Der Depp vom Dienst wrote:
> > saen acro wrote:
> > > Guess is involved feeds from 7E/9E
> > > Disable cache in player.
> >
> > What problem will be solved with this recommendation?
>
> Try for yourself before coment, and learn what do IPB frames in stream and when picture come visualised.

> He need low delay picture from "feed to screen" in sport events.

Do menuesearch before think. Will learn that is rubbish.

Wasting other peoples time.

Saen Acro

Der Depp vom Dienst wrote:
> Do menuesearch before think. Will learn that is rubbish.
>

> Wasting other peoples time.

user#26583 reduce your aggression, start respecting others to respect you.

Anonymous

saen acro wrote:
> Der Depp vom Dienst wrote:
> > Do menuesearch before think. Will learn that is rubbish.
> >
> > Wasting other peoples time.
>

> user#26583 reduce your aggression, start respecting others to respect you.

Improve your english:you may be understood.
Improve your techncal skills: you may produce less bullshit.

Igor T

> He need low delay picture from "feed to screen" in sport events.

Yes you are right. your answer is the only one at the moment which contains good information. Should I cut my keyframes?

Saen Acro

No need they are important to reduce first show image.
Just keep in mind 250-300ms must be maximum delay server client.

Else will get green artefacts.

I prefer scenario with EoIP tunnel, in place all traffic to pass over network hop's.

Anonymous

Once again: This has nothing to do with thv or descrambling. It is new that this forum is for Internet-Sharing.

Saen Acro

Der Depp vom Dienst wrote:

> Once again: This has nothing to do with thv or descrambling. It is new that this forum is for Internet-Sharing.


Der Depp vom Dienst = The idiot on duty

We are not dependent on your limited knowledge, user#26642 is explained enough detailed.
Exactly descrambling is problem not to use TVH for this scenario as main frontend, and use it as middleware.

Anonymous

saen acro wrote:
> Der Depp vom Dienst wrote:
> > Once again: This has nothing to do with thv or descrambling. It is new that this forum is for Internet-Sharing.
>
> [...]
> We are not dependent on your limited knowledge, user#26642 is explained enough detailed.

> Exactly descrambling is problem not to use TVH for this scenario as main frontend, and use it as middleware.

Unfortunatly this sentence doesn't makes any sense. You should write more clearly - than others may know what you mean.

BTW: your translation is badly wrong. In other words: you don't even understand the joke.

Anonymous

Igor T wrote:

> Yes you are right. your answer is the only one at the moment which contains good information. Should I cut my keyframes?

So is your problem solved - or are you gone because you realized that saen acro produces only hot air ?