[Bug 26738] "ISO Common Encryption EME Stream Format and Initialization Data" should be extended for MPEG-2 TS CENC

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26738

--- Comment #10 from Bob Lund <b.lund@cablelabs.com> ---
(In reply to Bob Lund from comment #7)
> (In reply to David Dorwin from comment #6)
> > (In reply to Bob Lund from comment #5)
> > > (In reply to David Dorwin from comment #4)
> > > > (In reply to Bob Lund from comment #3)
> > > > > David, the CENC MPEG-2 TS carries concatenated PSSH boxes identical to
> > > > > the BMFF case.  23001-9 section 5.2.1 says:
> > > > > 
> > > > > 5.2.1    General
> > > > > 
> > > > > A CETS PSSH packet carries the complete payload of a `pssh` box, as
> > > > > defined in ISO/IEC 23001-7. Each packet uses private syntax and carries a
> > > > > `pssh` box along with an MD5 hash for integrity.
> > > > 
> > > > Thanks. Questions about the above text:
> > > > * "payload of a... box" seems a bit ambiguous as to whether it is the entire
> > > > box or something within it.
> > > 
> > > It is the entire contents of the PSSH. The 'cets_pssh_packet' contains a
> > > 'pssh_box()' field defined in  23001-9 section 5.2.3 as "pssh_box: complete
> > > `pssh` box, as defined in ISO/IEC 23001-7".
> > > 
> > > > * The spec only supports one PSSH box per packet? Can there be multiple CETS
> > > > PSSH packets to support multiple System IDs?
> > > 
> > > Yes, PSSH for each system is carried in a separate PID.
> > 
> > How are the PIDs determined? If the PIDs are different for different System
> > IDs, how does the user agent know which PIDs contain PSSH boxes?
> > 
> 
> The transport stream contains a 'CA_Descriptor' (section 5.3) where
> 'num_systems' defines the number of system ID's,'encryption_algorithm' which
> specifies the encryption algorithm, same as `tenc`.IsEncrypted. There are
> 'num_systems' entries in 'encryption_algorithm'. Each entry contains the
> fields: 'system_id': same as `pssh`.SystemID and 'pssh_pid': PID on which
> `pssh` box(es) can be found for this content protection system
> 
> > > > * Would the `pssh` box be stripped from the packet and provided in the
> > > > "encrypted" event? (Answers to the above questions may add complexity here.)
> > > 
> > > The UA would provide the contents of the 'cets_pssh_packet.pssh_box()'
> > > field, i.e. the exact same PSSH box contents , as in the CENC ISO BMFF case.
> > 
> > In the ISO BMFF case, the PSSH boxes for all System IDs are concatenated in
> > the container and can easily be extracted and used in a single "encrypted"
> > event.
> >
> > For MPEG-2 TS, the user agent would need to collect the PSSH boxes from each
> > CETS PSSH packet, determine that there are no more CETS PSSH packets for
> > this location, and concatenate the PSSH boxes into a single "encrypted"
> > event. Is it possible to collect PSSH boxes and determine when there is a
> > "complete set" as I have described?
> 
> Yes. 'CA_Descriptor' contains all System IDs and associated PIDs which
> identify where to look for PSSH to concatenate in the "encrypted" event.
> 
> > 
> > > > * Why does the packet have a private syntax?
> > > 
> > > The packet syntax is not "private". It is defined in ISO/IEC 23001-9 which
> > > is available under exactly the same terms as CENC ISO BMFF ISO/IEV 23001-7. 
> > 
> > I was referring to "Each packet uses private syntax" from the quoted text in
> > 5.2.1 (comment #3). Why does 23001-9 say the syntax is "private" if it
> > defines it?
> 
> Ah, I wasn't clear on your question. MPEG-2 TS defines 'private' to mean
> anything not defined by the MPEG-2 specs, but defined elsewhere. In this
> case the cets_pssh_packet() uses private syntax defined within 23001-9. The
> MPEG-2 system spec defines a couple of ways private data can be carried in a
> transport stream. It is not completely clear in 23001-9 what mechanism the
> author intended. I will find that out and suggest that 23001-9 be clarified.


Here is clarification from the author of 23001-9 regarding how the
'cets_pssh_packet()' is carried in the MPEG-2 transport stream.

The carriage is using TS payloads (i.e., it is neither PES nor tables). The
parsing process is:

1) Collect packets from the first packet with PUSI=1 till (not including) next
packet with PUSI=1.

2) Concatenate the payload.

3) Result is 32 bits ('md5_flag' and 'reserved') followed by complete `pssh`
box (including all fields inherited from Box), optionally followed by 128-bit
MD5.


> Nonetheless, the outcome of that doesn't change that the
> 'cets_pssh_packet()' would be processed by the UA according to the syntax in
> 5.2.1.
> 
> > 
> > > > How is the user agent supposed to know how to parse it?
> > > 
> > > By purchasing the spec. Here is the link:
> > > http://www.iso.org/iso/catalogue_detail.htm?csnumber=63440
> > 
> > I was referring to a "private syntax", which I interpreted as not being
> > defined in the spec. See above.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 9 September 2014 14:55:00 UTC