Skip to main content

Proposed MPEOS API to fully support Range/Range.dtcp.com headers

  3 posts   Feedicon  
Replies: 2 - Last Post: May 03, 2012 22:27
by: mkorzen
showing 1 - 3 of 3
Posted: February 14, 2012 21:45 by mkorzen
Currently, there is a problem when an HN client makes a request to the RI HN server and includes Range.dtcp.com header (cleartext domain) for DTCP/IP-protected content. There is currently no API that would allow the stack to perform cleartext byte domain to network byte domain translations for PCP-encapsulated content.

The following proposed change adds various comment clarifications wrt to the API usage and adds one new method mpeos_hnServerGetNetworkBytePosition:

Index: mpe/os/include/mpeos_hn.h
===================================================================
--- mpe/os/include/mpeos_hn.h   (revision 29692)
+++ mpe/os/include/mpeos_hn.h   (working copy)
@@ -465,11 +465,11 @@
  * MPE_HN_CONTENT_LOCATION_LOCAL_VIDEO_DEVICE discriminator.
  *
  * It defines the video device to be used as the content source. When this
- * content type is used as a server-side streaming data source, content rendered to the
- * given video device shall be streamed out via the associated streaming session.
- * This includes content rendered via mpeos_dvrPlayback sessions or
- * mpe_MediaDecodeSession. Trick mode rendering must also be streamed,
- * with allowance for diminished quality and/or framerate.
+ * content type is used as a server-side streaming data source, content
+ * rendered to the given video device shall be streamed out via the associated
+ * streaming session. This includes content rendered via mpeos_dvrPlayback
+ * sessions or mpe_MediaDecodeSession. Trick mode rendering must also be
+ * streamed, with allowance for diminished quality and/or framerate.
  */
 typedef struct _mpe_HnStreamVideoDeviceContentDescription
 {
@@ -532,8 +532,8 @@
  *                   unspecified.
  * useServerSidePacing - Requested serverside paced streaming.
  * frameTypesInTrickModes - Requested frame types for trick modes.
- * supportConnectionStalling - When true, maintain the HTTP connection even when connection
- *                             inactivity is detected
+ * supportConnectionStalling - When true, maintain the HTTP connection even
+ *                             when connection inactivity is detected.
  **/
 typedef struct _mpe_HnStreamParamsMediaServerHttp
 {
@@ -565,6 +565,10 @@
  * with a series of playbacks. Still, at any given point in time of a streaming
  * session, there will only exist one single active playback.
  *
+ * Both specified byte positions will always be passed in network byte domain.
+ * For playbacks that are part of DTCP-enabled server streaming sessions, this
+ * means that requested positions already account for PCP-encapsulation.
+ *
  * contentLocation - Supplies the type of the content description that follows.
  * contentDescription - A reference to a recording, a TSB, personal content
  *                      item, or a tuner.
@@ -956,6 +960,10 @@
  * mpeos_hnServerUpdateEndPosition() adjusts the end byte position of the
  * currently-presenting stream.
  *
+ * The specified byte position will always be passed in network byte domain.
+ * For playbacks that are part of DTCP-enabled server streaming sessions, this
+ * means that requested position already accounts for PCP-encapsulation.
+ *
  * @param playbackSession    Active playback session to be updated.
  * @param endBytePosition    The new end byte position.  A value representing a
  *                           byte position that has already been streamed
@@ -1009,11 +1017,14 @@
         char * profileIDStr, char * mimeTypeStr, int64_t * fileSizeBytes);

 /**
- * mpeos_hnServerGetNetworkBytePositionForMediaTimeNS() should return the total
- * number of bytes of content streamed across the network associated with the
- * supplied content item using the DLNA profile and mime type identified by the
- * supplied strings.
+ * mpeos_hnServerGetNetworkBytePosition() should translate the requested
+ * local byte position into a network byte position for the supplied content
+ * item using the DLNA profile and mime type identified by the supplied
+ * strings.
  *
+ * For non-DTCP profileIDs, this should be a no-op and the returned network
+ * byte position should be the same as the requested local byte position.
+ *
  * @param contentLocation       Indicates content location type such as
  *                              recording, TSB, etc.
  * @param contentDescription    Structure describing content which varies
@@ -1021,6 +1032,44 @@
  * @param profileIDStr          DLNA media format to be used in network
  *                              transfer of this content. The actual profile ID
  *                              string can be prefixed with "DTCP_" string to
+ *                              indicate that the stack is performing byte
+ *                              position translation from cleartext domain to
+ *                              encrypted domain.
+ * @param mimeTypeStr           Mime type to be used in network transfer of
+ *                              this content. The stack will never use
+ *                              "application/x-dtcp1" content format here; in
+ *                              case of DTCP/IP transmissions, the actual
+ *                              "CONTENTFORMAT" value will be conveyed here.
+ * @param localBytePosition     Local byte position to be translated.
+ * @param networkBytePosition   Returns network byte position of content
+ *                              streamed across the network using supplied DLNA
+ *                              profile and mime type settings. The returned
+ *                              network byte position must start at Decoder
+ *                              Friendly Alignment Position as defined by DLNA
+ *                              DLNA Guidelines Volume 2.
+ *
+ * @return MPE_HN_ERR_NOERR            If successful.
+ *         MPE_HN_ERR_INVALID_PARAM    If one of the parameters is invalid.
+ *         MPE_HN_ERR_OS_FAILURE       OS-specific failures.
+ **/
+mpe_Error mpeos_hnServerGetNetworkBytePosition(
+        mpe_HnStreamContentLocation contentLocation, void * contentDescription,
+        char * profileIDStr, char * mimeTypeStr, int64_t localBytePosition,
+        int64_t * networkBytePosition);
+
+/**
+ * mpeos_hnServerGetNetworkBytePositionForMediaTimeNS() should translate the
+ * requested media time into a network byte position for the supplied content
+ * item using the DLNA profile and mime type identified by the supplied
+ * strings.
+ *
+ * @param contentLocation       Indicates content location type such as
+ *                              recording, TSB, etc.
+ * @param contentDescription    Structure describing content which varies
+ *                              depending on content location type provided.
+ * @param profileIDStr          DLNA media format to be used in network
+ *                              transfer of this content. The actual profile ID
+ *                              string can be prefixed with "DTCP_" string to
  *                              indicate that the stack is performing media
  *                              time lookup on PCP-encapsulated content item.
  * @param mimeTypeStr           Mime type to be used in network transfer of


Change details:
- Hunk 1 & 2 just fixes the formatting.
- Hunk 3 adds appropriate wording for the mpe_HnPlaybackParamsMediaServerHttp structure wrt to how the byte position parameters need to be interpreted.
- Hunk 4 clarifies contract for mpeos_hnServerUpdateEndPosition().
- Hunks 5 & 6 add new API mpeos_hnServerGetNetworkBytePosition and clean-up mpeos_hnServerGetNetworkBytePositionForMediaTimeNS (description was a copy/paste from mpeos_hnServerGetNetworkContentItemSize...)
Posted: May 03, 2012 22:27 by mkorzen
There are cases when it would be desirable to send additional data (namely PCP header and/or PCP padding) when Range.dtcp.com seek request happens to align with internal server block packetization scheme. Example:
- Server is applying DTCP/IP encryption with block sizes of 3948 (21 * 188).
- The following streaming request is received "Range.dtcp.com: bytes=3948-7895"
- In the current implementation, the server will send 7895 - 3948 + 1 = 3948 bytes, with the actual bytes (with DTCP/IP encryption applied) ranging from 3980-7927/3948. PCP header and PCP padding will not be sent.

That request happens to be aligned exactly with the start and end of the PCP block. In such case it would be desirable to actually include PCP header and padding in order to return a fully compliant PCP packet. The desired response to the example from above would be to send the following DTCP/IP-encrypted byte range data: 3966-7931/3966.

In order to do this the following MPEOS HN APIs need to be changed:
mpeos_hnServerGetNetworkBytePosition()
mpeos_hnServerGetNetworkBytePositionForMediaTimeNS()

Additional boolean parameter needs to be added that indicates whether the position being queried is the starting position or ending position, as follows:

Index: mpe/os/include/mpeos_hn.h
===================================================================
--- mpe/os/include/mpeos_hn.h   (revision 33223)
+++ mpe/os/include/mpeos_hn.h   (working copy)
@@ -1050,6 +1050,9 @@
  *                              case of DTCP/IP transmissions, the actual
  *                              "CONTENTFORMAT" value will be conveyed here.
  * @param localBytePosition     Local byte position to be translated.
+ * @param isStart               TRUE if the queried media time denotes
+ *                              beginning of content, FALSE if it denotes
+ *                              end of content.
  * @param networkBytePosition   Returns network byte position of content
  *                              streamed across the network using supplied DLNA
  *                              profile and mime type settings. The returned
@@ -1064,7 +1067,7 @@
 mpe_Error mpeos_hnServerGetNetworkBytePosition(
         mpe_HnStreamContentLocation contentLocation, void * contentDescription,
         char * profileIDStr, char * mimeTypeStr, int64_t localBytePosition,
-        int64_t * networkBytePosition);
+        mpe_Bool isStart, int64_t * networkBytePosition);

 /**
  * mpeos_hnServerGetNetworkBytePositionForMediaTimeNS() should translate the
@@ -1088,6 +1091,9 @@
  *                              "CONTENTFORMAT" value will be conveyed here.
  * @param mediaTimeNS           Media time in nanoseconds to query for byte
  *                              position.
+ * @param isStart               TRUE if the queried media time denotes
+ *                              beginning of content, FALSE if it denotes
+ *                              end of content.
  * @param bytePosition          Returns byte position of content streamed
  *                              across the network using supplied DLNA profile
  *                              and mime type settings for the specified media
@@ -1102,7 +1108,7 @@
 mpe_Error mpeos_hnServerGetNetworkBytePositionForMediaTimeNS(
         mpe_HnStreamContentLocation contentLocation, void * contentDescription,
         char * profileIDStr, char * mimeTypeStr, int64_t mediaTimeNS,
-        int64_t * bytePosition);
+        mpe_Bool isStart, int64_t * bytePosition);

 /**
  * Retrieves number/count of supported DLNA profile ID strings that are
Posted: April 19, 2012 17:20 by dhooley
These changes were incorporated into 1.2.2 Rel-A.
Replies: 2 - Last Post: May 03, 2012 22:27
by: mkorzen
 
 
Close
loading
Please Confirm
Close