Hi, I've been using and liking Avidemux for quite a while, but something I've noticed is the program often gives imprecise and imperfect cuts of audio, where things don't really line up as they should.
Here's what I mean. This is the clip in Avidemux, pay close attention to the end audio:
https://youtu.be/cWrvT_wc-6I
These are the exact same frames but edited in Premiere Pro:
https://youtu.be/MYszxgSq1h0
In Premiere Pro, you get the full audio. It doesn't cut off early like Avidemux. Why is this? Am I doing something wrong? My encode settings are
video: mpeg4 ASP (ff)
Audio: AAC (lav)
Output: mp4v2
I have tried all different audio formats and none were as clean as Premiere Pro, even "copy". Could anyone test this out by trying to get precise cuts of their own? I have encountered this many times across different videos. It's like Avidemux mutes the very end but I don't understand why. Please move this to the right section if I've posted it in the wrong one.
Thank you
This might be related to A/V sync. Did you try the latest nightly? Why DivX? This codec is ancient. Please try the Mp4 muxer, not mp4v2 for better comparison.
https://avidemux.org/nightly/
Quote from: eumagga0x2a on October 09, 2018, 06:19:40 AM
This might be related to A/V sync. Did you try the latest nightly? Why DivX? This codec is ancient. Please try the Mp4 muxer, not mp4v2 for better comparison.
https://avidemux.org/nightly/
Thank you very much for the response. I actually use Avidemux 2.6.21. I have some issues with 2.7. For instance, when I resume playback, I always get a green screen that flashes first. The cut points also work differently in 2.7, in previous versions you'd have to go the next frame and then choose that as the cut off point, 2.7 has you select the last frame you want as the cut off point, which I don't really like.
Regardless, I downloaded the latest nightly as you suggested and used the same settings, except this time had the Output Format set to MP4. Unfortunately, I got the same result. Avidemux 2.7 also seems to have a bug where the beginning of the video has a little audio blip, so it doesn't seem too suitable for my use. You can hear it here, as well as see that the audio still cuts off poorly:
https://www.youtube.com/watch?v=ttZDmzSCamI
Any ideas? Are others able to replicate this when aiming for precise cuts? I am using Windows 7, but I have previously had these issues on Windows 10 also
Also, I'm not sure how much this helps, but here's the ending audio tracks for both
Top two are the Avidemux 2.7 mp4 encode
Bottom two are Premiere Pro
Of course, you must ensure that A/V sync is correct. You could try if disabling B-frames makes the problem disappear.
The possibly relevant location in code would be the part of the muxerFFmpeg::saveLoop function following avidemux_core/ADM_coreMuxer/src/ADM_coreMuxerFfmpeg.cpp:556 (https://github.com/mean00/avidemux2/blob/master/avidemux_core/ADM_coreMuxer/src/ADM_coreMuxerFfmpeg.cpp#L556).
QuoteFor instance, when I resume playback, I always get a green screen that flashes first.
This is pure cosmetics, isn't it? Might be related to the DXVA2 video accel.
QuoteThe cut points also work differently in 2.7, in previous versions you'd have to go the next frame and then choose that as the cut off point, 2.7 has you select the last frame you want as the cut off point, which I don't really like.
Well, I see it other way round, so WONTFIX. You could become an important Avidemux contributor, then modify the behaviour to your liking.
QuoteAvidemux 2.7 also seems to have a bug where the beginning of the video has a little audio blip, so it doesn't seem too suitable for my use.
I strongly doubt that this issue (I tried to locate and to solve it, yet without success) is specific to 2.7.x. It is a small amount of previously decoded audio in a buffer, so if the last thing you played in Avidemux was silent, you would avoid this audio blip.
All fixes go only into 2.7.x and later, obviously. So staying at 2.6.21 is not a solution.
I hope, the tentative fix (https://github.com/mean00/avidemux2/commit/5879b8f855977d619afd69ebb5288827e149e8e4) doesn't break stuff. As to my brief testing, it solves the issue with last bits of audio in the saved video missing when the video stream contains B-frames for libavformat based muxers (Mp4, Matroska, not mp4v2).
Once a new nightly gets generated and uploaded, please test and report back.
Quote from: eumagga0x2a on October 09, 2018, 12:39:41 PM
Of course, you must ensure that A/V sync is correct. You could try if disabling B-frames makes the problem disappear.
Sorry, I'm not really sure how to do this, or how to modify the code.
Quote from: eumagga0x2a on October 09, 2018, 04:22:21 PM
The possibly relevant location in code would be the part of the muxerFFmpeg::saveLoop function following avidemux_core/ADM_coreMuxer/src/ADM_coreMuxerFfmpeg.cpp:556 (https://github.com/mean00/avidemux2/blob/master/avidemux_core/ADM_coreMuxer/src/ADM_coreMuxerFfmpeg.cpp#L556).
This is pure cosmetics, isn't it? Might be related to the DXVA2 video accel.
Yeah, it just effects playback, not the output but it seems worse in 2.7 than it was in 2.6
QuoteWell, I see it other way round, so WONTFIX. You could become an important Avidemux contributor, then modify the behaviour to your liking.
I completely understand that, I didn't mean to be disrespectful, I was just stating my preferences. Unfortunately I don't know enough to learn how to do that, this is just a program I've enjoyed using for a long time but have had these issues I never understood. I will move on to updated versions eventually, but at the moment for me, 2.7 doesn't offer more than 2.6.
QuoteI strongly doubt that this issue (I tried to locate and to solve it, yet without success) is specific to 2.7.x. It is a small amount of previously decoded audio in a buffer, so if the last thing you played in Avidemux was silent, you would avoid this audio blip.
All fixes go only into 2.7.x and later, obviously. So staying at 2.6.21 is not a solution.
The issue does seem specific to 2.7. I have uploaded 3 more clips to demonstrate the problem.
Here is the clip from Avidemux 2.6:
https://youtu.be/1EggraTCgIw
Here is the same clip but in Avidemux 2.7:
https://youtu.be/2sHpk28Q7oY
And here is the same clip but cut in Premiere Pro:
https://youtu.be/_YgF61Dkk1Y
As you can hear, in 2.7 there is a little audio hitch in the beginning, which isn't present in the other 2 cuts despite starting and ending on the exact same frames. It doesn't happen all the time, sometimes 2.7 behaves fine, but other times I have issues like this.
Also, as before, Premiere Pro gets the full, complete audio, whereas Avidemux seems to cut off early. Is there anything I can really do to fix this, and get precise cuts? I uploaded the audio tracks above if they're of any help.
I really do like Avidemux, it's a brilliant program but I just can't wrap my head round this issue and would like to solve it somehow.
Thanks for all the help
Quote from: eumagga0x2a on October 09, 2018, 06:27:35 PM
I hope, the tentative fix (https://github.com/mean00/avidemux2/commit/5879b8f855977d619afd69ebb5288827e149e8e4) doesn't break stuff. As to my brief testing, it solves the issue with last bits of audio in the saved video missing when the video stream contains B-frames for libavformat based muxers (Mp4, Matroska, not mp4v2).
Once a new nightly gets generated and uploaded, please test and report back.
Ah, sorry, I didn't see this post before making my previous one. Should I just wait for the next nightly and see if that works?
I do however want to bring attention to some of the other issues I mentioned with 2.7 in my previous post though, such as the initial audio blip that occurs in some cuts and is present in the video I posted above. The flashing green screen for playback is also problematic, as 2.6 seemed to handle this better, but it is not a major issue.
Have you been able to replicate them, or know of a fix?
Apologies if it sounds like I'm complaining too much, Avidemux has actually served me very well and like I said, I really do like it
Absolutely no problem with complaining, thank you for raising the question. I actually wanted to encourage to "get hands dirty" and start contributing to shape things to one's liking, at least this is how it worked in my case.
By the way, the only notable change in Avidemux behaviour since the old 2.6.x days when deleting a portion of video was inclusion of the picture matching the B marker (the end point) if it happend to be the last picture of the video. Apart from that, a few changes were made to keep the current position in the video (the currently displayed picture) during editing operations as good as possible to follow the principle of least surprise (https://en.wikipedia.org/wiki/Principle_of_least_astonishment).
The audio blip is a small portion of the previously decoded audio. I tried to fix it, but it turned out to be quite a difficult task. As explained above, play a silent passage in Avidemux directly before starting a save operation which includes re-encoding of audio. This will result in the blip consisting of silence and thus not noticeable.
If the green flash bothers you, disable DXVA2 display and use the OpenGL (QtGl) output (or feel encouraged to fix the issue yourself!). I get a brief initial corruption when initializing playback using VDPAU as well, but this doesn't bother me. This stuff is not on my todo list.
QuoteShould I just wait for the next nightly and see if that works?
Yes, exactly.
Quote from: eumagga0x2a on October 10, 2018, 09:21:44 AM
Absolutely no problem with complaining, thank you for raising the question. I actually wanted to encourage to "get hands dirty" and start contributing to shape things to one's liking, at least this is how it worked in my case.
It does seem interesting, but all of it seems way above my head! It'd be nice to try and manually restore the older B marker behaviour but I seriously would have no idea how to ;D
QuoteThe audio blip is a small portion of the previously decoded audio. I tried to fix it, but it turned out to be quite a difficult task. As explained above, play a silent passage in Avidemux directly before starting a save operation which includes re-encoding of audio. This will result in the blip consisting of silence and thus not noticeable.
Do you have any idea why the audio blip is present in 2.7, but not present in 2.6? Is it related to the changes made to follow the principle of least surprise? It just seems strange to me, and unfortunately my use for Avidemux requires lots of precise cuts like this. Sorry, just to be clear, what do you mean by playing silent passages in Avidemux? Is that something that is easy to do and replicate?
As I said, I use Avidemux for stuff like this constantly, so if I have to use a workaround each time I want to make a new clip, or if that audio blip is going to be present when I make a clip, the newer versions of Avidemux may unfortunately be unsuitable for me.
I do not want this to be the case, as I think the program is truly fantastic, but should the blips persist it wouldn't really allow me to do what I want to and I may have to stop using it :'(
I still look forward to the new nightly, and I'm incredibly appreciative you took the time and effort to not only look into this, but fix it as well, You're great, it's just that the blip doesn't seem like it'd be easy to workaround if I'm making multiple cuts at a time.
QuoteIf the green flash bothers you, disable DXVA2 display and use the OpenGL (QtGl) output (or feel encouraged to fix the issue yourself!). I get a brief initial corruption when initializing playback using VDPAU as well, but this doesn't bother me. This stuff is not on my todo list.
I'll try this, thanks. It doesn't bother me too much either, it just seems more noticeable on 2.7 than it was on 2.6 so I thought maybe it was something on my end.
Quote from: BatmanLoko9 on October 11, 2018, 12:11:44 AM
Quote from: eumagga0x2a on October 10, 2018, 09:21:44 AM
I actually wanted to encourage to "get hands dirty" and start contributing to shape things to one's liking, at least this is how it worked in my case.
It does seem interesting, but all of it seems way above my head!
This is always this way initially.
QuoteIt'd be nice to try and manually restore the older B marker behaviour but I seriously would have no idea how to ;D
Could you please explain what you exactly mean here? There were zero changes WRT markers affecting deletions after 2.6.20/21 you are using. Earlier changes affected only deletion of a portion of video with the marker B at or after the last frame. The old behaviour made it impossible to delete the last frame.
QuoteQuoteThe audio blip is a small portion of the previously decoded audio. I tried to fix it, but it turned out to be quite a difficult task. As explained above, play a silent passage in Avidemux directly before starting a save operation which includes re-encoding of audio. This will result in the blip consisting of silence and thus not noticeable.
Do you have any idea why the audio blip is present in 2.7, but not present in 2.6?
No, I am not that familiar with audio code. I am also not sure it was not present in 2.6. This might depend on audio decoder in use and even the audio output (the latter won't affect the saved video, however).
QuoteIs it related to the changes made to follow the principle of least surprise?
Unlikely.
QuoteSorry, just to be clear, what do you mean by playing silent passages in Avidemux?
The blip consists of the last audio (about ~50 ms in duration) decoded before stopping playback. If playback was stopped during a loud passage in the video, you might get an audible noise in the saved video. If playback was stopped during an almost silent scene, there shouldn't be any perceptible defect.
Quoteif I have to use a workaround each time I want to make a new clip, or if that audio blip is going to be present when I make a clip, the newer versions of Avidemux may unfortunately be unsuitable for me.
I do not want this to be the case, as I think the program is truly fantastic, but should the blips persist it wouldn't really allow me to do what I want to and I may have to stop using it :'(
As mentioned before, I tried to fix it and failed so far. If the Author of Avidemux doesn't fix this small problem himself, I plan to return to this bug at a later time, once much more important issues are solved. If you need Avidemux to work exactly as you need without workarounds right now, contribute code which fixes this bug (find and pay a capable developer to do it for you) or use another video editor.
Why do i get an error when trying to post? It brings up a Forbidden error and tells me to enable javascript, but I have. No add ons running either, it's very strange.
Quote from: eumagga0x2a on October 11, 2018, 07:42:11 AMThis is always this way initially.
Have you past programming experience? Without that it seems like it'd be quite difficult to get into this, no?
QuoteCould you please explain what you exactly mean here? There were zero changes WRT markers affecting deletions after 2.6.20/21 you are using. Earlier changes affected only deletion of a portion of video with the marker B at or after the last frame. The old behaviour made it impossible to delete the last frame.
I just meant like I said in an earlier post:
QuoteThe cut points also work differently in 2.7, in previous versions you'd have to go the next frame and then choose that as the cut off point, 2.7 has you select the last frame you want as the cut off point, which I don't really like.
You mentioned this was changed as well
QuoteNo, I am not that familiar with audio code. I am also not sure it was not present in 2.6. This might depend on audio decoder in use and even the audio output (the latter won't affect the saved video, however).
hmm, what makes you think it was not present in 2.6? I uploaded 2 different clips, both showed the blip in 2.7 but not in 2.6. You do have to listen out for it, but it is noticeable in my opinion.
QuoteThe blip consists of the last audio (about ~50 ms in duration) decoded before stopping playback. If playback was stopped during a loud passage in the video, you might get an audible noise in the saved video. If playback was stopped during an almost silent scene, there shouldn't be any perceptible defect.
Ah I understand what you mean now. Unfortunately like I said my use means I do this quite a bit so can't really hope for quiet scenes.
QuoteAs mentioned before, I tried to fix it and failed so far. If the Author of Avidemux doesn't fix this small problem himself, I plan to return to this bug at a later time, once much more important issues are solved. If you need Avidemux to work exactly as you need without workarounds right now, contribute code which fixes this bug (find and pay a capable developer to do it for you) or use another video editor.
Yes, I'm very grateful you took the time to look into it and try to fix it, that was really nice of you. I understand your point though, I just came here wondering if I was doing something wrong or if there was a workaround, since i couldn't seem to find mention of the issues elsewhere. I have learnt a bit more as well, so it was very nice of you to take the time to discuss this. Thanks for all the help, I'll still look out for the next nightly
Quote from: BatmanLoko9 on October 12, 2018, 01:29:37 AM
Have you past programming experience?
No past coding experience whatsoever.
QuoteI just meant like I said in an earlier post:
QuoteThe cut points also work differently in 2.7, in previous versions you'd have to go the next frame and then choose that as the cut off point, 2.7 has you select the last frame you want as the cut off point, which I don't really like.
You mentioned this was changed as well
If it ever were this way, I would classify this as a clearly buggy behaviour. Usually, one sets the B cut point to a keyframe using UP/DOWN arrow keys. In copy mode (which is the default), we can't drop B, it must stay. The way you wish the delete operation to work, one would have to make an additional step just to avoid a corrupted video (and a menacing warning popping out) in the most common use case.
The behaviour was changed only for B at or past the last frame of the video – and for a good reason.
QuoteI just came here wondering if I was doing something wrong or if there was a workaround
There is a workaround for the blip :-)
The issue will be tackled one day – maybe.
It's me again, I have created a new account as I wanted to update this thread. I think there was an issue with the email I used for the previous account, so I received constant errors. I attempted to use a different email and even that wasn't accepted but I appear to have the issue sorted out now.
I just wanted to update. I've been testing with the latest Nightly, and it seems the problem has been fixed now!
The audio blip has unfortunately remained. and I have a weird issue when encoding with Mpeg4 ASP (ff). If I encode a video using those settings, and then open the video in certain programs like Premiere Pro, or Windows 10 Media Player, it plays/encodes like this:
https://youtu.be/FEVCIUuu5GA
I don't understand why it does this. If I play the clip in VLC, or just upload the clip straight to Youtube, it is absolutely fine. However, in certain programs like Premiere Pro, or Windows own media player, the entire video is distorted.
QuoteAudible in the saved video when played with another video player (e.g. vlc) or audible when played in Avidemux? If the latter, you might be hearing the popping sound from initializing the audio device, not relevant to the actual content of the audio track. If the former, does enabling audio shift and using a bigger and bigger negative value (i.e. advancing audio WRT video) remove the blip?
Sorry, I meant audible in another video player. I will hopefully test using audio shifts later and report back
QuoteNo, unless I get a good way to reproduce it and there are no tasks with higher priority.
It just seems like strange behaviour. If you wish, I could provide you with the source files, as well as the exact frames where I get this blip if you do want to look into it. Regardless, I appreciate all the help so far even if you can't.
QuoteNo idea, but if you really have to use an obsolete codec like H.263, you could try whether the Xvid encoder shows better compatibility with non-ffmpeg based decoders.
Do you think it would be better to just use Mpeg4 x264 then? Like I said, I don't know much about video encoding, but way back when I first started using Avidemux, I used to encounter a cut in audio when I'd use x264, which is why I used MPEG4 ASP (ff) encoder. I know that seems strange, given it's the video encoder but it's just the way it was.
I will switch to x264, I assume it's less obsolete and if I encounter the audio cut I will again report back.
Thank you
Thank you for identifying the cause of the problems with the antispam service, I guess it should be pinned as README somewhere.
Did you re-encode audio for that click/blip/whatever at the start of a video as in https://youtu.be/2sHpk28Q7oY (https://youtu.be/2sHpk28Q7oY)? Was the audio track internal or external?
If you copied audio, then the whole theory about already decoded audio somewhere in a buffer does't apply.
Of course, H.264 via x264 is by far superior to older mpeg4 codecs like DivX. Only if the target equipment is not capable of decoding H.264 (like an ancient DVD player) or your PC is so slow that encoding with x264 would take an eternity and the graphics card is not NVIDIA or too old to allow to use NVENC, resorting to H.263/DivX/Xvid were justified. Choosing H.265 (HEVC) instead of H.264 should be well thought out, however. Both encoding and decoding demands a very powerful CPU or working hardware acceleration for HEVC.
The green flash on starting playback should be fixed now, please try a future nightly (r181129 or later).
Apart from that, a response to the questions in my previous post would be appreciated.
Quote from: eumagga0x2a on November 28, 2018, 04:38:16 PM
The green flash on starting playback should be fixed now, please try a future nightly (r181129 or later).
Apart from that, a response to the questions in my previous post would be appreciated.
Sorry, I'm horrible at remembering logins and due to that and not doing too much video encoding lately, I didn't update the thread.
Quote from: eumagga0x2a on November 17, 2018, 01:08:52 PM
Thank you for identifying the cause of the problems with the antispam service, I guess it should be pinned as README somewhere.
Did you re-encode audio for that click/blip/whatever at the start of a video as in https://youtu.be/2sHpk28Q7oY (https://youtu.be/2sHpk28Q7oY)? Was the audio track internal or external?
If you copied audio, then the whole theory about already decoded audio somewhere in a buffer does't apply.
As I recall, it was an Internal track, and I reencoded the audio.
I am happy to report though, that I have tested the latest nightly, and can confirm that the green flash is fixed. Not only that, but it seems the audio blip is also completely gone! Thank you so much for your help with this. For reference, I made the same clip again, with Avidemux 2.6, 2.7.1 and 2.7.3:
https://youtu.be/ho7tJspnDwM
https://youtu.be/YioWEB0v5cg
https://youtu.be/DL2ZHIQGaPE
As you can hear, there's no blip in 2.6, there is a blip in 2.7.1, but there's no blip in 2.7.3. The issue appears to be fixed. I'm still not used to the B Marker working differently though! :P
However, 2.7.3 seems to bring with it it's own issues. It seems that the latest version offers support for HiDPI Windows device but the implementation is problematic. When running in Windowed mode with a clip open, the bottom of the Avidemux program is cut off by the Taskbar, meaning you're unable to see timeframes. When running in full screen, Elements of the GUI begin to overlap, and the program is almost unusable. I have attached screenshots to demonstrate this. Should I create a new thread for this issue? This is on a 1920x1080 13.3" Laptop.
Also, can I ask what people would recommend are the best settings for short .mp4 clips like the ones I've been posting in this thread? I mentioned what I used initially, but you kindly pointed me towards using Mpeg4 AVC (x264) instead, as well as using the "MP4 Muxer" Output Format instead of "MP4v2" (The Muxer doesn't open if I use x264 with MP4v2, so I can't encode anything). Is AAC (lav) a fine audio encoder, or could I do better? Are the settings i'm using fine?
QuoteWhen running in Windowed mode with a clip open, the bottom of the Avidemux program is cut off by the Taskbar, meaning you're unable to see timeframes.
Yes, I experience it too that in HiDPI conditions on Windows, it is necessary to manually resize the window for the correct zoom value to be applied.
Nothing was changed regarding that brief portion of previously decoded audio somewhere in a buffer.
There is no MP4v2 muxer in VC++ builds. If Avidemux shows it in the list, you must have installed it over a mingw-compiled build, which can't work.
For very short videos, reduce the GOP length in order to get at least 3-4 seek points within the video.
Quote from: eumagga0x2a on May 10, 2019, 05:45:09 PM
QuoteWhen running in Windowed mode with a clip open, the bottom of the Avidemux program is cut off by the Taskbar, meaning you're unable to see timeframes.
Yes, I experience it too that in HiDPI conditions on Windows, it is necessary to manually resize the window for the correct zoom value to be applied.
Nothing was changed regarding that brief portion of previously decoded audio somewhere in a buffer.
There is no MP4v2 muxer in VC++ builds. If Avidemux shows it in the list, you must have installed it over a mingw-compiled build, which can't work.
For very short videos, reduce the GOP length in order to get at least 3-4 seek points within the video.
With the latest Avidemux, it seems I can't resize the window because as it showed in the screenshot, the taskbar then cuts off Avidemux and I can't make it smaller.
I seem to have slight work around, and that's using an external manifest file. It disables the HiDPI and makes Avidemux lose the sharpness in its GUI by making things blurrier, but it seems to work.
You're sure nothing was changed from 2.7.1 to 2.7.3 regarding the audio buffer? It seems strange that the issue is completely gone now! I'm happy with it though. Older versions of Avidemux (2.6) do seem to still have the much earlier mentioned issue of audio cutting off prematurely when compared to Premiere Pro. Would there be any way of fixing the audio in 2.6, I know it's outdated though.
I don't have the VC++ build, just the latest nightly, if MP4v2 has been removed, then I assume it isn't recommended to use regardless so it's no big miss. I'll just use MP4.
Thanks for the tip regarding the GOP length, really appreciate it. Do you think the rest of the chosen settings are fine too?
Quote from: BatmanLoko10 on May 11, 2019, 04:32:30 PM
With the latest Avidemux, it seems I can't resize the window because as it showed in the screenshot, the taskbar then cuts off Avidemux and I can't make it smaller.
Just grab the window border at another side, it need only a small nudge to trigger zoom recalculation.
QuoteI seem to have slight work around, and that's using an external manifest file. It disables the HiDPI and makes Avidemux lose the sharpness in its GUI by making things blurrier
That sounds horrible for me :-)
QuoteYou're sure nothing was changed from 2.7.1 to 2.7.3 regarding the audio buffer?
Not knowingly.
QuoteI don't have the VC++ build, just the latest nightly
There are official latest VC++ nightlies and official latest MinGW nighlies.
QuoteDo you think the rest of the chosen settings are fine too?
I'm sorry, but that was a general recommendation. Additionally, I'm not an expert in finetuning of x264 parameters.
Quote from: eumagga0x2a on May 11, 2019, 04:43:58 PM
Just grab the window border at another side, it need only a small nudge to trigger zoom recalculation.
The Window only goes so small however, it has a minimum size and unfortunately that size is too big to fit on my screen and the program ends up being cut off by the Windows taskbar. You can see this in the "windowed" Screenshot I uploaded, it doesn't get any smaller.
QuoteNot knowingly.
That is strange then! As you can see in those clips, the issue is clearly gone, I even tried the 2.7.1 build of Avidemux on a different machine and got the same blip.
QuoteThere are official latest VC++ nightlies and official latest MinGW nighlies.
I'll have to look into the VC++ builds, truth be told I'm not really sure what they are or how they work, as I generally just grab the installer from the Avidemux home page
QuoteI'm sorry, but that was a general recommendation. Additionally, I'm not an expert in finetuning of x264 parameters.
That's fine, you've already helped me plenty and told me better settings than the ones I was using! I used to used Mpeg4 ASP just because I didn't know any better! Thanks again
Just another quick update on this thread if it's not a bother.
The aforementioned settings of Mpeg4 AVC (x264), AAC (lav) and MP4 Muxer do not seem to be ideal settings for short clips. It seems when encoding things that are around 1 second long, the process fails and Avidemux throws the error "the file is saved but seems to be incomplete". The output file will also not play and be corrupted.
I'm not sure if this is an Avidemux bug or just a video editing thing, but I thought it'd be worth mentioning. Y
ou told me Mpeg4 ASP (ff) was an outdated output format, is Mpeg4 ASP (xvid4) superior since x264 doesn't seem to work in this case? Sorry, I'm not too experienced with this and I'm just trying to find the best settings but don't know which video ouput formats are better or worse. You did tell me x265 was the best, but that would require too much power so I'm not opting to use that.
I never thought of clips that short. In this exotic case, you could try setting the x264 profile to baseline to disable B-frames. Usually, the encoder analyses quite a lot of pictures before being able to output even a single compressed frame.
xvid4 is just another implemention of the same obsolete mpeg4 codec.
Quote from: eumagga0x2a on May 15, 2019, 07:06:39 PM
I never thought of clips that short. In this exotic case, you could try setting the x264 profile to baseline to disable B-frames. Usually, the encoder analyses quite a lot of pictures before being able to output even a single compressed frame.
xvid4 is just another implemention of the same obsolete mpeg4 codec.
Thank you, I can confirm that changing the profile did work. There does seem to be a slight quality difference when using my own configuration and choosing baseline. It also encodes quicker than the default "advanced configuration" Any idea why that might be? Enabling baseline is the only setting I changed in there after unticking "Advanced configuration".
If I wanted to open Avidemux with these settings by default, would this still be the best guide?
https://www.avidemux.org/admWiki/doku.php?id=tutorial:presets#example_save_your_x264_options
It does seem strange that clips that are around 1 or 2 seconds long don't encode right under x264, I don't seem to recall having this issue before at all, but perhaps I just never used the settings. Xvid4 and ASP (ff) work better but as you say, they're outdated and as I mentioned earlier, seem to give me problems when running in other programs. Would you recommend any other encoders?
Finally, I wanted to correct something I was saying earlier. I mentioned that the behaviour of the "B" marker has changed going from Avidemux 2.6 to 2.7. This is incorrect, it is actually the behaviour of the "A" marker that has been adjusted. I think I mentioned what has changed, but I could make a video demonstrating it in case I haven't been clear. Was this an intentional adjustment?
Once again, thank you for the help. The work you do on these forums is fantastic and it's good to see the commitment to a brilliant little program.
Oh, and something that's not really a big problem at all but I thought I'd ask, is there any way to stop Avidemux from resizing itself once you open media?
QuoteIf I wanted to open Avidemux with these settings by default, would this still be the best guide?
https://www.avidemux.org/admWiki/doku.php?id=tutorial:presets#example_save_your_x264_options (https://www.avidemux.org/admWiki/doku.php?id=tutorial:presets#example_save_your_x264_options)
It depends on what exactly you want to achieve. If you need to add an easy way to revert to particular encoder settings without using the x264 preset menu in the encoder configuration dialog and without affecting any other Avidemux configuration like output container, this is the way to go. If you are okay with other config being set as well, you can just set the current configuration as default (Ctrl+Alt+D or via the "Edit" menu).
Quoteis there any way to stop Avidemux from resizing itself once you open media?
Only if the Avidemux window is maximized.
Quote from: eumagga0x2a on May 17, 2019, 05:53:59 AM
QuoteIf I wanted to open Avidemux with these settings by default, would this still be the best guide?
https://www.avidemux.org/admWiki/doku.php?id=tutorial:presets#example_save_your_x264_options (https://www.avidemux.org/admWiki/doku.php?id=tutorial:presets#example_save_your_x264_options)
It depends on what exactly you want to achieve. If you need to add an easy way to revert to particular encoder settings without using the x264 preset menu in the encoder configuration dialog and without affecting any other Avidemux configuration like output container, this is the way to go. If you are okay with other config being set as well, you can just set the current configuration as default (Ctrl+Alt+D or via the "Edit" menu).
Quoteis there any way to stop Avidemux from resizing itself once you open media?
Only if the Avidemux window is maximized.
Thanks for the tip on setting the current config as default. I've no idea why I didn't look for that already in the settings, pretty silly of me.
As for Avidemux resizing, understandable. It just seems whenever I open something 1080p, with the default Zoom settings the Avidemux program gets cut off by the Windows taskbar. Changing the zoom setting fixes it though, but otherwise no dice. Again, not a huge issue, pressing the "4" key takes no time, just thought I'd ask.
I think I'll bounce back between 2.6 and 2.7 for now. Still too accustomed to the previous A marker behaviour to fully change. Thanks