Unable to open MKV file with VP9/OPUS

[train85]

This file format, downloaded from YouTube by IDM, cannot be opened in AviDemux. Neither in version 2.8.0 nor in 2.8.1. This applies to all files of this type.

Format selection in IDM:
http://ibn.im/TVN34dh

Sample file:
Andy

If you download not using IDM, but other programs, then you get a different format (WEBM), which normally opens in the program. And after repacking in mkvtoolnix or ffmpeg, Avidemux starts open this video.

At the same time, in video editing programs (for example, XviD4PSP) and in all players, files of this format are opened, played and edited without problems. The problem is only with AviDemux.

[eumagga0x2a]

Please post (by copy and paste) the output of MediaInfo for such a file.

If you download not using IDM, but other programs, then you get a different format (WEBM)

When using yt-dlp or youtube-dl, you can request any of formats offered by YouTube, muxable to any format supported for selected streams by ffmpeg. WebM is used only for VP9 + Opus (possibly also for AV1 + Opus). I suspect that the problem is with extradata-less AV1 streams as this was already reported a while ago. The solution was not to use outdated broken applications to obtain videos from YouTube. This one can be this or something different, please upload a short sample to WeTransfer, Mega, Dropbox or Google Drive rather than to some unfamiliar cdn (if these services are accessible from your location, of course).

[eumagga0x2a]

I forgot to mention that as CleanTalk external anti-spam service often interferes with posting URLs, you can provide the links to the sample on WeTransfer, Mega, Dropbox or Google Drive also via PM.

[train85]

I tried to publish MediaInfo and got the following:
CleanTalk: *** Forbidden. Please enable JavaScript. Message seems to be spam. ***
See my answer in PM.

[eumagga0x2a]

Thank you for the sample. The reason why Avidemux cannot open it is that it cannot locate the "Cues" element which provides the necessary info about location of keyframes. Avidemux cannot locate Cues because the names of elements referenced by the SeekHead element in the file created by IDM are stored backwards (reverse byte order). I suspect that this is an outright spec violation, but need to do some research first.

You can fix it by remuxing it with ffmpeg which creates a MKV file where Avidemux can find the Cues element.

By the way, I could find the video on YouTube, but I really wonder why the sample provided is that big. The size of video stream (VP9, 1280x720 @ 60 fps) is only ~35 MiB:

Code Select Expand

[info] Available formats for inp12hMy2vw:
ID  EXT   RESOLUTION FPS │   FILESIZE   TBR PROTO │ VCODEC          VBR ACODEC      ABR     ASR MORE INFO
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb2 mhtml 48x27          │                  mhtml │ images                                      storyboard
sb1 mhtml 80x45          │                  mhtml │ images                                      storyboard
sb0 mhtml 160x90         │                  mhtml │ images                                      storyboard
139 m4a   audio only     │    1.39MiB   48k https │ audio only          mp4a.40.5   48k 22050Hz low, m4a_dash
249 webm  audio only     │    1.25MiB   43k https │ audio only          opus        43k 48000Hz low, webm_dash
250 webm  audio only     │    1.50MiB   52k https │ audio only          opus        52k 48000Hz low, webm_dash
140 m4a   audio only     │    3.70MiB  129k https │ audio only          mp4a.40.2  129k 44100Hz medium, m4a_dash
251 webm  audio only     │    2.76MiB   96k https │ audio only          opus        96k 48000Hz medium, webm_dash
17  3gp   176x144      7 │    2.14MiB   74k https │ mp4v.20.3       74k mp4a.40.2    0k 22050Hz 144p
394 mp4   256x144     30 │    1.79MiB   62k https │ av01.0.00M.08   62k video only              144p, mp4_dash
160 mp4   256x144     30 │    1.56MiB   54k https │ avc1.4d400c     54k video only              144p, mp4_dash
278 webm  256x144     30 │    2.27MiB   79k https │ vp9             79k video only              144p, webm_dash
395 mp4   426x240     30 │    3.64MiB  127k https │ av01.0.00M.08  127k video only              240p, mp4_dash
133 mp4   426x240     30 │    2.99MiB  104k https │ avc1.4d4015    104k video only              240p, mp4_dash
242 webm  426x240     30 │    5.37MiB  188k https │ vp9            188k video only              240p, webm_dash
396 mp4   640x360     30 │    7.42MiB  259k https │ av01.0.01M.08  259k video only              360p, mp4_dash
134 mp4   640x360     30 │    5.91MiB  206k https │ avc1.4d401e    206k video only              360p, mp4_dash
18  mp4   640x360     30 │   16.99MiB  594k https │ avc1.42001E    594k mp4a.40.2    0k 44100Hz 360p
243 webm  640x360     30 │   10.14MiB  355k https │ vp9            355k video only              360p, webm_dash
397 mp4   854x480     30 │   13.70MiB  479k https │ av01.0.04M.08  479k video only              480p, mp4_dash
135 mp4   854x480     30 │   11.31MiB  396k https │ avc1.4d401f    396k video only              480p, mp4_dash
244 webm  854x480     30 │   14.50MiB  507k https │ vp9            507k video only              480p, webm_dash
136 mp4   1280x720    30 │   39.27MiB 1375k https │ avc1.4d401f   1375k video only              720p, mp4_dash
22  mp4   1280x720    30 │ ~ 44.07MiB 1504k https │ avc1.64001F   1504k mp4a.40.2    0k 44100Hz 720p
247 webm  1280x720    30 │   34.65MiB 1213k https │ vp9           1213k video only              720p, webm_dash
398 mp4   1280x720    60 │   42.27MiB 1480k https │ av01.0.08M.08 1480k video only              720p60, mp4_dash
298 mp4   1280x720    60 │   17.52MiB  613k https │ avc1.4d4020    613k video only              720p60, mp4_dash
302 webm  1280x720    60 │   34.25MiB 1199k https │ vp9           1199k video only              720p60, webm_dash
399 mp4   1920x1080   60 │   81.98MiB 2871k https │ av01.0.09M.08 2871k video only              1080p60, mp4_dash
299 mp4   1920x1080   60 │   83.68MiB 2930k https │ avc1.64002a   2930k video only              1080p60, mp4_dash
303 webm  1920x1080   60 │  116.30MiB 4073k https │ vp9           4073k video only              1080p60, webm_dash
Either YT offers different quality streams depending on location or IDM re-encodes on the fly. Avidemux opens the video (mkv, VP9 + Opus) as obtained by yt-dlp impeccably.

[train85]

Either YT offers different quality streams depending on location or IDM re-encodes on the fly. Avidemux opens the video (mkv, VP9 + Opus) as obtained by yt-dlp impeccably.

That's right. I wrote about it right away:
"If you download not using IDM, but other programs, then you get a different format (WEBM), which normally opens in the program. And after repacking in mkvtoolnix or ffmpeg, Avidemux starts open this video".
The problem is that all players and other programs have no problems finding keyframes in a file of this format, and only Avidemux does not know how to do it... I would like to ask to fix this if possible.

[eumagga0x2a]

Just to make it clear: the sample is really broken and neither VLC (which is based on FFmpeg) nor FFmpeg itself is able to locate the Cues element in it. You should report the bug (element IDs within the SeekHead element stored as little endian) to IDM developers.

However, Avidemux completely dismissed hints from Simple Block headers as a way to identify keyframes. In the sample, these headers are correct and make it seekable. Future Avidemux builds, i.e. those containing the changeset [demuxers/Matroska] Preliminarily mark index entries as keyframes based on Simple Block headers, will load this sample without issues.

By the way, older Avidemux releases forcibly marked the first frame in a Matroska video as a keyframe, no matter what. This approach resulted in a big mess in rare cases when the first frame was not a keyframe but sort of helped with loading the sample – we need at least one keyframe to be present. Of course, it could not make the file seekable as there was just one frame marked as keyframe.

[train85]

You should report the bug (element IDs within the SeekHead element stored as little endian) to IDM developers.

I will try to do it.

Future Avidemux builds will load this sample without issues.

Thank you.

[eumagga0x2a]

A fresh MinGW-compiled win64 nightly containing the fix has been uploaded to https://avidemux.org/nightly/win64/.

[train85]

A fresh MinGW-compiled win64 nightly containing the fix has been uploaded to https://avidemux.org/nightly/win64/.

Thanks a lot, everything works in this version!

But I found another problem. Here is the link to the file, also from YouTube and also downloaded using IDM, but in a slightly different format - MKV (AV1+OPUS)
https://drive.google.com/file/d/14KytLgczkRVAL8sClV3CQ399_7Dy6kez/view?usp=sharing

Older versions of Avidemux cannot open it. The latest version opens it, but when you try to save a segment from a file (direct copying of streams), an error is returned:
http://ibn.im/a0rcLEp

[eumagga0x2a]

This is exactly the problem with extradata-less AV1 streams I mentioned earlier. libavformat will error out when asked to write a Matroska packet if no extradata is available for AV1.

We would need to extract extradata e.g. from the first keyframe when opening a file with AV1 video stream but without extradata supplied. I'll evaluate our options at a later point.

[train85]

This is exactly the problem with extradata-less AV1 streams I mentioned earlier. libavformat will error out when asked to write a Matroska packet if no extradata is available for AV1.

Yes, I understand that. Unlike the first example, other editors have problems with this format, for example, XviD4PSP was able to cut a piece from such a file (although he did it for a long time, it was more like recoding), but rewinding does not work in the resulting file. Apparently, this is a more complicated case..

[eumagga0x2a]

Should be fixed for such Matroska source videos by [1] and [2].

[train85]

Thank you, I will be waiting for an update.

[train85]

Thanks, everything works in the latest version. I am impressed by the responsiveness of the developers, a great program!