[Q] How to smooth playout with DTU-315 and tsduck

[stulluk]

As I described here , I have a DTU-315 and I can play TS files ( recorded from live TS or self generated via ffmpeg) with TSduck. Tested playout to various DVB-S/T STB's and as well as Smart TV's. I can even use --level argument to control the RF level. Really nice.

My current problem is, playing with TSduck either stutters or sporadically causes blank screen with many STB's/TV's.

With StreamXpress, when I play TS files to these STB's, there is no stuttering or sporadic blank screen issue (Playback is smooth)

When I try playing with TSduck with following commands:

stulluk ~/TSFILES $  tsp --verbose -I file --infinite Turksat_11054_v_30000_2023-09-10-22-12-18_TRT_GROUP.ts  -O dektec --modulation DVB-S2-8PSK --satellite-frequency 11054000000 --lnb 9750,10600,11700 --convolutional-rate 3/4 --symbol-rate 30000000 --stuffing 
* file: initial input bitrate is 62,834,825 b/s
* dektec: using Dektec device 0, output channel 0 (DTU-315 port 1)
* dektec: setting output TS bitrate to 66,843,707 b/s
* dektec: setting output carrier frequency to 1,304,000,000 Hz
* dektec: output fifo size: 16,777,216 bytes, max: 16,777,216 bytes, typical: 16,777,216 bytes
* dektec: initial output bitrate: 66,843,707 b/s
* dektec: Will preload FIFO before starting transmission. Preload FIFO size: 13,421,696 bytes.
* dektec: DTU-315 output FIFO load is 13,421,696 bytes, starting transmission
^C* tsp: user interrupt, terminating...
* dektec: terminating DTU-315 output
* dektec: DTU-315 output terminated
stulluk ~/TSFILES $  cd ..
stulluk ~ $  tsp --verbose -I file --infinite BigBuckBunny-16M-Mux.ts   -O dektec --modulation DVB-S2-8PSK --satellite-frequency 11054000000 --lnb 9750,10600,11700 --convolutional-rate 3/4 --symbol-rate 30000000 --stuffing 
* file: initial input bitrate is 16,000,000 b/s
* dektec: using Dektec device 0, output channel 0 (DTU-315 port 1)
* dektec: setting output TS bitrate to 66,843,707 b/s
* dektec: setting output carrier frequency to 1,304,000,000 Hz
* dektec: output fifo size: 16,777,216 bytes, max: 16,777,216 bytes, typical: 16,777,216 bytes
* dektec: initial output bitrate: 66,843,707 b/s
* dektec: Will preload FIFO before starting transmission. Preload FIFO size: 13,421,696 bytes.
* dektec: DTU-315 output FIFO load is 13,421,696 bytes, starting transmission
^C* tsp: user interrupt, terminating...
* dektec: terminating DTU-315 output
* dektec: DTU-315 output terminated
stulluk ~ $  

With both SPTS (BigBuckbunny) and MPTS (TRT-GROUP), I always get sporadic stuttering and/or blank screen with TSduck.

Is this due to me using an old version ( 3.30-2710 ) or am I missing a command line argument ( such as --stuffing above or -P regulate ) ?

Note-1: Studied following:

• Variable source TS issue with speed/stuttering, can tsp add null packets? #4
• dvb-t with dektec #1012

Note-2: I also observed dektec plugin commandline output where input bitrate / output bitrate differs, but I used exactly same frequency , same symrate, same modulation parameters but I still get stuttering and/or blank screen (where STB's demux / decoder recovers periodically) with tsduck, but it just works fine with StreamXpress.. Do I need to calculate symrate / bitrate manually or is there something wrong with PTS ? What are the meanings of input bitrate / output bitrate?

Note-3: mediainfo's
BigBuckBunny-16M-Mux.ts (Self Created , constant bitrate, SPTS): https://pastebin.mozilla.org/KLtQt5VT
Turksat_11054_v_30000_2023-09-10-22-12-18_TRT_GROUP.ts ( Full Transponder record as TS, variable bitrate, MPTS): https://pastebin.mozilla.org/1UAZHKD9

I tested following TS files as well:

stulluk ~ $  tree TSFILES/
TSFILES/
├── Hotbird_10727_h_30000_2023-09-10-16-00-23-NASATV-UHD.ts
├── Hotbird_11727_v_29900_2023-09-10-16-36-11_DW_FHD.ts
├── Hotbird_12380_v_30000_2023-09-10-21-51-52_FASHIONTV_UHD.ts
├── Hotbird_12558_v_27500_2023-09-10-15-26-38_HOTBIRD4K.ts
├── Turksat_11054_v_30000_2023-09-10-22-12-18_TRT_GROUP.ts
├── Turksat_11767_v_15000_2023-09-10-14-41-59_TRT4K.ts
├── Turksat_12015_h_27500_2023-09-10-22-32-04_NTV_STAR.ts
└── Turksat_12245_h_27500_2023-09-10-17-13-44_KANALD_CNN.ts

0 directories, 8 files
stulluk ~ $  

Just 2 of above TS files also stutter with StreamXpress , and when I try playing them with media players, I see TS discontinuity errors in them. So, they are out of question, but other 6 TS files are perfectly clean, but they still stutter with TSduck where they are perfectly smooth with StreamXpress..

[lelegard]

To be directly injected in the modulator, the TS files shall have constant bitrate and this bitrate must be exactly the one which is computed from the output modulation parameters. Otherwise, the reception speed will be different from the expected playout speed. Can you confirm that the input bitrate are exactly conformant with the modulation parameters?

[stulluk]

Yes, as I mentioned above, I am using exactly same symbol rate with the actual live stream ( see above ). And also pls note that, even the TS itself is CBR or VBR, StreamXpress can playout this normally, and STBs has no stutter. And when I play the same streams via tsduck, it always stutter. Is this a bug or am I missing an argument to call tsp ?

[lelegard]

I am using exactly same symbol rate with the actual live stream

This is not sufficient. The output bitrate depends on all modulation parameters, including convolution rate and xPSK modulation. Are they the same as the original input?

Since this is DVB-S2, make sure that roll-off (and also maybe short frames and pilots) and the same as on input. You didn't specify any. All these parameters alter the expected bitrate.

even the TS itself is CBR or VBR, StreamXpress can playout this normally

Your command simply copies the input file into the modulator. I confirm that this works only if the input file has exactly the expected CBR bitrate for the modulation parameters. If your file has missing packets or stuffing removed, its effective bitrate is lower.

We don't know what StreamXpress does. Maybe it analyzes the signal and regulates it if its bitrate is lower.

Once you have fixed all missing modulation parameters as explained above, use one of the many online satellite bandwidth calculators (google for it) to get the exact expected bitrate. Then, use the command tsbitrate on your input file and check it is the same.

If it is lower than the expected value, use -P regulate --pcr-synchronous in your tsp command.

[stulluk]

First of all, thank you so much for your kindness & support.

I think we are getting closer, but not there yet. See below.

I am using exactly same symbol rate with the actual live stream

This is not sufficient. The output bitrate depends on all modulation parameters, including convolution rate and xPSK modulation. Are they the same as the original input?

Yes they are. Please see here: https://www.lyngsat.com/muxes/Turksat-3A_West_11054-V.html
And here are my tests:

stulluk ~ $  tsbitrate TSFILES/Turksat_11054_v_30000_2023-09-10-22-12-18_TRT_GROUP.ts 
TS bitrate: 62,826,773 b/s (188-byte), 68,173,733 b/s (204-byte)
stulluk ~ $  
stulluk ~ $  
stulluk ~ $  tsp --verbose -I file --infinite TSFILES/Turksat_11054_v_30000_2023-09-10-22-12-18_TRT_GROUP.ts   -O dektec --modulation DVB-S2-8PSK --satellite-frequency 11054000000 --lnb 9750,10600,11700 --convolutional-rate 3/4 --symbol-rate 30000000 --roll-off 0.35 --pilots 
* file: initial input bitrate is 62,834,825 b/s
* dektec: using Dektec device 0, output channel 0 (DTU-315 port 1)
* dektec: setting output TS bitrate to 65,325,764 b/s
* dektec: setting output carrier frequency to 1,304,000,000 Hz
* dektec: output fifo size: 16,777,216 bytes, max: 16,777,216 bytes, typical: 16,777,216 bytes
* dektec: initial output bitrate: 65,325,764 b/s
* dektec: Will preload FIFO before starting transmission. Preload FIFO size: 13,421,696 bytes.
* dektec: DTU-315 output FIFO load is 13,421,696 bytes, starting transmission
^C* tsp: user interrupt, terminating...
* dektec: terminating DTU-315 output
* dektec: DTU-315 output terminated
stulluk ~ $  tsp --verbose -I file --infinite TSFILES/Turksat_11054_v_30000_2023-09-10-22-12-18_TRT_GROUP.ts   -O dektec --modulation DVB-S2-8PSK --satellite-frequency 11054000000 --lnb 9750,10600,11700 --convolutional-rate 3/4 --symbol-rate 30000000 -P regulate --pcr-synchronous 
* regulate: minimum wait: 10,000,000 nano-seconds, using 50,000,000 ns
* file: initial input bitrate is 62,834,825 b/s
* dektec: using Dektec device 0, output channel 0 (DTU-315 port 1)
* dektec: setting output TS bitrate to 66,843,707 b/s
* dektec: setting output carrier frequency to 1,304,000,000 Hz
* dektec: output fifo size: 16,777,216 bytes, max: 16,777,216 bytes, typical: 16,777,216 bytes
* dektec: initial output bitrate: 66,843,707 b/s
* dektec: Will preload FIFO before starting transmission. Preload FIFO size: 13,421,696 bytes.
* regulate: using PID 0x0649 (1609) for PCR reference
* dektec: DTU-315 output FIFO load is 13,421,696 bytes, starting transmission
* dektec: Got DMA underflow.
* dektec: Got DMA underflow.
* dektec: Got DMA underflow.
* dektec: Got DMA underflow.
* dektec: Got DMA underflow.
* dektec: Got DMA underflow.
...

First, I don't know how can I find roloff-factor for a given Transponder. I assumed this one ( TRT-GROUP ) to have 0.35 , so I tried with that one. I also experimenting to change the value to 0.25 but this didn't change output bitrate.

Secondly, the argument "--pilots" is not fully clear to me. It doesn't accept any value, if I understand correctly, if we don't add it, basically pilot=off and if we add it, it is pilot=on . Is my understanding correct? I tried both adding and removing this argument, it didn't change output bitrate

Third, please notice the original TS Bitrate: it is around 62.830.000 b/s .

Fourth, adding -P regulate --pcr-synchronous causes * dektec: Got DMA underflow. message to be printed on the stdout and the STB immediately loses sync and tons of video artifacts occur. This is way worse than not using them. So I gave up there.

Lastly: Please notice the output bitrate , it is always way higher than input bitrate, so I focused there.

Since this is DVB-S2, make sure that roll-off (and also maybe short frames and pilots) and the same as on input. You didn't specify any. All these parameters alter the expected bitrate.

even the TS itself is CBR or VBR, StreamXpress can playout this normally

Your command simply copies the input file into the modulator. I confirm that this works only if the input file has exactly the expected CBR bitrate for the modulation parameters. If your file has missing packets or stuffing removed, its effective bitrate is lower.

We don't know what StreamXpress does. Maybe it analyzes the signal and regulates it if its bitrate is lower.

Exactly, this would be the goal : Can we find out what the StreamXpress is doing ? (Please save me from using this Windows PC 🤕 )

Once you have fixed all missing modulation parameters as explained above, use one of the many online satellite bandwidth calculators (google for it) to get the exact expected bitrate. Then, use the command tsbitrate on your input file and check it is the same.

I tried this:

So it seems TSduck is calculating the output bitrate correctly. But see below.

If it is lower than the expected value, use -P regulate --pcr-synchronous in your tsp command.

See above.

Additionally, I also tried --input-modulation but this didn't make a change, output bitrate was always 66M'ish. So it was stuttering / blank video sporadically.

---

What made me to actually progress on this was to try playing with symbol rate. So what I did was to try reducing the symbol rate.

After a few trials, even when the original symbol rate was 30000, I set it to 28200 , an voila! No stuttering, no blank screen...

stulluk ~ $  tsp --verbose -I file --infinite TSFILES/Turksat_11054_v_30000_2023-09-10-22-12-18_TRT_GROUP.ts   -O dektec --modulation DVB-S2-8PSK --satellite-frequency 11054000000 --lnb 9750,10600,11700 --convolutional-rate 3/4 --symbol-rate 28200000
* file: initial input bitrate is 62,834,825 b/s
* dektec: using Dektec device 0, output channel 0 (DTU-315 port 1)
* dektec: setting output TS bitrate to 62,833,084 b/s
* dektec: setting output carrier frequency to 1,304,000,000 Hz
* dektec: output fifo size: 16,777,216 bytes, max: 16,777,216 bytes, typical: 16,777,216 bytes
* dektec: initial output bitrate: 62,833,084 b/s
* dektec: Will preload FIFO before starting transmission. Preload FIFO size: 13,421,696 bytes.
* dektec: DTU-315 output FIFO load is 13,421,696 bytes, starting transmission
^C* tsp: user interrupt, terminating...
* dektec: terminating DTU-315 output
* dektec: DTU-315 output terminated
stulluk ~ $

The output bitrate is very close to input bitrate, and since none of the --roll-off or --pilots or -P regulate --pcr-synchronous or --stuffing or --input-modulation changed the output bitrate, I guess there is something else that is causing this problem...

So, as a summary, if the output bitrate is very close to input bitrate, no (easily observable) issue occurs.

Is this a bug, or am I missing anything ?

[konrad-dabek]

Are you really sure, that you have recorded a full TS? Because this transponders output is around 65,12 Mbit/s, so if you've got ~63 Mbit/s, it looks like you're missing null packets, which are occupying 2,2 Mbit/s in this MUX.

Correct settings for this frequency are:
roll-off: 0.20
pilots: on
DVB-S2/8PSK
FEC: 3/4

Details: https://www.digitalbitrate.com/dtv.php?mux=11054&liste=1&live=89&lang=en
Please share your TS, so we can examine it or check if in recordings you can see PID 8191 (you can examine TS contents with TSDuck itself).

StreamXpress automatically fills up TS with nulls if RMX option is enabled. If you disable RMX option and TS is not a full TS recording, SR calculation will significantly fall down, which is also a (bit tricky) way to confirm, that the recording is not a full TS.

[stulluk]

@konrad-dabek thank you so much.

You were right about two points:

1. My recorded TS was not full. I thought that it was full, but actually, it was not.

To capture Full TS from transponders, I was using a program called MUMUDVB. Compared to TSduck, this program had one nice feature, it was printing the program names in the stdout during capture. I couldn't find this feature in tsp, so I was using it.

Tonight I decided to bring my TBS5530 and try capturing same transponder via TSduck to see if the bitrate changes or not. And it was, TSduck was actually capturing around 65Mbit/s including RADIO's ( Which was not there in my previous captures with MumuDVB) ...

Then, I decided to play it together with correct pilots and roll-off values.

Result: Almost perfect playback. No stuttering & no blank screen
Note: I was getting just a little MPEG mosaic between cycles of restarting the TS playout from the beginning due to --infinite argument.

2. You are right about the --roll-off and --pilots values. Without these, the output bitrate was different than input bitrate and I was getting blank screens. With correct values, I played multiple times, and there was no issue.

Sadly, during these tests, somehow my TBS5530 get damaged and now it is not detected by my PC's anymore. When I connect it to my PC, dmesg print is as follows:

 [  699.781481] usb 1-2: new high-speed USB device number 6 using xhci_hcd
[  700.007851] usb 1-2: New USB device found, idVendor=04b4, idProduct=8613, bcdDevice=a0.01
[  700.007858] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  700.010025] usbtest 1-2:1.0: FX2 device
[  700.010030] usbtest 1-2:1.0: high-speed {control bulk-in bulk-out} tests (+alt)
[  704.545766] usb 1-2: USB disconnect, device number 6

I suspect something happened to its firmware or USB controller. So I can't use it and I can't provide my commands to capture full TS and playout to Dektec DTU-315...

I will buy a new DVB device which would be supported in the mainline kernel: I don't want to rebuild kernel drivers everyttime I upgrade my kernel: https://github.com/tbsdtv/linux_media/wiki -> I don't want to do this.

I suspect Hauppauge DVB-S/S2 cards might work out-of-box with recent kernels, what do you think ? If you can suggest any device that can work out of box with a reasonable price, please let me know.

Other than this, thank you very much for your helps, and my issue is resolved.

[lelegard]

Note: I was getting just a little MPEG mosaic between cycles of restarting the TS playout from the beginning due to --infinite argument.

That is expected. A partial image encoding at the end of the file is followed by a different partial encoding at the beginning of it. The result can only be video garbage.

[stulluk]

@lelegard @konrad-dabek Thank you so much for your kindness & support.

I can now capture full TS from Transponders correctly, and I verified that it really needs correct value for roll-off and pilots.

The important hint for me was to make sure input bitrate ~ output bitrate. When this is not achieved, I saw various video artifacts, but when they are almost equal, playback for long durations are flawless.

Here is a screenshot of how it works for someone interested:

Closing the issue with many thanks.