Hello,
I can now get good results when viewing the stream with VLC on the same computer and also using VLC on another computer over the local network.
Just been on the satellite using 333ks and FEC 2/3 and all seemed OK - for a short while....
After less than 1 minute the video froze and then re-started after approx 10 seconds. This kept on repeating until it froze completely.
To view what was happening I used a testcard image with scrolling text - this showed the freezing video quite clearly. When it did re-start the scrolling text seemed to jump to where it would have been had it not stalled.
The Portsdown and computer are both connected to the network via the same network switch, so I tried connecting the Portsdown directly to the router but this made no difference.
I tried 250ks and got the same result. I also tried 125ks but could not get the Ryde to lock on the signal.
I have the Portsdown set with a static IP of 192.168.1.26.
There are no obvious errors showing up on the script window. If I stop transmitting with the Portsdown when the video has frozen but keep the script running and then re-transmit the video display on the satellite seems OK for a while until it freezes again.
Could this be an issue with the sending of the stream to the Portsdown that is causing this problem ?
Or could it be that the settings in the script needs more adjustment ?
Regards,
Nick - G4NKV
Streaming from OBS freezes and stutters.
Re: Streaming from OBS freezes and stutters.
I am going to assume here you are using the latest minitioune and it is fussy.
The TS rate the Pluto suggests seems not entirely accurate with respect to overhead according to minitioune. It probably is close enough at higher rates but lower rates the overhead might be a bit lumpy. The buffers should account for this but if the coding is not as well behaved as we would like these buffers can fill up. That might be what is happening. It won't manifest with VLC because VLC doesn't have a fixed symbol rate to match.
When you select a bit rate for the TS make sure it is a bit less than the calculator says - so 250 2/3 QPSK might suggest 331kb/s. Knock it back a bit and see if that helps. Start at say 10% reduction, 300kb/s and work upwards while it is still reliable. The Pluto inserts nulls to account for the lower rate. I assume the Portsdown does too but I don't use it that way so can't be sure.
The other reasons you might see this are uncorrected errors on the receive side or if you are using a networked Portsdown or Pluto, packets getting lost on the network. Do not connect the Pluto to a long ethernet cable and if it's connected by USB, make sure the cable is the very best you have, like the one it came with. Make sure nothing else on the network is sending UDP, e.g. a H264/H265 box.
Mike
The TS rate the Pluto suggests seems not entirely accurate with respect to overhead according to minitioune. It probably is close enough at higher rates but lower rates the overhead might be a bit lumpy. The buffers should account for this but if the coding is not as well behaved as we would like these buffers can fill up. That might be what is happening. It won't manifest with VLC because VLC doesn't have a fixed symbol rate to match.
When you select a bit rate for the TS make sure it is a bit less than the calculator says - so 250 2/3 QPSK might suggest 331kb/s. Knock it back a bit and see if that helps. Start at say 10% reduction, 300kb/s and work upwards while it is still reliable. The Pluto inserts nulls to account for the lower rate. I assume the Portsdown does too but I don't use it that way so can't be sure.
The other reasons you might see this are uncorrected errors on the receive side or if you are using a networked Portsdown or Pluto, packets getting lost on the network. Do not connect the Pluto to a long ethernet cable and if it's connected by USB, make sure the cable is the very best you have, like the one it came with. Make sure nothing else on the network is sending UDP, e.g. a H264/H265 box.
Mike
Re: Streaming from OBS freezes and stutters.
Hi Mike,
Thanks for the reply.
I am using a Portsdown with Lime Mini - one of the early ones I obtained from BATC shop. For receive it's the Ryde with Minitioner hardware connected via USB. I have configured some OBS profiles with the Output (Scaled) Resolution and fps set to match that in the scripts used.
The Portsdown and Ryde are connected by short 1 Mtr cables to a network switch on my desk, which is connected to the router via a network cable approx 3 Mtrs long.
I have tried two different scripts - the one of yours in issue 270 for BATC net (H264 encoding) and one by SQ6QV (H265 encoding). Both work fine with VLC player but not with Portsdown, but now I see your explanation of why that is.
From what you say am I correct in assuming that the stream from the computer may be too fast (if that's the correct term) at the calculated rate of say 440k (333 2/3 QPSK) for the Portsdown to handle ?
Is there a way of monitoring the packets to see if they are getting lost on the network, or if there are any other issues ?
I will try your suggestion of reducing the -muxrate to see if it helps things. The batch file I have written (never done batch files before) based on the one by SQ6QV, but which also includes your script for 125ks, allows me to enter a custom TS rate. It's a bit clunky but seems to work OK.
Wondering if the Pluto is a better way to go forward.
Regards,
Nick - G4NKV
Thanks for the reply.
I am using a Portsdown with Lime Mini - one of the early ones I obtained from BATC shop. For receive it's the Ryde with Minitioner hardware connected via USB. I have configured some OBS profiles with the Output (Scaled) Resolution and fps set to match that in the scripts used.
The Portsdown and Ryde are connected by short 1 Mtr cables to a network switch on my desk, which is connected to the router via a network cable approx 3 Mtrs long.
I have tried two different scripts - the one of yours in issue 270 for BATC net (H264 encoding) and one by SQ6QV (H265 encoding). Both work fine with VLC player but not with Portsdown, but now I see your explanation of why that is.
From what you say am I correct in assuming that the stream from the computer may be too fast (if that's the correct term) at the calculated rate of say 440k (333 2/3 QPSK) for the Portsdown to handle ?
Is there a way of monitoring the packets to see if they are getting lost on the network, or if there are any other issues ?
I will try your suggestion of reducing the -muxrate to see if it helps things. The batch file I have written (never done batch files before) based on the one by SQ6QV, but which also includes your script for 125ks, allows me to enter a custom TS rate. It's a bit clunky but seems to work OK.
Wondering if the Pluto is a better way to go forward.
Regards,
Nick - G4NKV
Re: Streaming from OBS freezes and stutters.
Hi Nick,
I use a Pluto. I have a lime but it's not been used this year, nor much of last year, for DATV. Does that answer the question?
Mike
I use a Pluto. I have a lime but it's not been used this year, nor much of last year, for DATV. Does that answer the question?
Mike
Re: Streaming from OBS freezes and stutters.
Hi Mike,
Your suggestion of reducing the TS bitrate by 10% has worked....
For 333ks 2/3 FEC I reduced it from 440k to 400k and was rewarded with a good steady signal over the satellite. From opening test card, webcam video and audio, a full length 'Big Buck Bunny' video and closing image with audio I detected no problems at all.
I also tried 250ks at 2/3 FEC reducing the TS bitrate from 333ks to 300ks and all OK.
Tested both with NVidia encoders and at 15 fps and 30 fps - no problems.
Could not test at 125ks as I could not get the Ryde to lock. Also unable to test at 500ks and 1000ks as current amp not powerful enough and replacement not being used as it's getting water into the case (which is IP66 rated), so that's my next thing to solve. When I test I will just set the bitrates down by 10% as well.
Many thanks for the help - you hit the nail on the head with that suggestion.
Regards,
Nick.
Your suggestion of reducing the TS bitrate by 10% has worked....
For 333ks 2/3 FEC I reduced it from 440k to 400k and was rewarded with a good steady signal over the satellite. From opening test card, webcam video and audio, a full length 'Big Buck Bunny' video and closing image with audio I detected no problems at all.
I also tried 250ks at 2/3 FEC reducing the TS bitrate from 333ks to 300ks and all OK.
Tested both with NVidia encoders and at 15 fps and 30 fps - no problems.
Could not test at 125ks as I could not get the Ryde to lock. Also unable to test at 500ks and 1000ks as current amp not powerful enough and replacement not being used as it's getting water into the case (which is IP66 rated), so that's my next thing to solve. When I test I will just set the bitrates down by 10% as well.
Many thanks for the help - you hit the nail on the head with that suggestion.
Regards,
Nick.