Jump to content


Photo

Delay the transport stream before recoring

TS delay

  • Please log in to reply
11 replies to this topic

#1 Wurstpelle

  • Member
  • 4 posts

0
Neutral

Posted 23 March 2015 - 17:50

Hi!

 

Im completely new to OpenPLI development.

 

What I want to achieve is delaying/caching parts ot the transport stream before submitting it to the demultiplexer. Delaying a couple of seconds is normally sufficient for getting a failure-free recoring so this sould be done in RAM.

 

So my question is where would I start hooking into the TS (best right after the tuner) and before the TS get de-muxed and distributed to i.e. the recorder part of OpenPLi.

 

Im developing on a VU+DUO2 but the implementation should be generic so it can be used on every box.

 

Any hint on where to get started would be highly appreciated.

 

Thanks, WP



Re: Delay the transport stream before recoring #2 Pr2

  • PLi® Contributor
  • 6,046 posts

+256
Excellent

Posted 23 March 2015 - 18:17

Hi,

 


... Delaying a couple of seconds is normally sufficient for getting a failure-free recording so this should be done in RAM.

 

Why do you think that the current way of recording in OpenPLi is unsafe?

I never miss a record on OpenPLi except when the HDD is full :-) so why do you want to add a buffer that will use RAM space when it is not needed, and please think that OpenPLi support multiple STBs models that don't have all the RAM and the power of your VU+ Duo2.

 

Pr2


NO SUPPORT by PM, it is a forum make your question public so everybody can benefit from the question/answer.
If you think that my answer helps you, you can press the up arrow in bottom right of the answer.

Wanna help with OpenPLi Translation? Please read our Wiki Information for translators

Sat: Hotbird 13.0E, Astra 19.2E, Eutelsat5A 5.0W
VU+ Solo 4K: 2*DVB-S2 + 2*DVB-C/T/T2 (used in DVB-C) & Duo 4K: 2*DVB-S2X + DVB-C (FBC)

AB-Com: PULSe 4K 1*DVB-S2X (+ DVB-C/T/T2)
Edision OS Mio 4K: 1*DVB-S2X + 1*DVB-C/T/T2
 


Re: Delay the transport stream before recoring #3 Wurstpelle

  • Member
  • 4 posts

0
Neutral

Posted 23 March 2015 - 18:46

This is especially an issue for TS packets that are encrypted.

So delaying the encrypted packets until the correct (even or odd) decryption word is available makes recording more robust.

This should be just a few 100ms so I assume not much memory is needed.

Re: Delay the transport stream before recoring #4 WanWizard

  • PLi® Core member
  • 68,301 posts

+1,718
Excellent

Posted 23 March 2015 - 21:28

I never even had a failure recording, especially not with a local disk. Even an old 5400rpm disk is more than fast enough, and the OS provides enough buffer for it not to fail.

 

So I'm curious to what issue you have, and you think this is going to fix...


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Delay the transport stream before recoring #5 Jan Gruuthuse

  • Senior Member
  • 985 posts

+20
Neutral

Posted 24 March 2015 - 08:39

If your device has recording issues, use lead in 10 or 15 minutes. Increasing buffering eats memory (HD transmissions) On my current box this is what I have as memory, in standby:

System  Total: 230.21 MB  Used: 117.57 MB  Free: 112.64 MB  Buffer: 0.44 MB  Cached: 34.88 MB. Not much left to play with


Sf8HD, sf8008, OpenPli 9.0, fixed lnb 28.2E, 19.2E

Re: Delay the transport stream before recoring #6 Wurstpelle

  • Member
  • 4 posts

0
Neutral

Posted 24 March 2015 - 09:43

The problem is not recording. The problem is decryption. When the stream switches from even to odd but the right control word hasn't arrived yet in the system because of delays TS decryption immediately fails. So delaying the stream until the correct control word arrived will keep the stream correct.

I'm talking about using a 1-2 MB buffer - so the RAM resources should not be the problem.

But my original question actually was how to hook into the TS right after the tuner just before sending the stream to the decryption block.

Re: Delay the transport stream before recoring #7 Pr2

  • PLi® Contributor
  • 6,046 posts

+256
Excellent

Posted 24 March 2015 - 13:14

OK I have got it, you don't have any local valid subscription card in your STB and you use an external sharing system (over Internet probably) to descramble the signal... and this gives you problems. I don't think that OpenPLi members will provide support for such illegal stuff.

 

Get a local card in your STB and your problem will be solved the response time will perfectly match the reception timing.

 

Pr2


NO SUPPORT by PM, it is a forum make your question public so everybody can benefit from the question/answer.
If you think that my answer helps you, you can press the up arrow in bottom right of the answer.

Wanna help with OpenPLi Translation? Please read our Wiki Information for translators

Sat: Hotbird 13.0E, Astra 19.2E, Eutelsat5A 5.0W
VU+ Solo 4K: 2*DVB-S2 + 2*DVB-C/T/T2 (used in DVB-C) & Duo 4K: 2*DVB-S2X + DVB-C (FBC)

AB-Com: PULSe 4K 1*DVB-S2X (+ DVB-C/T/T2)
Edision OS Mio 4K: 1*DVB-S2X + 1*DVB-C/T/T2
 


Re: Delay the transport stream before recoring #8 MiLo

  • PLi® Core member
  • 14,042 posts

+298
Excellent

Posted 24 March 2015 - 14:03

Just record without descrambling, this is an option you can set. You can then descramble it offline, and retry as often as you like. This will not work on all boxes (in particular, it won't work on DMM models) because not all boxes can route data from the software side through the descrambler.

Or just stream the recording to yourself and descramble it on playback for "live" TV.

You will always need a record + playback step in order to delay the stream, because of the way the hardware works.
Real musicians never die - they just decompose

Re: Delay the transport stream before recoring #9 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 24 March 2015 - 19:44

Plus:

 

The trajectory of the transport stream is completely in sillicon until it's fetched by enigma and written to file. Before the stream leaves the sillicon, it already has been descrambled. There is no way you can add buffering there. The hardware buffer of the demuxer is configurable though BUT it won't solve this issue.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Delay the transport stream before recoring #10 Wurstpelle

  • Member
  • 4 posts

0
Neutral

Posted 25 March 2015 - 10:32

Ok - thanks for all the information!

It looks like right before writing to file would be an option to hook into the stream if I do not want to do it offline. I will check this option.

@MiLo - you mentioned an option routing data through the HW descrambler on some boxes from software side. Can you please point me to where this could be achieved (for my case on the VU+duo2 if possible...)

Re: Delay the transport stream before recoring #11 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 25 March 2015 - 11:11

use the 'offline decode' option in the context menu of the recording list.

 

Just make sure you set the recording type to 'no decoding' and 'include ecm', so they include everything you need for offline decoding.

 

But I'm not sure that offline decoding works on vu+ nowadays, it hasn't for a long time.



Re: Delay the transport stream before recoring #12 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 26 March 2015 - 18:48

But I'm not sure that offline decoding works on vu+ nowadays, it hasn't for a long time.

Good point!

 

And the answer is "no", it can't work, because the scrambling bits in the ts header are cleared even though no descrambling has taken place. This bug has been reported to VU+ and they said they will look into the issue. Also I've heard a rumour that certain (all?) VU+ models cannot descramble offline anyway, due to hardware limitations. VU+ receivers are not the best choice if you're going to fiddle with decryption (see our comparison chart).


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.



1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users