wvtt segments do not cover the entire period

[joeyparrish]

In your vectors, there are not enough wvtt segments to cover the entire Period. For example, in the MultiDRM vector, Representation #12 stops after 142 segments. Duration is 4000, timescale is 1000, so this is 568 seconds into the Period. The Period duration is 734 seconds.

We would expect there to be wvtt segments to cover the entire Period. Instead, we request segment 143 and get an HTTP 404 error.

Segments in which there is no text to display should contain a vtte box inside the mdat, and nothing else. Segment 1, for example, does exactly that.

[sandersaares]

Will be corrected in next update to the test vectors. Thanks for the report!

[joeyparrish]

Thanks for responding! Since this is causing some of our tests to fail, can you give me a rough estimate of when the next update will be? (Days, weeks, months?) If it's going to be a while, I may want to temporarily disable the affected tests until then.

[sandersaares]

I estimate the update will take place by the end of the month if not sooner. We were holding on it for a bit to see if the CMAF standardization effort by MPEG introduced any new factors into the subject matter that we should consider in our test vectors to ensure they are compatible with CMAF but that track appears to be running slow over the summer, so I think we will do the update soon regardless.

Do note that such content (with some representations "ending early", leading to 404s) is the normal state of DASH videos produced by the mp4box packager, so they are quite likely to be found in the wild. Not valid DASH but still has a compatibility impact - people looking for a free DASH packager might end up with mp4box and be surprised that such content does not play.

[joeyparrish]

Then we may end up filing a bug against MP4Box as well. Thanks!

[sandersaares]

See also https://github.com/gpac/gpac/issues/521 for a related discussion on mp4box.

[joeyparrish]

Oh, wonderful. Thanks for the link!

[sandersaares]

@joeyparrish - we have a preview of the updated test vectors available at https://github.com/Axinom/dash-test-vectors/tree/v7. It is not yet pushed to master, as we are currently validating the assets to ensure that they contain no errors. If you have any comments, I would be most interested to hear them!

For the v7 test vectors, we have changed quite a lot in order to bring the data set up to more modern standards. For example, subtitles are now provided in both WebVTT and ISMC encodings, and video is provided both in H.264 and H.265 encodings.

[joeyparrish]

The new text streams now cover the whole period. Thanks! The v7 vectors have exposed a couple of small bugs in Shaka v2, so we are correcting those now.

Should I wait until you push to master, or would it be alright for me to update our demo assets to point to v7 now?

[joeyparrish]

Actually, these are not all working for me yet. I'm having issues with a couple of them. I will double-check my test setup in case I've done something wrong.

[sandersaares]

The URLs of the videos are final - the only adjustments to be expected are any bugfixes in case validation indicates that there are some errors in the content (which we'll just fix in-place, by replacing the files, if we catch it before pushing to master). I imagine it should be safe to update your URLs to these if they look defect-free to you.

[joeyparrish]

For some reason, the encrypted audio streams are not working for me on Chrome for Linux, Mac, or Windows. If I ignore the audio streams, the video plays fine. This is the case on v7-MultiDRM-SingleKey, v7-MultiDRM-MultiKey, and v7-MultiDRM-MultiKey-MultiPeriod. (For v7-MultiDRM-MultiKey-MultiPeriod, I can play the unencrypted audio (et-ET) in period 1.)

The log from the Chrome media pipeline on Linux is:

Timestamp	Property	Value
00:00:00 00	pipeline_state	kCreated
00:00:00 00	event	WEBMEDIAPLAYER_CREATED
00:00:00 00	url	blob:http://localhost/78a2a94f-a39c-4b30-8c65-8aeb9c1246a7
00:00:00 00	pipeline_state	kInitDemuxer
00:00:00 46	duration	1468
00:00:00 56	info	Audio codec: mp4a.40.2. Sampling frequency: 48000Hz. Sampling frequency(Extension): 0Hz. Channel layout: 3.
00:00:00 56	found_audio_stream	true
00:00:00 56	audio_codec_name	aac
00:00:00 56	pipeline_state	kInitRenderer
00:00:00 57	error	Append: stream parsing failed. Data size=66150 append_window_start=0 append_window_end=734.04
00:00:00 58	pipeline_state	kStopping
00:00:00 58	pipeline_state	kStopped
00:00:00 60	pipeline_error	chunk demuxer: append failed

The content plays correctly on Edge w/ PlayReady. If it would be helpful, I can put together a demo with Shaka Player.

[sandersaares]

Aha, I smell a rat! It would seem that the codec is marked as mp4a.40.2 in the manifest, indicating AAC-LC. In fact, the data inside is HE-AACv2, so this is wrong. I believe that should be mp4a.40.29. Will try to reproduce the issue, get the manifests fixed and see if that sorts it out!

Edit: no, actually the data inside might actually be AAC-LC?! It is certainly supposed to be HE-AACv2. Will dig into this deeper. Meanwhile, a demo of the problem with Shaka Player would definitely be helpful in speeding up the investigation, yes.

[sandersaares]

Indeed, the audio tracks are corrupted to various extents. We will re-do the audio streams for the test vectors.

[sandersaares]

The updated audio tracks are currently being uploaded, should be available in an hour or so. I was not yet able to validate with Shaka Player, though - will await your feedback/demo or failing that, will try tomorrow to set up Shaka Player and see the issue myself.

[joeyparrish]

A quick smoke test passed. I'm running more detailed tests on various browsers now.

[joeyparrish]

Sorry, I accidentally smoke tested v6. I'm still getting failures on v7 in Chrome. I'm also getting a PlayReady error on Edge: 8004b896.

Here's a demo you can use to quickly reproduce: http://axinomv7.shaka-player-demo.appspot.com/demo/

[sandersaares]

PlayReady+Edge appears to require a PlayReady PSSH box in the initialization segment of audio streams. I will report this defect to Microsoft.

[sandersaares]

For Chrome - the file appears perfectly valid, so I am calling this a Chrome defect pending evidence to the contrary.

Comparing to v6 test vectors and trying various transforms on both sets of data, the crucial difference I see is that (due to tooling version updates) v7 signals the use of subsample encryption also for the audio tracks (it is always used for the video tracks), though this signaling is a bit of a no-op as it signals 0 bytes of clear data all the time (everything in the audio track is encrypted). This signaling appears in conformance to CENC, so all seems right and proper there.

[sandersaares]

And, finally, Firefox stands out by:

• requiring Widevine PSSH box in audio initialization segment.
• breaking when subsample encryption is signaled on the audio tracks.
• breaking when HE-AAC v2 is used.

[sandersaares]

I will try to report these issues to browser vendors. Meanwhile, I have pushed the v7 data set to master, as no further issues have been detected (the only change was that the audio stream was updated to HE-AAC v2).

Do you plan to keep this demo player available for any nontrivial time period? (Can I reference it in my defect reports or will it be 404 soon?)

[joeyparrish]

I would be happy to leave that demo player up for you for your bug reports.

However, since v6 worked across browsers, it seems like v7 is a regression. How can you deploy a service with streams that fail in various ways on Chrome, Firefox, and Edge?

[sandersaares]

This set of test vectors is designed to be a modern set of test data that is expected to be supported by players that target modern standards. It attempts to make use of desirable features/mechanisms that are either just coming into use (DASH-IF IOP 3.3 recommendations published this summer) or are foreseen to become relevant in the near future (already positioning to target CMAF compatibility in so much as MPEG has agreed so far).

It is certainly not example of test data that is adjusted to deal with defects of players/platforms, as that would be counterproductive. Players/platforms need to be fixed to support standard-conforming data, not the other way around, after all - that's the whole point of having standards.

[sandersaares]

Reported issues here for reference.

• Connect feedback ID 3101080 (private)
• https://bugs.chromium.org/p/chromium/issues/detail?id=643604
• https://bugzilla.mozilla.org/show_bug.cgi?id=1300069

[joeyparrish]

Fair enough, but for our purposes (demonstrating player and platform compatibility with your encoder) we have to continue using v6. And v6's text streams are broken, which we have had to work around. It would be nice if you could correct the bug in v6 without requiring us to jump to unsupported streams in v7.

[sandersaares]

That is perfectly understandable. However, I would also consider the viewpoint that as a common packager (mp4box) does actually produce such content as v6, perhaps it should be considered sufficiently realistic content to be supported?

I can certainly understand a "do not care about playback of nonconforming content" policy, but overall compatibility does tend to be a strong requirement for players - I suspect you will find that many implementors begin with mp4box and might run into this issue.

I will update this issue if we can squeeze in a "v6.1" for you.

[joeyparrish]

Sounds fair. Thanks for considering.

[sandersaares]

@joeyparrish please find v6.1 described at https://github.com/Axinom/dash-test-vectors/tree/conservative

This should fix any missing segments, at least I saw none during my validation run. Only the manifest and text tracks changed - the rest are the same as in v6. The text tracks were re-encoded, which may (though should not) introduce differences in the content.

[sandersaares]

@joeyparrish we applied a hotfix to the v7 test vectors, to correct the content defect referenced in https://bugs.chromium.org/p/chromium/issues/detail?id=643604

The v7 test vectors (at least the single-key one, which I tried) now appear to play fine in Shaka Player, at least in Chrome. Firefox and Edge are confirmed to have bugs that prevent playback. There still appears to be some missing piece of the puzzle for Firefox.

[sandersaares]

Closing this as 6.1 is now available. Feel free to reopen if we missed any!

[joeyparrish]

Sorry for the delay. Since you corrected the saiz values as mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=643604#c9, I am able to play v7 in Chrome & Firefox.

I am having DRM-related issues on IE and Edge which are probably unrelated. I will file a new issue for that if need be.

Thank you for your support!

[sandersaares]

FYI, there is an Edge issue with v7 playback that is fixed in some future version of Edge, not yet published.

[joeyparrish]

Is there a bug filed with Edge where we can follow along?

[sandersaares]

I filed a private bug on Connect for this, so it is not visible to others outside Microsoft. The issue is marked as fixed and Microsoft feedback is that the fix is expected to be published in a future version of Edge. I expect it will be in the next major patch for Windows, given that Edge tends to leave all the media stuff up to the Windows media stack, so that is likely where the fix actually is.

[joeyparrish]

If we can't have access to the bug report, can you find out what version has the fix so that we can watch out for it?

[sandersaares]

I have not been able to obtain any useful data related to that. I will let you know if something becomes apparent but I do not expect to hear any specific numbers, really.

[sandersaares]

@joeyparrish

The update should be available in a couple of weeks to the early Windows Insider ring release and in general part of the Windows (Creator) update.

[joeyparrish]

Thanks!