Cannot copy vp9 stream from webm to mp4

[yrrqxk]

Summary of the bug:
I cannot copy the stream of this webm to an mp4 container. It can be copied to another webm and re-encoded to either webm or mp4 without issue.

Copying this stream to another webm seems to also copy the defect as trying to copy from one webm to another then copy to mp4 results in the same error. This even happens with clips from affected files as you can see in the attached file.

If this is relevant, the files are produced by youtube-dl and the issue only seems to happen when the video was in DASH format. This has been an issue for some time (months) across multiple youtube-dl versions and ffmpeg versions.
How to reproduce:

ffmpeg.exe -i test.webm -c copy test.mp4

ffmpeg version:
2021-01-20-git-2021dbe1d6-full_build-www.gyan.dev

[yrrqxk]

Video to reproduce bug.

[yrrqxk]

ffmpeg trace log showing bug.

[Carl Eugen Hoyos]

Not a regression afaict.

[yrrqxk]

Is there anything more I can do to help get this bug resolved quickly? If there's any information missing please say so and I'll do my best to provide it.

I should also mention I had the same issue on both Linux and Windows.

[mkver]

There are two blocks with timestamp 5339ms in test.webm. The second of those is a keyframe, which points to an issue with concatenating together different segments. This leads to the error message when muxing into mp4.
You can fix this video by muxing it with mkvmerge and specifying a default duration of 30000/1001p; notice that this might affect audio sync if there is audio for this file.

[yrrqxk]

Unfortunately it's not just this one file. I'm trying to grab a large amount of youtube videos with youtube-dl and I can't afford to manually intervene with each one (several exhibited the same issue before I gave up).

I am assuming the DASH segments overlap by a bit at the beginning and end of each segment, with the keyframe being the first frame in the next segment. Is there maybe an -fflags setting to just take the data from only one of the files when there's an overlap? How is this resolved when a file is being transcoded?

[James]

Should be fixed in 68595b46cb374658432fff998e82e5ff434557ac.