edash-packager does not handle mp2t streams with cropping correctly

[shaka-project]

edash-packager does not handle mp2t streams with cropping correctly

[kqyang]

Some more background of the issue:

H.264 typically has a macroblock size of 16x16. Cropping is necessary if width/height are not exactly disivible by 16. For example, for 320x180 resolution, it can be achieved with pic_width_in_mbs_minus1 = 19, pic_height_in_map_units_minus1 = 11, frame_crop_bottom_offset = 6.

ISO/IEC 14496-15:2004 5.3.7 Visual width and height

The width and height fields in a VisualSampleEntry must correctly document the cropped frame dimensions (visual presentation size) of the AVC stream that is described by that entry.

With incorrect width and height values in VisualSampleEntry, Chrome is not able to decrypt and decode the frames correctly, causing playback issues for some resolutions. (Chrome seems to handle unencrypted contents well even with incorrect width/height - Our guess is Chrome h.264 decoder is robust against these size discrepancies and the CDM's decoder is not).

[kqyang]

Fixed in 3a5fdd2