[WIP] Add edit box support to offset PTS

[drichards]

Made an initial stab at of the edit box changes discussed in #9, however it doesn't seem to make much difference to stream startup in safari, so possibly I'm doing something wrong.

Thoughts I have about this:

• there's a bunch of modifications of start PTS times happen in remuxVideo/Audio after the initial segment has been generated, is it possible that discrepancies there are causing problems?
• it's possible I'm just implementing the edit box logic incorrectly when writing out the bits, I was primarily referencing these two documents for implementation http://l.web.umkc.edu/lizhu/teaching/2016sp.video-communication/ref/mp4.pdf http://xhelmboyx.tripod.com/formats/mp4-layout.txt

[mangui]

Hi @drichards tks for this PR

refer to the spec, u need 4 bytes for segment duration and 4 bytes for media time

aligned(8) class EditListBox extends FullBox(‘elst’, version, 0) {
 unsigned int(32) entry_count;
 for (i=1; i <= entry_count; i++) {
 if (version==1) {
 unsigned int(64) segment_duration;
 int(64) media_time;
 } else { // version==0
 unsigned int(32) segment_duration;
 int(32) media_time;
 }
 int(16) media_rate_integer;
 int(16) media_rate_fraction = 0;
 }
} 

i did some preliminary tests some months ago on a local branch, with hardcoded offset for the audio track ... just to give it a try (before computing the offset as u did in mp4-remuxer) and using i could avoid glitches with Safari.

[kanongil]

@drichards I'm pretty sure you are doing it wrong. As far as I can tell, the duration should be 0, and the media time is the configurable part (which you set to -1 / 0xffffffff for some reason).

[drichards]

Reading through the spec here http://l.web.umkc.edu/lizhu/teaching/2016sp.video-communication/ref/mp4.pdf

Starting offsets for tracks (streams) are represented by an initial empty edit. For example, to play a track from
its start for 30 seconds, but at 10 seconds into the presentation, we have the following edit list:
Entry-count = 2
Segment-duration = 10 seconds
Media-Time = -1
Media-Rate = 1
Segment-duration = 30 seconds (could be the length of the whole track)
Media-Time = 0 seconds
Media-Rate = 1

That seems to say that an offset should be specified by a duration (first 4 bytes after the number of entries bytes) with a media-time of -1 (next 4 bytes). In #9 @jernoble also discussed "empty edits" which are specified using a media-time of -1.

I tried changing the offset to be in the media-time field and set the segment duration to 0. That seems to have avoided the stuttering poster image but doesn't fix the problem for two reasons

• the video still doesn't play most of the time
• it cuts off the first several frames of the video

The second of those indicates to me that potentially the calculation for the offset is being done wrong, but it still doesn't seem to agree with how the spec presents edit box offsets.

[mangui]

Hi @drichards , I slightly adjusted your logic on elst branch
main thing was to take into account track timescale.
you can check it here: http://streambox.fr/mse/hls.js-elst/demo, behaviour with Safari is much better
feedback welcome

[drichards]

Looks good to me. Looks like there's a couple of console.logs in there that I imagine you'd want to clean up/replace with logger.log

[drichards]

One more on line 513 of mp4-generator

[drichards]

Looking at that demo branch it looks like Safari is also tacking on a range header to the ts file requests, which is forcing a preflight CORs request. Presumably unrelated to this, but it doesn't appear to happen on the 0.6.2-1 demo page

[mangui]

ok I am suspecting it might be related to https://github.com/dailymotion/hls.js/pull/559

[mangui]

should be fixed now
http://streambox.fr/mse/hls.js-elst/demo/

[phloxic]

Only the buck bunny video plays for me, the others load, but I can't convince the player to start - and with 'pipe dream' safari freezes and/or becomes unresponsive (beach ball etc.)
This one works, but only after quite a few bufferSeekOverHole's at the beginning.

[mangui]

Yes ... one step further... but how many steps left ? :-/

[phloxic]

@mangui - considering that this is a blindfolded reverse-engineering/guessing process with an extremely loose (TS) spec it's good progress ;-)

[johnBartos]

Closing this due to lack of activity