Drawing issues on first fragment in version 0.4+

[dtniland]

It seems like there is some sort of corruption or error that somehow stops the drawing of the first fragment of video from our encoding service. If you play: http://pmd205470tn.download.theplatform.com.edgesuite.net/PDK_Demo/734/401/Toy_Story_3.m3u8
in any of your reference players, you'll see a strange affect where if hardware is turned on, it will show half of the opening frame with the other half black, green, or often even an image from prior video that may have been left in the hardware buffer. If hardware is turned off (via enableStageVideo = false in OSMF) then it just won't play the first fragment.

I've tried adjusting several of the HLSSettings of your plugin, but nothing seems to make a difference.

We've noticed that the same issue does not affect any of the test media on your site. It is affecting many of the media that we've encoded through our encoding service however. These same media played fine up through flashls version 0.3.7 and we may be forced to revert to that version for our clients.

If there is some encoding setting that is causing the error, we can possibly addess that on our end -- if we know what the issue is.

As always, thank you for your efforts.

[mangui]

@dtniland
your video is working with v0.4.0.5 but broken since v0.4.0.6
http://flashls.org/flashls-0.4.0.5/examples/osmf/GrindPlayer.html?src=http%3A%2F%2Fpmd205470tn.download.theplatform.com.edgesuite.net%2FPDK_Demo%2F734%2F401%2FToy_Story_3.m3u8

http://flashls.org/flashls-0.4.0.6/examples/osmf/GrindPlayer.html?src=http%3A%2F%2Fpmd205470tn.download.theplatform.com.edgesuite.net%2FPDK_Demo%2F734%2F401%2FToy_Story_3.m3u8

same on your side ?

[mangui]

i am going to dig into the diff
v0.4.0.5...v0.4.0.6

[mangui]

ok it also works with v0.4.1.1 if JSLoader is enabled.
most probably the issue deals with the optimization I did around TSDemuxer.
it looks like your TS stream is a bit broken:

WARN:TS: late PMT found, rewinding at beginning of TS
WARN:TS: lost sync between offsets:597/752

I am suspecting the optimization I made are not robust to these kind of errors.

[mangui]

mm the issue was related to the fact that your TS stream contained an unknown PID, and while optimizing the TS demuxer, i slightly changed the way to handle unknown PID. this should now work as before.
this unknown PID is a famous one ... 0x1fff is used for null packets: refer to https://en.wikipedia.org/wiki/MPEG_transport_stream#Null_packets , as you can see these packets are used for padding in broadcast equipment, and thus are not expected in HLS stream, as it is a waste of bandwidth.

cheers,
Mangui

[dtniland]

Thanks, mangui, I'll check it out.

[dtniland]

Thanks, that fixed it.