Additional info:

It works fine on another machine, which seems to have VPX decode disabled due to being a version prior to the Windows 10 creator's update.

chrome://gpu diff (working machine on right)

http://www.mergely.com/O6gaz3cV/

Don't have a machine with vpx decode handy today, jbauman@ are you able to reproduce this?

Yeah, I'm also seeing this on Intel. no idea what could cause this sort of thing.

I've observed that it only seems to happen following a bitrate transition, if that helps!

@jbau: Intel HD graphics?

In the past we've seen issues like this with the h264 hardware decoders when keyframes are incorrectly marked in the stream. I.e. we end up sending non-keyframe packets as the first ones to the hardware decoder. +sandersd who might have more to add on what we've seen in the past. Dan, do you have a similar tool for checking webm streams?

That is quite possible - however, DASH depends on keyframes in order to achieve smooth bitrate transitions. If the keyframes were misaligned, I'd expect to see corruption on any bitrate transitions even when using the soft decoder.

If I detect when the resolution changes in the bitstream and make a new decoder (same as we do with h.264) then it seems to work, though I don't know why that should be. The VP9 MFT seems to be changing the output size of the stream in a sensible way, so it's unclear why it would be corrupted.

I'm not sure recreating the decoder would be a valid solution in the general case, as I think VP9 reference frame scaling should allow an output frame with a different size to depend on an earlier frame.

I don't think that reference frame scaling applies in this case. With DASH each quality level is encoded entirely separately (but with fixed/consistent key-frame intervals), and is spliced together using media source extensions.

It's also perfectly valid in DASH to use completely different video sources for each bitstream, as seen in the reference (H264) stream at http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd - the quality level is encoded into the video.

MSE config changes should be completing flushing the decoder in between intialization segments. I notice that we send DRAIN vs FLUSH to the MFT. Should we be sending FLUSH after DRAIN maybe?

Yeah, I hacked it to send FLUSH in this case before resuming decoding after a DRAIN completes and it seems to work. Should the DXVAVideoDecodeAccelerator try to handle that (it may cause issues in the case where video after the flush depends on video before it) or should the client try to do it?

I'm also going to play with adding MFSampleExtension_Discontinuity or sending MFT_MESSAGE_NOTIFY_END_OF_STREAM/MFT_MESSAGE_NOTIFY_START_OF_STREAM

I think the only case where you would see issues is with non-mse content like this http://storage.googleapis.com/dalecurtis/frame_size_change.webm - but that would not even issue a flush (sorry don't have a vp9 version and my ffmpeg-fu is failing at the moment) where we don't issue a flush in between. These types of videos are very rare though and already don't work on some platforms (Android).

There's no way for MSE content to depend on frames across the flush; or at least there's no way it'll work right now. All of our software decoders do a full reconfigure for config changes, not just a Flush like some of the VDAs do. The VDAs don't allow reinitialization, so they don't see this reconfigure though. So I think just always sending FLUSH after a flush completes should be fine.

In any case, are you sure reference frame scaling is supposed to work across a flush? I find that fairly surprising. +fgalligan in case he knows.

I'm not even talking about reference frame scaling in this case. I'm just not sure of the semantics of the stream after VideoDecodeAccelerator::Flush is used. I know it's supposed to decode everything so far and return it to the client, but are subsequent frames allowed to depend on frames prior to the flush, or is that forbidden?

I didn't even know that was a question to ask; it certainly won't work with any of our software decoders, so in that sense yes it's forbidden :)

Ok, good to know. Also, sending FLUSH doesn't seem to help consistently. The only thing I've found so far that actually works all the time is recreating the IMFTransform decoder on Flush().

(Just a note for anyone visiting this ticket who is affected - launch Chrom(e/ium) with --enable-accelerated-vpx-decode=0 as a workaround)

Dale@, as per c#13, is this behavior intended (by design)? can I resolve this bug as won't fix?

John was looking into this per the above comments.

Just wondered if there was any progress with this?

I don't think I understand enough about how MSE resolution changes are supposed to work to be able to fix this.

John, does wiping the IMFTransform as you mention in c#14 unback previously decoded zero-copy frames? If not I suggest we use that approach (or figure out why FLUSH isn't working... since it seems like it should).

MSE resolution changes always send EOS (Flush) then trigger Initialize() again (which GVD ignores). In all our software decoders we destroy the codec and create a new one on the Initialize(). So doing that for our hardware decoders is fine if it works.

Throwing away the IMFTransform shouldn't affect the previously-decoded video frames at all.

Okay, if you still have your old change; want to put it up for review? Otherwise I'll get around to crafting the same thing this week.

I have https://codereview.chromium.org/2923913003/, but I don't think it passed all the tests.

Reuploaded here since bot logs expired: https://chromium-review.googlesource.com/c/607580

Hi folks. This is becoming much more of an issue now that the Creator's Update has been rolled out.

I understand that things take time, however - is there any way to detect from Javascript if the accelerated-vpx-decode flag is set (and therefore use a fallback stream to avoid the corruption issue)

Sorry there are some crashes and test failures preventing the fix we wanted to try, will try to get to this soon.

I'm still unsure why you are seeing this and YouTube vp9 encodes are not. Even though they're using transcodes of the same video across resolution changes, I'd be surprised that the encoded data is similar enough to not result in similar issues if the problem is related to the flush.

mpd URL no longer works. @tom can you restore that URL for testing?

Sorry, yes, the URL has changed to:

https://login.plasticpictures.tv/stream/221b0430e48aef24df59af2856d536e6907bc79a/manifest.mpd

Observation: With Chrome/61 I am now seeing an improvement:

The video still corrupts on bitrate change, however the corruption seems to clear up after the next keyframe (whereas before it would persist for the rest of the playback session).

Be sure to disable "local storage" in the reference player to force the bitrate switching to happen.

Actually, never mind. This one still exhibits issues the whole way through

https://login.plasticpictures.tv/stream/f554d2d6331d449be6e0fce5881d8e817b573a74/manifest.mpd

Thanks, will take a look next week.

+hubbe, liberato who have shown interest in picking up some of the VDA work.

Hmm, I'm unable to reproduce this with canary + nvidia 1050ti. jbauman@ note he saw it on Intel, but original report is on a 1050ti. 

tom@ are you still able to reproduce this on canary? I'm using the dash nightly player (2.6.2):

http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html

Yes, I can confirm that I am still seeing the issue on all my systems with Canary and this stream:

https://login.plasticpictures.tv/stream/f554d2d6331d449be6e0fce5881d8e817b573a74/manifest.mpd

The system I've just tested on is Windows 10 64-bit with GTX 1080 Ti, but it happens on all my machines with nVidia cards and Win 10 creators update.

You need the "creator's update" to be able to reproduce this, and hardware acceleration must be enabled. It's also important to disable "Allow local storage" so that a bitrate transition actually takes place.

Thanks. Sorry, I was testing on anniversary edition with canary forced to use hardware decoding since our internal machines haven't updated yet.

hubbe@ can you see if this reproduces on the fall creator's update you installed? 

Yes, this video shows corruption on my machine with chrome M61, M62 and M63.
Once I turn off hardware decoding, the problem goes away. (Nvidia GTX 1050)

Thanks for testing, it's unfortunate that it's not fixed.

This may be a dash-if bug. Using Shaka v2.2.0 there's no corruption between segments in our tests.

http://storage.googleapis.com/dalecurtis/shaka/shaka.html?src=https://login.plasticpictures.tv/stream/f554d2d6331d449be6e0fce5881d8e817b573a74/manifest.mpd

Here's a link to the shaka demo player with v2.2.3-debug:

https://shaka-player-demo.appspot.com/demo/#asset=https://login.plasticpictures.tv/stream/f554d2d6331d449be6e0fce5881d8e817b573a74/manifest.mpd;lang=en-US

FWIW, I'm a little hesitant to apply the patch we discussed in c#23 since it requires destroying the hardware decoder instances on every flush which can lead to stuttering at segment boundaries.

The plot thickens.  Yes, you're right - Shaka is MUCH better (and I've moved my client's site over to use it to work around the issue). So this does point to it being a dash implementation issue.

However.. here's a stream which exhibits some corruption with shaka too (during the transition to 2160p. Doesn't happen every time.)

https://login.plasticpictures.tv/stream/14e350d17948c99e73d00cda7443c0b57744a67f/manifest.mpd

https://shaka-player-demo.appspot.com/demo/#asset=https://login.plasticpictures.tv/stream/14e350d17948c99e73d00cda7443c0b57744a67f/manifest.mpd;lang=en-US

Screenshot of Shaka: https://gyazo.com/bd9982e211b1d97ee132443ab6ff9247

I filed a ticket with Shaka to see if they have some input: https://github.com/google/shaka-player/issues/1103

As described in c#39, I am also able to reproduce this issue in Shaka player (and others DASH compatible players). It is just a matter of forcing the player to do a few bitrate switches to reproduce the issue.

Regarding Dash.js, when playing DASH streams, we are not doing any manipulation of the segments so there is not too much we can do to fix/break this. We are just appending segments in the right order so it would be weird (although not impossible) that there is something wrong in Dash.js which is causing video artifacts.

From my tests (dash.js, shaka player and jw player) my assumption is the time takes to reproduce the issue is just a matter of the ABR algorithm. The much bitrate switches happen, the easier is reproducing the issue. 

I am going to take a deeper look to the stream to try to get more conclusions. In the mean time, if you need anything from dash.js, just please let me know. I will be glad to help here.

Deleted: shaka.png 244 KB

	shaka.png 244 KB View Download

Thanks for the extra samples! @liberato, with the new d3d11 decoder do you still see corruption like described?

@tom, You mention this plays fine in other browsers, but did you specifically test Edge? I thought I tested it myself, but now I'm not sure if it was actually using vp9 for the test given my hardware.

@dalecur - Tested on Edge, no playback issues whatsoever. One thing of note, though - there is a small but noticeable lag on ABR switch (a fraction of a second). Maybe this is a sign that they're tearing down the decoder?

Edge is running at <1% cpu during playback - pretty sure it's using the hardware decoder. Not sure how to verify that though.

The only influence dash.js or Shaka Player could have over the issue is exactly when in the stream we switch, and to what.  It could also be influenced by overlapping segments (which current Shaka Player versions don't do).  Does dash.js overlap segments in the SourceBuffer?

These things could explain differences in repro rates, but neither player has any direct influence over anything at a decoder level.

I recommend instrumenting exactly what segments are appended in what order, because that would be reproducible independent of any player.

Shaka's player.getStats() method returns a structure which includes a history of adaptation decisions which could approximate this, but instrumenting at StreamingEngine or NetworkingEngine could provide a better picture.  Let me know if you need help with this.

No, there is no situation in dash.js in which we are overlapping segments. We are always appending full segments one after the other. 

Good point Joey. I will try to help getting the list of files appended when we reproduce this issue in dash.js. Not easy (difficult to get a laptop in which this issue is reproducible) but will do my best.

I have been working on a very simple demo that reproduces this issue. It uses MSE and just appends 4 video chunks of the provided stream:
- Init chunk of 240p quality
- First data chunk of 240p quality
- Init chunk of 720p quality (simulating a bitrate switch)
- Second data chunk of 720p quality

As you will see, as far as second chunk of 720p quality starts playing you will start seeing the video artifacts. You can find the demo here: 
http://dashjs.eb.epiclabs.io/

If you want to take a look to the code or modify it to test something different, please find it here:
https://github.com/jeoliva/mse-example/tree/artifacts-test

Thanks for the repro demo! I'll dig in and see if there's something besides completely tearing down the decoder between switches that we can do here.

hubbe was kind enough to try the d3d11 decoder, but unfortunately it still doesn't play correctly.

it's possible that chrome chose dxva anyway, but i suspect not.  on my local system, which doesn't have creator's edition, it picks the d3d11decoder.

Tried a few different things without success so far:
- Double checked that segment boundaries are actually keyframes. They are.
- Set MFSampleExtension_Discontinuity, per https://msdn.microsoft.com/en-us/library/windows/desktop/ms705630(v=vs.85).aspx
- In addition to the above, Sent MFT_MESSAGE_NOTIFY_END_OF_STREAM at Flush() before DRAIN and MFT_MESSAGE_NOTIFY_START_OF_STREAM after Flush, https://msdn.microsoft.com/en-us/library/windows/desktop/dd940424(v=vs.85).aspx 

No luck with any of that :| The link in c#46 still causes corruption on Creators Edition+ at around 6 seconds

+brucedawson in case he has any ideas. It might be time to create a minimized test case and send it to Microsoft. 

No ideas. If you create a minimized test case and need help submitting it to Microsoft I can open up a formal support case with them.

Experimented a bit more today. Just in case it was something with the webm packaging I stuffed the stream into a mp4 container and rewrote the demo, available internally at xorax.sea/winvp9/mse.html. I also constructed a similar demo from 240p + 720p YouTube VP9 encodings and was not able to reproduce the issue, available internally at xorax.sea/winvp9/mse_buck.html.

I also generated a progressive webm which exhibits the issue - among other things; hardware decoding doesn't properly detect the size change and thus doesn't update dimensions.

Edge in Fall Creators edition should be able to play it, so I'll test that when I get home.

Deleted: stream.webm 2.2 MB

	stream.webm 2.2 MB View Download

Actually I think if we just detect and process configuration changes this issue is fixed. With YouTube encodes this doesn't matter, but these encodes seem to require us to process the flush and invalidate the decoder upon config change: https://chromium-review.googlesource.com/c/chromium/src/+/802629

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/37c4403918e4461496415a8b3e104207b9317f34

commit 37c4403918e4461496415a8b3e104207b9317f34
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Tue Dec 05 20:36:40 2017

Trigger configuration changes for vp9 resolution changes.

This has been unnecessary in the past with YouTube VP9 encodings,
but for some reason other VP9 encoding types show artifacts if
the configuration change is not processed.

BUG= 729600 
TEST=no more artifacts on http://dashjs.eb.epiclabs.io/

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Id91f112ff8a1f1877cade3e8a86af39b05ff80a0
Reviewed-on: https://chromium-review.googlesource.com/802629
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521812}
[modify] https://crrev.com/37c4403918e4461496415a8b3e104207b9317f34/media/gpu/dxva_video_decode_accelerator_win.cc

@Tom or @Jesus, have you had a chance to try Chrome Canary to see if the issue is resolved in all cases for you? The fix I landed was similar to one that jbauman@ indicated didn't work in all cases, but I wasn't able to trigger any further issues.

I will try tomorrow (I don't have a Windows 10 machine close to me now) and will get back to you with the results.

Thanks 

@dalecur, just did some tests in a Windows 10 machine. I have tested two streams that were previously failing. The one I used to generate the basic test (http://dashjs.eb.epiclabs.io/) and another one shared by @Tom (https://login.plasticpictures.tv/stream/221b0430e48aef24df59af2856d536e6907bc79a/manifest.mpd).

Simple test, and the stream I used to generate it, worked like a charm. No artifact at all. 

However, in the other one I still see some artifacts, mainly when switching to the top bitrate (16 Mbps!). I am going to prepare a very basic test using chunks of this stream to make the errors easy to reproduce. I will also take a a look at the stream itself to be sure there is nothing wrong there.

Thanks

Forget the last part of my previous message. I have been trying (quite intensively, during more than one hour and with all bitrate combinations) to reproduce the issue again with the stream that was failing and I couldn't. Seems everything is fine. 

I can't confirm but probably I reproduced the issue before because there was a confusion in my side and I was not using Chrome Canary in that specific test......

After my latest tests, everything looks fine. Using dash.js in Chrome Canary those "problematic" streams play nicely.

Okay great. Thanks for testing! Sorry it took me so long to figure out a solution for this issue.

Given the potential for adverse affects with this change, I'm not planning to merge it to M64, so it will roll out with the normal M65 release process. If anything else comes up we can try stronger fixes.