Thanks for filing the issue...

Tried to reproduce the issue on reported chrome version 73.0.3644.0 using Mac 10.14.0 and 10.14.1. Attaching screen-cast for reference.
Steps: 
------
1. Launched reported chrome 
2. Navigated the URL "https://gist.github.com/surma/171a383df351c7bfa4d890394b7e6e96" and downloaded the file 
3. Opened the html file and Waited ~5 seconds 
As we have not observed playing the video file and also the comment line

@Reporter: Could you please check the attached screen-cast and let us know if we missed anything form our end and if possible provide and screen-cast for better triaging it.

Thanks.!

Deleted: 916215.mp4 1.2 MB

	916215.mp4 1.2 MB View Download

Not sure why autoplay is not working for you, but that’s important for this issue. 

The file from the gist creates a video that is playable, that’s the essential observation here. After commenting out the line like described in step 4, the video will NOT be playable anymore.

For more clarity, and as requested, here is a screencast: https://youtu.be/tHa5aFkqWIo 

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

MediaRecorder will transparently record whatever is provided to it;
so I think the issue here is that the <canvas>.captureStream() is

Made a codepen to study exactly what's happening:
https://codepen.io/miguelao/pen/MZVoJd?editors=1010

Just to be sure, you'd like to draw the animation to the canvas
"offline", as fast as possible, and then play it back at a reduced
speed, so the animation looks smooth, correct?  That would never
work anyway, because the playback would be at exactly the same
speed of the recording, because there's no way to retimestamp
the encoded data before putting it in the container.  We discussed
this in the context of using a MediaRecorder for offline web 
transcoding (<video> plays a given format, MediaRecorder records
another, and you'd like that to be as fast as possible, not at
the speed of the playback) -- but it didn't reach any conclusion,
see https://discourse.wicg.io/t/allow-non-realtime-use-of-mediarecorder/2308/4

I confirmed that if we don't `await raf();`, then the video 
track receives no VideoFrames, so nothing gets encoded (I 
also tried creating the captureStream();  with no parameter 
and also commenting out the line videoTrack.requestFrame(), 
which shouldn't make a difference, and indeed it doesn't).
So MR is not broken in this case, but still this demo would
not work as expected, see #6