This file format, downloaded from YouTube by IDM (http://www.internetdownloadmanager.com), 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 (https://cdn.bunkr.is/Andy-Murray-vs-Dominic-Thiem-Highlights---Madrid-2022-kLgQz81R.MKV)
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.
Please post (by copy and paste) the output of MediaInfo for such a file.
Quote from: train85 on May 05, 2022, 04:58:13 PMIf 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).
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.
I tried to publish MediaInfo and got the following:
CleanTalk: *** Forbidden. Please enable JavaScript. Message seems to be spam. ***
See my answer in PM.
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:
[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.
Quote from: eumagga0x2a on May 05, 2022, 08:42:50 PMEither 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.
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 (https://github.com/mean00/avidemux2/commit/0283b2204339b44e59aa5402c73a42e29d212312), 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.
Quote from: eumagga0x2a on May 07, 2022, 12:54:48 AMYou should report the bug (element IDs within the SeekHead element stored as little endian) to IDM developers.
I will try to do it.
Quote from: eumagga0x2a on May 07, 2022, 12:54:48 AMFuture Avidemux builds will load this sample without issues.
Thank you.
A fresh MinGW-compiled win64 nightly containing the fix has been uploaded to https://avidemux.org/nightly/win64/ (https://avidemux.org/nightly/win64/).
Quote from: eumagga0x2a on May 07, 2022, 04:32:00 PMA fresh MinGW-compiled win64 nightly containing the fix has been uploaded to https://avidemux.org/nightly/win64/ (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
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.
Quote from: eumagga0x2a on May 08, 2022, 01:26:43 PMThis 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..
Should be fixed for such Matroska source videos by [1] (https://github.com/mean00/avidemux2/commit/f4b0ac784151df5ba603a3086d1ab6660d212424) and [2] (https://github.com/mean00/avidemux2/commit/f3a9f2c9b39a50ab3a80d7dbc154ed5b65d6f9c9).
Thank you, I will be waiting for an update.
Thanks, everything works in the latest version. I am impressed by the responsiveness of the developers, a great program!