i.MX8M DRM Widevine L1 on Disney+

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX8M DRM Widevine L1 on Disney+

1,783 Views
alexchoo
Contributor I

Hi @arunbaskar_gnanapragasam and community

We have been testing the Widevine L1 DRM on i.MX8M for a while. We came across issue with L1 playback with Disney+ app.  We have done lots of testing and code trace on this issue and also perform oemcrypto test as instructed by NXP. So far, the playback still failed. 

We have been comparing the code path between Google exoplayer L1 test stream, Disney+ L3 stream and Disney+ L1 stream and found that the issue seems to reside at the VPU decoding process. We have included the log in the this post and hopefully to get more information on how to over come this issue. 

Disney+ stream is encoded with H.264 and we use H.264 stream from Google exoplayer to do the comparison. 

The error occurs when the decoder attempt to perform access unit boundary check which in turn call h264bsdCheckPpsId(), when attempting to do ExpGoLomb decoding of the first macroblock slice

h264hwd_decoder.c: h264bsdDecode() -> h264bsdCheckAccessUnitBoundary()
h264hwd_storage.c:  h264bsdCheckAccessUnitBoundary() -> h264bsdCheckPpsId()
h264hwd_slice_header.c: h264bsdCheckPpsId() -> h264bsdDecodeExpGoLombUnsinged() 

snippet.jpg

The error will first seen when system attempt to work on coded slice of and IDR picture (NAL Unit type:5) and of course it also failed in subsequent coded slice of non-IDR picture (NAL Unit type: 1)
see log disney_wv1.log line#1087 ,  where the stream data shouldn't be 0x0. 

When the playback were done with exoplayer L1 stream,  the decoding process are the same, except that the google L1 did not encounter these issue.  see log google_l1.log line #420

When we force Disney+ to play with L3, the same decoding process run without issue.  see log  disney_wv3.log line#717

There is no NALU parsing error notice during the decoding process. It is possible that somehow the stream buffer get corrupted leading to value 0x0 left for stream buffer data. We need NXP support to clarify this issue. We will continue to investigate around the stream data. Thanks.

0 Kudos
Reply
3 Replies

1,754 Views

Hi Alex,

Could you please share the Disney+ H.264 stream that you have encoded and used it for your testing. In addition to that, can you also provide the data dump of tmp_strm_data, which is the input to the h264bsdDecodeExpGoLombUnsinged() function where you are reporting the issue.

Since we don't have the same setup and app to reproduce the issue, the above two data will help us triage the issue and provide proper inputs.

Thanks,

Arun Baskar

0 Kudos
Reply

1,774 Views

Hi Alex,

Good to know your progress made so far with regards to Android Widevine L1 playback using your platform based on 8MQ. 

With regards to the problem that you have mentioned with Disney+ App, we are not sure how much we can help as we don't have a means to reproduce the issue using our EVK platform.

But since you have shared some logs along with comparison with Exoplayer playback where you do see the problem, I will share this information with our DRM team and try to get their inputs. 

Kindly provide me few days to get back on this issue.

 

Thanks,

Arun Baskar

 

1,742 Views
alexchoo
Contributor I

Hi Arun, 

Thanks for getting back so quickly. We are attempting to determine when the stream data become zero. The stream data input to h264bsdDecodeExpGoLombUnsinged() for Disney+ L1 is zero. We have dump the slice data bytes (tmp strm data) for pic id 0  per request and for Disney+ L1 all bytes are 0x0. 

Thanks,
Alex

0 Kudos
Reply