Jump to content


Photo

streamproxy and seeking in file


  • Please log in to reply
79 replies to this topic

Re: streamproxy and seeking in file #61 Erik Slagter

  • PLi® Core member
  • 45,346 posts

+497
Excellent

Posted 9 May 2019 - 15:21

Ok good to know. If you have something that's release quality, please share or create a PR.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: streamproxy and seeking in file #62 anudanan

  • Senior Member
  • 998 posts

+14
Neutral

Posted 9 May 2019 - 15:30

Here is my source tree for the thread based version but there are many changes between my tree and your streamproxy sources. So I´m not sure to make a PR to your tree. I´m not sure if your will use my complete changes but you can look into it. Maybe you have  better ideas to switch from fork based version to the thread based version.

 

https://github.com/a...ee/work-threads

 

This version runs very stable on my uno4kse and I hope the source also handle boxes with more than one transcoding units. 

I have simulate something for that


Receiver:2 x Uno4k SE (PLI 7.0 rel), 1 x ET9200 (PLI 4.0), NAS: 2 x QNAP 410, TV: LG 65C8llla, LG 47LB570V, LG 42LM615S, Sound: Yamaha RX-v663, Teufel System 5 THX

Re: streamproxy and seeking in file #63 anudanan

  • Senior Member
  • 998 posts

+14
Neutral

Posted 9 May 2019 - 16:09

The base idea my changes is to have a structur to handle a fix number of threads for trancoding streams. The number depends on the hardware in the box, The other thread are only limited inside the source code with a define

#define CLIENTTHREADS 32

 

If a stream request comes up than it depends on the transcoding demand to use one of the free structure for transcoding threads or to use a free structur for threads for streaming directly without transcoding.  The thread starts if the request comes up

 

If the main process detects seeking in a recorded movie  thread than  it informs the streaming threadto use  a new socket and a new position. 

 

The filetstreaming thread checks in his loop if there is a seeking request and make then the neccessary operations.


Receiver:2 x Uno4k SE (PLI 7.0 rel), 1 x ET9200 (PLI 4.0), NAS: 2 x QNAP 410, TV: LG 65C8llla, LG 47LB570V, LG 42LM615S, Sound: Yamaha RX-v663, Teufel System 5 THX

Re: streamproxy and seeking in file #64 Erik Slagter

  • PLi® Core member
  • 45,346 posts

+497
Excellent

Posted 9 May 2019 - 16:53

I'd best see the changes being applied in small steps (git commits or patches). I've done a similar thing on another project recently. Take the original code, then one step at a time, add some code in a way it still can compile (ideally it also still works), make a git commit and describe clearly what it does and how and then go on to the next until everything is in. In the meantime, check for unnecessary white space changes and ignore them. For other non-functional changes, apply them separately. This will make sure, in the future, me, and others, will be able to find out what went on and why, so other can also develop and contribute.


Edited by Erik Slagter, 9 May 2019 - 16:54.

* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: streamproxy and seeking in file #65 anudanan

  • Senior Member
  • 998 posts

+14
Neutral

Posted 9 May 2019 - 17:11

I‘ve done also many different commits from the beginning of the changes to the lastest changes. You see it in the commit history of the branch. Ir may be that is not compatible with your idea of step bei step. For me it was usefull to learn how to migrate from the fork model to the thread model

Edited by anudanan, 9 May 2019 - 17:15.

Receiver:2 x Uno4k SE (PLI 7.0 rel), 1 x ET9200 (PLI 4.0), NAS: 2 x QNAP 410, TV: LG 65C8llla, LG 47LB570V, LG 42LM615S, Sound: Yamaha RX-v663, Teufel System 5 THX

Re: streamproxy and seeking in file #66 Erik Slagter

  • PLi® Core member
  • 45,346 posts

+497
Excellent

Posted 9 May 2019 - 19:07

Good, I'll have a look. May take a while though, don't panic.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: streamproxy and seeking in file #67 Erik Slagter

  • PLi® Core member
  • 45,346 posts

+497
Excellent

Posted 29 May 2019 - 14:04

I reviewed the code and commits.

 

The commits are not suitable for merging into mainstream, the descriptions are mostly missing, incomplete or not descriptive; the commits are mostly whitespace changes and "trying" things and full of whitespace errors.

 

The code itself is also not up to quality standard, I'm afraid. Introduction of char arrays (a.o.) and pointers is not really something I'd like to see.

 

It looks like the code still has fork()s? Or are they gone in the final versions?

 

Whenever I have some time I will do it like this:

 

- remove the current fork() so there will always only run one instance

- if the streamproxy detects more than one encoder, it will fork() itself and attach itself so a second tcp port for the secondary encoder

- it will also fork an instance for streaming

- each instance of streamproxy will only serve one encoder, which will make quite a lot of things quite a bit simpeler

 

It may be possible to do all of this without forking at all, implementing it all with threads, which is better, especially on a STB.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: streamproxy and seeking in file #68 anudanan

  • Senior Member
  • 998 posts

+14
Neutral

Posted 30 May 2019 - 08:57

Thank you for your coments

I know the code is not compliant with your demands but for me it works weil.

There are no forma only threads.

The disadvantages of using different processes for different encoderes are the different listen ports. So the clients must know about that and also the OWIf for generation of the m3u file.

My different streaming threads use the same ports similar to your streamproxy forks
Receiver:2 x Uno4k SE (PLI 7.0 rel), 1 x ET9200 (PLI 4.0), NAS: 2 x QNAP 410, TV: LG 65C8llla, LG 47LB570V, LG 42LM615S, Sound: Yamaha RX-v663, Teufel System 5 THX

Re: streamproxy and seeking in file #69 anudanan

  • Senior Member
  • 998 posts

+14
Neutral

Posted 30 May 2019 - 09:38

Sorry ma mobil phone. Forma means fork
Receiver:2 x Uno4k SE (PLI 7.0 rel), 1 x ET9200 (PLI 4.0), NAS: 2 x QNAP 410, TV: LG 65C8llla, LG 47LB570V, LG 42LM615S, Sound: Yamaha RX-v663, Teufel System 5 THX

Re: streamproxy and seeking in file #70 Erik Slagter

  • PLi® Core member
  • 45,346 posts

+497
Excellent

Posted 30 May 2019 - 10:16

That is exactly why I want to do it differently, either with or without using threads. The main issue is that we cannot know if a new request comes from another client or the same client. So my first step is to make different encoders listen to different tcp ports. The drawback is that you'd need to configure different tcp ports on different clients, but the huge advantage is that once on one encoder, the client stays on one encoder (and cannot spoil it for other clients). And the current situation, which quite frequently occurs, where two encoders are busy for one client, is no longer possible.

 

This is for broadcom transcoding.

 

For Xtrend/Mutant/Zgemma transcoding the transcoding is handled by enigma; there is no interface to the encoder in streamproxy itself, so this could not be handled this way. OTOH this transcoding interface has way less troubles, so I won't focus too much on it.

 

Then there is the streaming interface as well, which could be offered unlimited.

 

Currently I am thinking of splitting the interface into streaming+enigma transcoding on one side and broadcom transcoding on the other. Maybe something like mostly like it is now: one port for streaming, enigma transcoding and broadcom transcoding on one encoder. Then the other broadcom encoder on another port.

 

It should be possible to implement all of this without forking, i.e. with threads, but it may be complex.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: streamproxy and seeking in file #71 anudanan

  • Senior Member
  • 998 posts

+14
Neutral

Posted 30 May 2019 - 11:11

For detection seeking from the same client I compare the filename and the IP address of the new request with the old one. This is save enough. There is a theoretical problem with more clients behind NAT if they stream the same movie, but from my point of view that is no problem
Receiver:2 x Uno4k SE (PLI 7.0 rel), 1 x ET9200 (PLI 4.0), NAS: 2 x QNAP 410, TV: LG 65C8llla, LG 47LB570V, LG 42LM615S, Sound: Yamaha RX-v663, Teufel System 5 THX

Re: streamproxy and seeking in file #72 anudanan

  • Senior Member
  • 998 posts

+14
Neutral

Posted 31 May 2019 - 20:00

how Is your idea to check if a client makes a seek or a new client will make a new connection. The same was as I do it ?
Receiver:2 x Uno4k SE (PLI 7.0 rel), 1 x ET9200 (PLI 4.0), NAS: 2 x QNAP 410, TV: LG 65C8llla, LG 47LB570V, LG 42LM615S, Sound: Yamaha RX-v663, Teufel System 5 THX

Re: streamproxy and seeking in file #73 Erik Slagter

  • PLi® Core member
  • 45,346 posts

+497
Excellent

Posted 31 May 2019 - 20:35

I don't want to make it that stateful. More state = less robust.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: streamproxy and seeking in file #74 Erik Slagter

  • PLi® Core member
  • 45,346 posts

+497
Excellent

Posted 31 May 2019 - 20:36

how Is your idea to check if a client makes a seek or a new client will make a new connection. The same was as I do it ?

If it connects on the same port(=encoder) it's treated as the same client.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: streamproxy and seeking in file #75 anudanan

  • Senior Member
  • 998 posts

+14
Neutral

Posted 31 May 2019 - 20:45

That means an second client can stop a running stream from a first client and catch the encoder.
Do you think that is ok and acceptable?
Receiver:2 x Uno4k SE (PLI 7.0 rel), 1 x ET9200 (PLI 4.0), NAS: 2 x QNAP 410, TV: LG 65C8llla, LG 47LB570V, LG 42LM615S, Sound: Yamaha RX-v663, Teufel System 5 THX

Re: streamproxy and seeking in file #76 Erik Slagter

  • PLi® Core member
  • 45,346 posts

+497
Excellent

Posted 1 June 2019 - 13:18

It's all under your own control. Every client that is configured to use the same port can interrupt each other. If you want to clients to be fully indepedent, use two different ports (= encoders).

 

This is only relevant on receivers that have two encoders anyway.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: streamproxy and seeking in file #77 anudanan

  • Senior Member
  • 998 posts

+14
Neutral

Posted 1 June 2019 - 15:09

Ok, not automatic but only manual by the user
Receiver:2 x Uno4k SE (PLI 7.0 rel), 1 x ET9200 (PLI 4.0), NAS: 2 x QNAP 410, TV: LG 65C8llla, LG 47LB570V, LG 42LM615S, Sound: Yamaha RX-v663, Teufel System 5 THX

Re: streamproxy and seeking in file #78 Erik Slagter

  • PLi® Core member
  • 45,346 posts

+497
Excellent

Posted 3 June 2019 - 18:16

And that way it's completely stateless.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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: streamproxy and seeking in file #79 anudanan

  • Senior Member
  • 998 posts

+14
Neutral

Posted 4 June 2019 - 18:19

I don‘t hate statemachines, if they are coded robust for all error situations;-)
Receiver:2 x Uno4k SE (PLI 7.0 rel), 1 x ET9200 (PLI 4.0), NAS: 2 x QNAP 410, TV: LG 65C8llla, LG 47LB570V, LG 42LM615S, Sound: Yamaha RX-v663, Teufel System 5 THX

Re: streamproxy and seeking in file #80 Erik Slagter

  • PLi® Core member
  • 45,346 posts

+497
Excellent

Posted 6 June 2019 - 16:03

It has nothing to do with a state machine.

 

What I mean is that I don't want the server to need to retain any information (state) of the client. Because that will make it less robust. Compare cookes in your browser, because the web server doesn't want to retain state from you as client.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
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.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users