79 replies to this topic

[anudanan]

for direct streaming I think the thread must be started dynamically like fork or fork using is ok for live streaming (because there is noch HW count limit as it is by transcoding)

 

But a parallel handling of fork and threads is not easy

Edited by anudanan, 5 March 2019 - 10:14.

[anudanan]

@erik:

is there a possbilitiy to clear only the encoder buffer without a complete  close and a new open of the encocer device?

The idea ist to clear after a new file-seek to the old movie data inside the encoder, so that seek is fast than today in my poc (acutally I see some seconds from the old position after seeking)

[anudanan]

new PoC code with starting the threads on demand without polling the joblist

 

acualle only broadcom transcoding is implemented for file and live streaming

 

no enigma transcoding and no file and live streaming without transcoding is implemented

Edited by anudanan, 5 March 2019 - 22:39.

[anudanan]

I´ve include now the transcoding enigma methode in threads, but seeking ends the session. I can't test it, i´have no box for that

 

only direct streaming is a open thing and I don´t know if it is needed or not

[Erik Slagter]

@erik:

what does streamproxy with direct streaming? In the code there are line for that but I haven´t use it in the past.

The way most applications use streamproxy is in a compatibility fallback mode. See the streamproxy.conf for the default actions on defined ports.

 

If the streamproxy is controlled with native commands, you can request to have either live streaming, file streaming, live transcoding or file transcoding on any port it's listening on.

 

But all existing applications use port 8001 for streaming, which is handled by enigma2 itself so will never be passed on to streamproxy.

[Erik Slagter]

@erik:

Is it neccessary to integrate the direct streaming without transcoding also in streamproxy with threads?

In my PoC these functions are not ready for use

 

If yes, I can do it, but acutally I don´t know, if anyone need this

I dont' want to drop this feature.

[Erik Slagter]

@erik:

is there a possbilitiy to clear only the encoder buffer without a complete  close and a new open of the encocer device?

The idea ist to clear after a new file-seek to the old movie data inside the encoder, so that seek is fast than today in my poc (acutally I see some seconds from the old position after seeking)

I think the ring queue (I assume you mean the buffer internal to streamproxy and not the buffer within the drivers/transcoder) isn't that big it's an issue. If you want to clear it, that's simple, just call the "reset" method on it.

[Erik Slagter]

The streaming, which should be unlimited, needs indeed quite a different approach from transcoding, which is always limited to one or two session.

That's why I said we need to think about this.

 

A proper approach might be to drop the fork() altogether and use threads instead, it may not be that much work. Then for transcoding always use one thread. If another transcoding requests comes in, drop the current transcoding connection and continue on the new connection. For streaming threads, do actually spawn a new thread.

 

This will mean only one transcoding session can be started, even if the receiver supports two. That's not a big deal as it seems:

- most receivers have limitations on when a second transcoding session can be used (e.g. receiver needs to be in standby, source needs to be < UHD, or PiP needs to be off)

- for the die-hard transcoders, they could run a second instance of streamproxy on an alternative port

 

This would make the design a lot less complex.

 

When I first started streamproxy, quite a few years ago, it wasn't clear at all what transcoding capabilities future receivers would have. They might have ten transcoders or more, who knows. Now we know there are no receivers that more than two transcoders and even then they're limited.

Edited by Erik Slagter, 7 March 2019 - 20:36.

[Erik Slagter]

I´ve include now the transcoding enigma methode in threads, but seeking ends the session. I can't test it, i´have no box for that

You can always test it. AFAIK enigma transcoding will fall back to streaming if no encoder is found.

[anudanan]

Thx for your explanations

 

 

@erik:

is there a possbilitiy to clear only the encoder buffer without a complete  close and a new open of the encocer device?

The idea ist to clear after a new file-seek to the old movie data inside the encoder, so that seek is fast than today in my poc (acutally I see some seconds from the old position after seeking)

I think the ring queue (I assume you mean the buffer internal to streamproxy and not the buffer within the drivers/transcoder) isn't that big it's an issue. If you want to clear it, that's simple, just call the "reset" method on it.

 

 

I have reset the softwarequeue but I think there are buffers in the drivers/transcoders which store some seconds from the older frames before seeking which goes to the client via the new socket.  I have made some tests to reads them from encoder before putting new data to the encoder but it doesn´t work properly 

[Erik Slagter]

That may very well be possible.

 

Don't forget the pipeline includes two circular queues. One between the demux and the transcoding input and one between the transcoding output and the http client.

[anudanan]

which demux queue do you mean by filetranscoding. I see the demux handling in the transcoded live stream source but where is it in transcoded file streaming source? I see the read of the file without a queue and the write in the encoder ans the read from the encoder and the queue write to the socket

[Erik Slagter]

The demux is only used for live streaming and transcoding. For file streaming and transcoding, it's not necessary, there are only pids in that belong to one program.

[anudanan]

I have the same view. Then the rest frames must be in the driver because after seeking in the moviefile I make a reset of the queue between encoder and socket but the client gets 5-6 seconds older frames and then the new frames from the seek position

 

I´ve tested to stop the encoder,then draining the frames and starting the encoder but that need extra time before running. The user has than a black screen for some seconds instead of old frames. I think it is not possible to speedup that behavier. 

[anudanan]

I´ve have finished my work with the threads. All streamings (file, live, direct or transcoding) are now thread based

 

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

[anudanan]

@Erik:

Do you have documentations of all driver functions for the encoder (ioctl etc). I would like to search about some ideas to speedup the seek operation by deleting the old frames which must be in the driver buffers. I hope there is a methode (ioctl option) to delete the old buffer content without a  complete stopping and restarting the encoder chip.

[Erik Slagter]

Can't help here. There is NO documenation, I found this by reverse engineering other code. I can tell you there are no other ioctl's than these, this is what we'll have to do it with. It would be very much better if we had more finegrained control of the process, but simply there isn't. When a stream is running, there are two possibilities; either you do a skip in the same stream and you might get away with just dropping all packets in between, I hope the transcoder doesn't get confused due to a range of timestamps missing and part of frames are missing (hard to avoid). Or you setup a new transcoding request which will take 10-12 seconds. There are no other options.

 

I am still very much in favour of "kiss", limiting one instance of streamproxy to one transcoder and simply abort a currently running stream when another request comes in. When the service is the same, the transcoding may not be needed to be setup again.

[anudanan]

That is what my modified strreamproxy does. It works without a new setup of the hardware but after seeking to the new position in the movie file it needs 5-.7 seconds in which a user continous watching from the older postion until the swtich  to the new position in the streaming client it there. But it works better that in the past.

 

.

Edited by anudanan, 9 May 2019 - 09:14.

[Erik Slagter]

That is indeed probably better. But I'd like to see what happens if you don't stop the transcoding and start feeding packets from another point in the file. It may work (or not).

[anudanan]

My last modified streamproxy doesn´t stop transcoding. It only flushes the outgoing queue to the client socket and seeks to the new position of the moviefile, and continous the loop. No ioctl to the trancoding hardware. it works.