[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 #7 from Bob Lund <b.lund@cablelabs.com> ---
(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.
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 Monday, 8 September 2014 22:44:27 UTC