Skip to main content

Live tuning from DLNA IP client and stream disturbance

2 replies [Last post]
howardteece
Offline
Joined: 2010-06-17
Points: 0

There seem to be some holes when streaming a live service to an IP client when disturbance in the stream occurs. By disturbance I mean tune unlock/lock, CA refusal etc.

Let's consider non-IP behavior first.
When you tune to a live service you do so with a ServiceContext and this can have listeners registered to handle disturbance. This can then be directed to an App that can show an OSD with either 'Please Wait' or 'You need to purchase this' etc. as it turns up as an ACEE.

Now, in an IP client there's no way we can get these events. The IP client doesn't have a context as such and the events aren't trapped by anything in the Stack for forwarding. So there's no way of telling the client that the stream is in trouble. And even if it did, what kind of event would we expect? DLNA? IP side channel?

Now, worse things happen. If you start RiExerciser and tune to the first channel and then publish it in the CDS and then use, for example, wget to start playback with this command:

wget "localhost:4004/ocaphn/service?ocaploc=0x45a&profile=MPEG_TS_SD_NA_ISO&mime=video/mpeg"

You can start streaming to a file, just like a DLNA client. Now, login in to the telnet session and using the tuner diagnostics send an unlock event.
The download stops and closes the socket. That's because it thinks the stream has ended because the end-of-file is seen by the stack and that must mean the data is complete - but no! Not really.

OK, so now put a server side pause in the stream. And then inject an unlock event. And then a lock before the buffering ends and you'll see a bit of discontinuity. What should really happen here? Would we expect the server to fill with black, or join the streams together. And if there were some sort of event, what would it be?

The same can be said for CA Refusal, where the buffering stops when the CableCARD says no and the client reads to the end of the file.

In both cases, the client would expect to be able to rewind back into what they've just been watching.

And when an initial tune is created from the HTTP GET, would we expect a 401 if there's no lock or a CA Refusal or just black an event and then eventually data if it ever became available.

I've tried using the StreamingActivityListener and the provided NetworkInterface, but still can't quite get some way to stitch this all up.

Anyway, just something to think about.

H

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
scottdeboy
Offline
Joined: 2009-02-02
Points: 0

In the scenario you describe, when using a DVR-enabled platform as the server and sending an UNSYNC event via telnet, and an MPE_HN_EVT_END_OF_CONTENT event is received by the stack.

At that point, the server-side 'session' is closed. However, the stack does not close the socket. If chunked encoding was used, an end chunk is sent to the client and the StreamingActivityListener is notified that the stream has ended. The socket remains connected but will not restart transmission of content due to reception of a SYNC event being sent via telnet.

I agree that this may cause endpoints some confusion - media time discontinuities and what appears to be a stalled stream. However, loss of tuner sync, media access authorization and other scenarios which would normally result in AlternativeContentErrorEvent notifications for broadcast services were discussed while the specification changes supporting live channel streaming were being defined. The decision was made to not include language in the specification describing how these failure scenarios must be handled, allowing vendors to provide their own solutions, at least in homogeneous environments.

The socket is only closed due to a call to ChannelContentItem.setTuningLocator(null), the reception of a ConnectionComplete notification, or a call to NetSecurityManager.revokeAuthorization(id).

The stack should not be disconnecting the socket due to reception of an MPE_HN_EVT_END_OF_CONTENT event or when tuner sync is lost - if you see that, please file a bug.

cpratt
Offline
Joined: 2008-12-18
Points: 0

I think there's a fundamental question here that isn't answered by DLNA or OCAP:

Should a content request (e.g. a range request from x-y) be considered "failed" if there's a loss of content or should it just be considered stalled/blocking until content is restored? (or optionally pulling black frames)

Returning a result code allows for the possibility of an error being communicated to the client. But there isn't a good way for a client to know when a new request can be submitted after this. Blocking/resuming or sending black content seem to have a higher probability of working with most clients (including your wget example above)...