Failing to stream live HLS w/ TS & transmuxing

[avelad]

Raised in #740 (comment)

We parse the TS segments to get their timestamps, since HLS doesn't provide that information. However, as far as I can tell, the MP4 output from mux.js has different timestamps than what we parsed from the TS segments. So the MediaSource timeline doesn't line up with the Player's seek range.

[joeyparrish]

Repro URL from original comment: https://nightly-dot-shaka-player-demo.appspot.com/demo/#asset=https://cdn.demo.anevia.com/live/nas40/Arte/mirada_test/Arte.m3u8;lang=es

[joeyparrish]

With some local hacks to adjust MediaSource SourceBuffer offsets to compensate for the bad output from mux.js, I can play the above stream. I need to raise the issue with mux.js to see if there is a way we should be configuring it to give us unmodified timestamps.

[joeyparrish]

Filed videojs/mux.js#168 to get support from mux.js.

[joeyparrish]

We have a work-around now. I'm asking mux.js folks for a configuration for this to make it a little easier, but we can move forward in the mean time.

[thedracle]

So- I am seeing this issue where the timestamps output by muxjs are different than my TS segments when the presentationTimeOffset isn't 0.

Basically my first MPEGTS segment starts at 133500:

        {
            "media_type": "video",
            "stream_index": 0,
            "key_frame": 1,
            "pkt_pts": 133500,
            "pkt_pts_time": "1.483333",
            "pkt_dts": 133500,
            "pkt_dts_time": "1.483333",
            "best_effort_timestamp": 133500,
            "best_effort_timestamp_time": "1.483333",
            "pkt_duration": 3750,
            "pkt_duration_time": "0.041667",
            "pkt_pos": "564",
            "pkt_size": "10638",
            "width": 320,
            "height": 240,
            "pix_fmt": "yuv420p",
            "sample_aspect_ratio": "1:1",
            "pict_type": "I",
            "coded_picture_number": 0,
            "display_picture_number": 0,
            "interlaced_frame": 0,
            "top_field_first": 0,
            "repeat_pict": 0
        }

In the logs I see:

First segment 750k.ts starts at 1.4833333333333334

Which matches the first PTS (Although there is an earlier PTS for the first audio packet in the stream which appears later).

The presentationTimeOffset is set to 1.4833333333333334, but the code to adjust the PTS via the transmuxer sets it to adjust by 0:

lib/media/transmuxer.js:

this.muxTransmuxer_.setBaseMediaDecodeTime(startTime * timescale);

^ Tracing in the debugger 'startTime' is 0.

As a result the transmuxed mp4 seems to adjust all of the timestamps:

        {
            "media_type": "video",
            "stream_index": 0,
            "key_frame": 1,
            "pkt_pts": 7500,
            "pkt_pts_time": "0.083333",
            "pkt_dts": 7500,
            "pkt_dts_time": "0.083333",
            "best_effort_timestamp": 7500,
            "best_effort_timestamp_time": "0.083333",
            "pkt_pos": "2877",
            "pkt_size": "28480",
            "width": 640,
            "height": 480,
            "pix_fmt": "yuv420p",
            "sample_aspect_ratio": "1:1",
            "pict_type": "I",
            "coded_picture_number": 0,
            "display_picture_number": 0,
            "interlaced_frame": 0,
            "top_field_first": 0,
            "repeat_pict": 0
        },

And MediaSourceExtensions croaks with the following error:

video frame with PTS 141667us has negative DTS -66667us after applying timestampOffset, handling any discontinuity, and filtering against append window

Also, I wonder if getStartTimeFromTsSegment_ in lib/hls/hls_parser.js needs to be adjusted to search for a minimum timestamp closer to the beginning of the TS stream, rather than just reading the PTS out of the first TS packet it finds that has one.

[TheModMaker]

Please post a new issue for this.