What about AV1 codec support ? Encoding, decoding, no support at all ?
I have tried to load the demo file at https://github.com/SPBTV/video_av1_samples without success : black screen, only few lines of random colours at the bottom. FourCC code for codec not shown in info dialog box. Also, I have not found an av1 codec option for encoding.
I use Avidemux 2.7.0 (not tested 2.7.1).
Any development on this front?
I figure it isn't yet implemented, do we know if it's being worked on?
Not that I were aware of. Not on my present todo list* either.
*) The todo list:
- evaluate options of fixing HEVC hw accel. decoding on Windows with Intel graphics;
- fix audio in fragmented mp4, currently not supported by the mp4 demuxer.
A luxury wish, probably out of reach: implementing a libvpx-based VP9 encoder.
I feel like VP9 is less of a priority than AV1 since big corps have already started pushing it as a successor to VP9... It is based on it after all.
Just need to be able to remux it in copy mode at the very least. Seems we can demux an MP4 with AV1, but can't use copy mode and remux it back into an MP4 for some reason.
Oh, I hope that AV1 will be supported too, since Youtube recently switched to it (and the codec seems better than VP9).
Quote from: undefined2020-07-07: 2.7.6: Another nice release, completely done by Euma
* New Video Decoder:Add libaom-based AV1 decoder
I use Avidemux 2.7.6 - Release. However, in the list of options for video encoding, I only see
Quote from: undefinedCopy
Mpeg4 ASP (xvid4)
Mpeg4 AVC (x264)
So, does the application support this open, and royalty-free codec, which is already two and a half years old, or not?
Quote from: Siana West on September 29, 2020, 07:05:22 AMo, does the application support this open, and royalty-free codec, which is already two and a half years old, or not?
As the changelog states, AV1 decode support is present = no AV1 encode support yet. Implementing an encoder plugin may become possible after hardware upgrade, already the VP9 encoder is unbearably slow for me, AV1 must be much worse.
Quote from: eumagga0x2a on September 29, 2020, 08:30:43 AMalready the VP9 encoder is unbearably slow for me, AV1 must be much worse.
Btw, even the normal smart-cutting without re-encoding seems to have some problems for AV1 (video from youtube)
The saved video is incomplete. The error occurred at 00:00:00 [..] invalid time stamps [..]
Could you please provide the YouTube-ID of the video you are unable to cut in copy mode?
Quote from: eumagga0x2a on October 13, 2020, 08:28:18 PMCould you please provide the YouTube-ID of the video you are unable to cut in copy mode?
Ok, but it's a silly one XD
Btw it happened to other AV1 Youtube videos too, but not always.
Could you please elaborate, which steps are necessary to reproduce the issue? I can cut the 1920x1080 AV1 version of this video in Avidemux in copy mode without any problems whatsoever.
I'm using AvidemuxVC 0276 btw
- I downloaded the video with Youtubedl (it joins the AV1 video + Opus audio files).
- I got the AV1 1080p 60fps format and it plays normally.
- if I try to smart-cut it (for example the first 11 secs), I get the error.
I tried extracting only the video part with mkvtoolnix and Avidemux managed to cut it.
So, it seems that the program doesn't like the joined audio, for some reason.
I wonder if it's Youtubedl's fault or not.
I would recommend to use the latest nightly as a rule.
Quote from: phaolo on October 14, 2020, 07:38:18 PM- I downloaded the video with Youtubedl (it joins the AV1 video + Opus audio files).
In other words, you loaded a MKV file in Avidemux (ffmpeg, used by youtube-dl to mux streams, will refuse to mux Opus in MP4 by default), I tested with MP4.
Now retried with MKV and again no issues.
Quote from: phaolo on October 14, 2020, 07:38:18 PMSo, it seems that the program doesn't like the joined audio, for some reason.
Not the audio but the container.
Please try a nightly.
Quote from: eumagga0x2a on October 14, 2020, 08:09:31 PMIn other words, you loaded a MKV file in Avidemux [..]
I would recommend to use the latest nightly as a rule. [..]
Yes, I used a mkv, Youtubedl has an option to fix the container after the download.
Ok, I'll try the nightly.. even if I really dislike dev builds in general.. the few times I tried them I always had problems. -_-
Quote from: phaolo on October 14, 2020, 08:34:46 PMthe few times I tried them I always had problems.
Dev builds are better than releases most of the time, but sometimes they can be terrible. As can be releases.
Nightlies not being tested by a sufficiently large crowd means bugs making it into releases unnoticed.
Ono, I finally tried the latest nighly (v277 VC 21-03-03) but.. it still shows the "Too short" error with AV1 :(
Quote from: phaolo on March 05, 2021, 02:35:10 AMit still shows the "Too short" error with AV1
I just tried with a random AV1 video from YT (id fH921fbPB-g) as well as with the stream 399 from the video you mentioned earlier (id vKDQGcQWt9Q) and didn't experience any difficulties cutting the AV1 varieties in copy mode. I conclude from that that the problem is likely not on our side. Maybe you use a broken tool to obtain the videos in the first place, please try one which works (e.g. youtube-dl).
But I'm exactly using youtube-dl.
I made a script for it, but these are the resulting (simplified) parameters I use:
--merge-output-format mkv -f "(bestvideo[vcodec^=av01][height=1080]/bestvideo[vcodec^=vp9][height=1080]) + bestaudio[ext=webm][abr>=90]"
And here is the (simplified) Mediainfo data for the downloaded file for "vKDQGcQWt9Q":
Format : Matroska
Format version : Version 4
File size : 254 MiB
Duration : 12 min 17 s
Overall bit rate : 2 884 kb/s
Writing application : Lavf58.12.100
Format : AV1
Format/Info : AOMedia Video 1
Format profile : Main@L4.1
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Format : Opus
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 32 bits
Compression mode : Lossy
I don't want to insist too much, but it's so strange that you aren't getting the error like me. :-\
Not insisting too much is the problem :)
Which FFmpeg version is your youtube-dl using?
It might be also helpful to know the segment layout i.e. where do you cut. Saving from the start of the video to e.g. 00:03:27.766 works impeccably for me, the MKV loaded by Avidemux was muxed from streams 399+251 with FFmpeg 4.3.2.
Mm.. I installed it from this archive:
ffmpeg- v0431_25 2020_11_15 win64- gpl shared.zip
It's not that old, but I'll try updating it.
(ffmpeg's multiple builds are confusing for me btw)
Btw your stream codes seem correct, and my test cuts were random (but on keyframes).
4.3.1 is for sure recent enough, I didn't have any issues to cut with MKV created by 4.2.x at least (or maybe even 4.1.x). edit: obviously, on Linux.
It didn't work :(
I updated ffmpeg to the latest version (v0432_160 2021_03_04 win64- gpl shared) and cut your video at your time and I'm still getting the error.
I'm on Windows 7 Pro x64 here instead.
Quote from: phaolo on March 05, 2021, 07:46:30 AMffmpeg- v0431_25 2020_11_15 win64- gpl shared.zip
By the way, would you mind trying a static build?
Another thing to try: don't use your youtbue-dl command line and obtain just the video track (i.e. 399), no audio. Try to cut it.
Quote from: eumagga0x2a on March 05, 2021, 08:06:40 AMBy the way, would you mind trying a static build?
Which one do you mean exactly?
As I mentioned, I don't understand those build names at all.
I followed the link "Windows builds by BtbN" and there are like 10 archives..
Quote from: eumagga0x2a on March 05, 2021, 08:09:30 AMAnother thing to try: don't use your youtbue-dl command line and obtain just the video track (i.e. 399), no audio. Try to cut it.
Ok, I tried "-f 399" and I can cut the resulting .mp4 mute file.
If I do "-f 399+251" instead, the resulting .mkv file gives the same error as before when cut.
I also tried VP9+Opus with "-f 303+251" and cutting the .webm didn't give me problems.
I meant ffmpeg-n4.3.2-160-gfbb9368226-win64-gpl-4.3.zip (no "shared" in the name).
(this simple machines forum software stupidly makes URLs out of anything with a period followed by three letters)
Quote from: phaolo on March 05, 2021, 08:25:05 AMIf I do "-f 399+251" instead, the resulting .mkv file gives the same error as before when cut.
The problem is obviously with the muxing step.
Nope, the static builds gave me the same error.
Quote from: eumagga0x2a on March 05, 2021, 08:31:20 AMThe problem is obviously with the muxing step.
But why.. could it be a FFmpeg problem just on Windows?
Also damn, this means I downloaded a bunch of faulty AV1 files -_-
Quote from: phaolo on March 05, 2021, 08:58:06 AMBut why.. could it be a FFmpeg problem just on Windows?
Difficult to tell with certainty at this stage of problem assessment. Could be also a Matroska demuxer problem in Avidemux (on Windows only, of course). Could you eventually provide such a presumably faulty MKV as a sample via WeTransfer, Mega, Dropbox or Google Drive, please?
Sure, here you go:
Thank you, I can reproduce the failure with your MKV, works with mine. The first thing which strikes me is that the video track in your MKV lacks extradata (decoder configuration), i.e. the MKV is indeed broken. Looking deeper into it.
In your MKV, according to mkvtoolnix:
Multiplexing application: Lavf58.12.100
This is FFmpeg 4.0, not FFmpeg 4.3.2, which would have libavformat (Lavf) 58.45.100. FFmpeg 4.0 seems to be really too old for AV1.
Oh no, that's the worst case for me :'(
But FFmpeg 4.0?? Where TF is youtube-dl getting it?
The PATH env variable is pointing to "C:\Program Files\ffmpeg\bin", exactly where I put the latest build..
$PATH has usually not just a single entry, with the current directory being probably searched first on Windows, so you should look into the folder where youtube-dl binary is located.
And there it is, an ancient ffmpeg executable next to youtubedl.
I've deleted it and now the program points to the correct one.
And the error stopped appearing.
Thank you for the help.
Now I'll have to redownload everything.. RIP.
Alternatively, you can re-encode the audio track e.g. to AAC and save edited broken MKVs as MP4 in Avidemux. This works. Just the MKV muxer refuses to cope with extradata-less AV1 streams.
Eh, I'd prefer not to encode again files, to preserve their (youtube) quality.
Btw, how do you match the libavformat version to the FFmpeg one? Is there a list?
For example I see that OBS is still creating files with an old 58.20.100
Anyway, I hope that 58.12.100 didn't cause some other issues also with AVC or VP9.
You don't need to re-encode video as long as you stick to MP4 container (AV1 is compatible with MP4, Opus not yet).
Regarding libavformat version, I just looked at the version.h file at https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/version.h (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/version.h) and switched tags (click on "master" to expand the list) until I got to the value of LIBAVFORMAT_VERSION_MINOR matching yours.
I see, thanks.
(I would have never found that lol)
Btw, I think I managed to recover the files for cutting, by:
1- saving only the video part with Avidemux to .mp4 (gMKVExtractGUI failed instead)
2- extracting the opus audio with gMKVExtractGUI
3- join both again with MKVToolNix GUI
4- cut with Avidemux normally
It is even simpler: just load the extradata-less source MKV in MKVToolNix and remux it, no intermediate steps necessary. This adds the missing extradata to the output file, making it fit for further editing with Avidemux.
Ah true, that's way better.
But in any case, no need to redownload everything as I first though ;D