Multi-period with presentationTimeOffset can overwrite previous period

[tjber]

Hi,

Continued with [https://groups.google.com/forum/#!topic/shaka-player-users/2RK662rDMk8]

I didn't try to play it with the master.
I have used the demo application of version 2.2.4 in chrome and firefox

I have a system in which I will receive a series of video files containing a number of black frames at the beginning.
Currently the process to play those files is to transcode them to remove those frames and start playing from 0, but I'd like to skip this step.
So, I tried to use the presentationTimeOffset attribute in the mpd file.
<SegmentBase indexRangeExact="true" indexRange="" presentationTimeOffset="" >

The problem is that I need frame accuracy and it seems that this attribute only has second precision.
I have tried several combinations with this attribute and the timeScale without success. Dash especifications says :

presentationTimeOffset : The value of the presentation time offset in seconds is the division of the value of this attribute and the value of the timescale attribute.

but I get the feeling that this attribute is not being taken into account.

I attach the mpd file I'm testing with.
dash.mpd.txt

I have updated in dropbox the files with which the issue can be played back, and I have added a file in which you can see the expected result (expected_file.mp4) https://www.dropbox.com/sh/zfbynu6n9bxhd9q/AAB4TEvA9g71UADgne0pqwKia?dl=0

What I would like to do is to skip the initial frames (marked with a white counter) and that the playback starts in frame marked with the TC 00:00:00:00 of the file with the green TC, after that, in the second period skip the initial frames again and that the playback starts in frame marked with the TC 00:00:00:00 of the file with the red TC.

Currently if I try to jump 3.12 seconds actually a jump of 4 seconds is made, so for the first period the playback starts at TC 00:00:00:22 instead of 00:00:00:00 and the second period does not jump at all.

If I can change some of the manifest file to make this work, any ideas will be welcome.

Thank you in advance.
TJ

[TheModMaker]

First, presentationTimeOffset must be an integer, so the value 3.12 is invalid. You can use the timescale attribute to get decimals, but it should match the timescale in the media. So if the timescale is 100, then the presentationTimeOffset would be 312.

It also looks like we aren't handling the presentationTimeoffset value correctly with timescale. I'm marking this a duplicate of #1099.

[joeyparrish]

@tjber, when #1099 is fixed (soon), you should try again with the presentationTimeOffset field set with respect to timescale. Please follow along on #1099. Sorry for the confusion.

[joeyparrish]

If you are still having issues after #1099 is fixed, we can reopen this issue and try again. Thanks!

[joeyparrish]

The fix for #1099 has been pushed to the master branch.

[tjber]

I'll test it and come back with the results.
Thank you very much!

[tjber]

Hi!
I've tried again, both with the Demo app and the master.

The timescale attribute is already taken into account in the SegmentBase, but frame accuracy is not yet possible, it only jumps from second to second.
I mean, with these values:
<SegmentBase indexRangeExact="true" indexRange="915-1138" timescale = "100" presentationTimeOffset="212" >
Playback starts at second 3, not 2,120.

Also, If the manifest has more than 1 period, the presentationTimeOffset is only taken into account in the first period, playback of the following periods starts in the second 0.

This is the mpd file i used for testing.

dash.mpd.txt

Thanks!

[TheModMaker]

Without a playable URL to test with, it will be hard to diagnose the problem. You can send it to shaka-player-issues@google.com if you can't post it publically.

My guess (without being able to look at the content) is that there is a keyframe at 3 seconds. When we set the presentationTimeOffset, this changes where the media time 0 is. The browser will drop any frames that appear before time 0. If the first frame after 0 is not a keyframe, the browser won't be able to decode it so it will discard those frames until it hits a keyframe.

[tjber]

Hi,

@TheModMaker , I've tried your guess and it's good. I have generated a file in which all the frames are keyframes and so it is positioned correctly.
Unfortunately, in my case it's not a valid solution because I won't be able to regenerate the files, so I'll need to find a workaround.

The playback of the second period still does not take into account the presentationTimeOffset, even with these new files.

I've added the regenerated materials and the two manifests I've tested with to the dropbox folder:
https://www.dropbox.com/sh/zfbynu6n9bxhd9q/AAB4TEvA9g71UADgne0pqwKia?dl=0
dash. mpd --> manifest that I've been doing the tests
dash_allkeyframes. mpd --> manifest that refers to regenerated files in which all frames are keyframes
(you can download and use them freely, they are a replica of my original files that I created to document the issue)