Using version 2.6.18 for Win64.
There are a few bugs that keep traveling over years from one version to another:
1) When trying to save a video as AVI YV12, only first 4 GB are saved and then the encoding stops, although the file system is NTFS and can handle larger files.
2) Audio output selection resets "invisibly" when the current video is closed and a new one is opened, although the selection visibly remains the same. Example to reproduce the bug:
a) drag (open) a MOV video (actually, any video format, but the problem will be more clearly seen with a video file containing a WAV audio stream).
b) select video: "Copy", audio: "AAC (faac)".
c) select MP4 Muxer.
d) save the video (everything goes fine now).
e) close the file (ctrl-w).
f) drag another MOV video of the kind.
g) now you see that video output is still "copy" and audio is "AAC (Faac)" and output is "MP4" (the same as they were set for the previous video).
h) save the file.
i) you see a bulk of error messages like "unsupported. Only AAC, AC3, E-AC3 and mpegaudio supported for audio" and other errors.
j) select AAC(Faac) from the dropdown list again, although it is already selected!
k) try to save the file again, and it is being saved!
3) I'm missing a normal adjustable window-wide zoom because 1:2 is too small and 1:1 is too large for my screen when working with full hd videos. And the fact that Avidemux window changes its size when closing and opening videos annoys a lot because I need to resize it after opening every new window to fit my workplace (I have also other windows opened for work).
4) When saving a file, the default file name line shows a name of a file that was saved a long time ago and has nothing to to with the current project. I think it will be more reasonable to show the file name that is being currently edited in this field so that the user could easily make simple changes of it. For example, if the opened video is "2016-01-01_12-00-00.mp4", make it also a default name for the SAVE AS dialog so that the user could make a fast modification such as "2016-01-01_12-00-00_cut.mp4" without the need to find the original filename somewhere and type it manually in this field.
are you reporting on 2.6.18 release or on nightly builds (where developing happens).
windows: http://www.avidemux.org/nightly/win64
1) .avi is not advised as container these days, you should go for .mp4 or .mkv. If you insist on avi, there is a setting in Avidemux Menu: Edit: Preferences: Output: [v] Create OpenDML files
3) tried: num keypad 4 3 2 or 1
4) this is probably changed
save current settings could solve some of your issues is you work a lot of videos from the same source.
1) See the reply by Jan.
2) Has been fixed post-release by [UI] Preserve audio codec upon loading a video, now for real (https://github.com/mean00/avidemux2/commit/aad74273fb7ba175c7f139a6da2079d307fdcb40).
3) ACK, but probably not a high priority.
4) Has been recently fixed by [core, qt] Use the base name of the currently loaded video as the default base name when saving (https://github.com/mean00/avidemux2/commit/595c2be7b8c0af979a470f887694fc46b3b83d70).
Quote from: Jan Gruuthuse on February 17, 2017, 03:49:30 PM
1) .avi is not advised as container these days, you should go for .mp4 or .mkv. If you insist on avi, there is a setting in Avidemux Menu: Edit: Preferences: Output: [v] Create OpenDML files
I tried mp4 and mkv but they do not seem to support YV12 codec and I use it to quickly export lossless intermediate videos to encode them with handbrake later in a batch (handbrake also has a good denoise filter that doesn't blur too much but noticeably remove the noise). I'll try OpenDML, thanks for the hint.
Quote
3) tried: num keypad 4 3 2 or 1
It just switches 1:1, 1:2 and other standard zooms but not full-window zoom.
About 2 and 4, thanks, the latest 170212 version is surely better than the "stable" release and fixes these problems (I thought it should be visa versa but I was wrong). Jan Gruuthuse and eumagga0x2a, thank you for your help.
Just remembered another issue. It is probably not Avidemux bug, but I'll describe it and maybe a fix can be found.
When cutting videos in Free Video Editor, it seems to damage the frame sequence by removing an initial I-frames sometimes but it saves further dependent frames (this is my guess). So, these files can be played by all video players that I have but they cannot be opened in Adobe Premiere (it sees only a sound track). Avidemux can open them but it cannot save them (it shows "Too short" message without saving the file). I tried various things and found a solution: move the cursor to the first I-frame and delete all the previous frames. After this simple trick Avidemux can save these files. Although it seems to be Free Video Editor's bug, but I thought Avidemux should validate files for such video file "damages" and ask if the user wants to remove the initial frames that cause the failure during the saving process to ensure max compatibility with broken videos and other videos that fail to follow strict specifications.
acritum, this is completely unrelated to the topic. If the first keyframe is missing, the whole GOP is skipped. For issues beyond that: please provide a sample.
Quote from: eumagga0x2a on February 18, 2017, 03:18:23 PM
acritum, this is completely unrelated to the topic. If the first keyframe is missing, the whole GOP is skipped. For issues beyond that: please provide a sample.
Just not to make new topics in the forum, here is a sample. I do not know what's wrong with it. I have cut some parts of it in Free Video Editor. Sometimes it saves normal files and maybe 1 out of 5-10 files are saved like that. You can play it in any player, but you cannot save it in Avidemux without removing the initial frames. I cannot attach it due to filesize limitations. Download here:
http://acritum.com/temp/fail.mp4
Maybe you can disassemble it with your dev tools and find out what's wrong with it.
Saving the "fail.mp4" video in Copy mode works for me using the MKV or the MP4v2 muxer. Only the MP4 muxer, which actually invokes the libavformat library within the bundled ffmpeg, stumbles over upon two frames with equal decoding timestamps:
[lavc] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 8000 >= 8000
This comes from libavformat/mux.c:560 and indeed, starting the selection on the second keyframe makes the compute_muxer_pkt_fields function happy.
Unfortunately, I can't judge if this can be worked around in Avidemux or if the bundled ffmpeg needs patching and what this patching should look like.
edit: the first keyframe is not missing.
Thank you for the explanation. Luckily, Avidemux became more convenient than it was 2-3 years ago, so I think it's time to say good-bye to Free Video Editor. I liked it for fast cutting and one-click saving files (it adds "_cut" to the end of the original file name and saves it to the same folder with one click). Previous Avidemux versions required to type the name of the file in the "Save as" window and it was really annoying when dealing with many videos. The latest version offers the original file name in the "Save as" window but still there's something unpredictable happening with the folder where the output file is saved. As far as I understand it is the last used folder or the parent folder if the last one doesn't exist anymore or even the "Avidemux" program folder in some cases. This is quite confusing because when I save project-A in folder-A, close it, open project-B in folder-B, I expect the output file to be saved in folder-B, but instead of it, it is saved in folder-A. Of course, I can check the folder before saving the file and change it to folder-B, but when the folder names are typical such as 20161030_165422, the eyes get tired and sometimes I don't notice that the folder needs to be changed and the output file is saved to the folder of the previous source/output video (folder-A) and when the encoding is done and I can't see it in the folder-B with the source file, I need to look through many folders with previous projects to find it. Although I understand that saving many files from different locations to a single output folder is sometimes useful, but in the cases like the one I described above, it leads to much confusion. So I thought it would be useful if the user could specify what folder should be used as default output folder in the Avidemux settings. There can be several options such as:
* the last folder that was used for saving,
* the folder of the source video,
* the folder specified below
[ c:\blablavla ]
This simple patch can noticeably increase the speed and ease of work when dealing with many projects/files.
And do you know anything about wrong colors when opening an AVI file? For example, when I export an uncompressed AVI from Adobe Premiere, they play well in players, but when I open it in Avidemux, it shows the blueish colors instead of the normal colors. I found a solution in forums, by adding "Swap UV" filter, but this is not very convenient because it requires video recompression (and I like Avidemux for being able to copy the streams quickly). Is this problem known and are there any plans to fix it?
The source/creation process uses another colour plane. Switching this at start would help.
http://avidemux.org/smif/index.php/topic,16572.0.html
Technical info (developers, ....)
https://msdn.microsoft.com/en-us/library/windows/desktop/dd206750(v=vs.85).aspx
Beyond my basic user capabilities.
Quote from: acritum on February 20, 2017, 05:18:21 AM
Previous Avidemux versions required to type the name of the file in the "Save as" window and it was really annoying when dealing with many videos. The latest version offers the original file name in the "Save as" window but still there's something unpredictable happening with the folder where the output file is saved. As far as I understand it is the last used folder or the parent folder if the last one doesn't exist anymore or even the "Avidemux" program folder in some cases.
It would be interesting to investigate in which situations exactly the
program directory gets automatically chosen. This is definitely not right, but regardless that the other behaviour matches my workflow (source and target are located always on different HDDs), I think that it should be this way. Avidemux will suggest the source folder as target if the lastdir_write preference is empty, which is currently questionable, because this facilitates overwriting the source video (you do get a prompt, but still).
QuoteThis is quite confusing because when I save project-A in folder-A, close it, open project-B in folder-B, I expect the output file to be saved in folder-B
Source dir = target dir is actually a really bad practice when editing video files located on rotating storage devices, less so for SSD, of course.
QuoteI thought it would be useful if the user could specify what folder should be used as default output folder in the Avidemux settings. There can be several options such as:
* the last folder that was used for saving,
* the folder of the source video,
The latter would at least require implementing automatic renaming.
Quote* the folder specified below
[ c:\blablavla ]
This should be covered by the current default behaviour once a video has been saved and is not needed IMHO. In general you are free to delete lines 51 and 52
admCoreUtils::getLastWriteFolder(lastFolder);
if(!lastFolder.size())from avidemux/qt4/ADM_userInterfaces/ADM_gui/file_qt4.cpp and build Avidemux from source to make Avidemux always suggest the source directory as target (you do need Linux to accomplish this (https://raw.githubusercontent.com/mean00/avidemux2/master/cross-compiling.txt)).
QuoteAnd do you know anything about wrong colors when opening an AVI file? For example, when I export an uncompressed AVI from Adobe Premiere, they play well in players, but when I open it in Avidemux, it shows the blueish colors instead of the normal colors.
Please provide a sample or at least the MediaInfo output for the file in question.
Quote from: Jan Gruuthuse on February 20, 2017, 05:51:41 AM
The source/creation process uses another colour plane. Switching this at start would help.
http://avidemux.org/smif/index.php/topic,16572.0.html
I don't see any possibility to switch it neither in Premiere nor in Avidemux. And the Swap UV filter solution requires re-encoding which is time consuming and results in quality loss. Do I understand it right that the color plane can't be switched without re-encoding?
Quote from: eumagga0x2a on February 20, 2017, 07:47:40 AM
Source dir = target dir is actually a really bad practice when editing video files located on rotating storage devices, less so for SSD, of course.
But if a user has one HDD drive (like most of notebook/laptop owners), we don't have any choice.
QuoteI thought it would be useful if the user could specify what folder should be used as default output folder in the Avidemux settings. There can be several options such as:
* the last folder that was used for saving,
* the folder of the source video,
The latter would at least require implementing automatic renaming.
I don't think automatic renaming is required IF/WHEN the "save-as" dialog is shown. You just cannot overwrite the source because the file is open by Avidemux and thus becomes read only for a while, so you have to choose any other file name anyway. Of course, it would be great if Avidemux could automate the saving process the way Free Video Editor does. Every time you save the video "file.mp4", it creates files like file_cut.mp4, file_cut(1).mp4, file_cut(2).mp4, etc, so you can quickly create as many edited version as you need without any prompts/confirmations and without any files being overwritten. The works goes really fast even if you have to deal with hundreds of videos. And when the source and dest. folders are the same, you can quickly compare the source and the result videos because file.mp4 and file_cut.mp4 go one after another in the same folder and they are easy to find and test one-by-one and redo the work if the result looks unsatisfying. But this is another level of ease-of use, I hope Avidemux can reach it some day. I don't have Linux at the moment and even if I install it, I have no experience in compiling software in Linux. Besides, any new official upgrade will clean out all my changes, so I'd rather get used to what we have now and wait until the developers will find time and desire to add this little patch to the official build.
If this is still needed, here is Mediainfo for "Uncompressed UYVY 422 8bit" AVI files, generated by Adobe Premiere:
General
Complete name : 160812_183906_cut.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 6.38 GiB
Duration : 4 min 38 s
Overall bit rate : 197 Mb/s
Recorded date : 2017-02-02T14:04:24+03:00
Writing application : Lavf56.1.100
Video
ID : 0
Format : YUV
Codec ID : UYVY
Codec ID/Info : Uncompressed 16bpp. YUV 4:2:2 (Y sample at every pixel, U and V sampled at every second pixel horizontally on each line). A macropixel contains 2 pixels in 1 u_int32.
Duration : 4 min 38 s
Bit rate : 195 Mb/s
Width : 848 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate : 30.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Compression mode : Lossless
Bits/(Pixel*Frame) : 16.000
Stream size : 6.33 GiB (99%)
Audio
ID : 1
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Duration : 4 min 38 s
Bit rate mode : Constant
Bit rate : 1 536 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 50.9 MiB (1%)
Alignment : Aligned on interleaves
Interleave, duration : 21 ms (0.64 video frame)
Quote from: acritum on February 20, 2017, 09:55:06 AM
I don't think automatic renaming is required IF/WHEN the "save-as" dialog is shown. You just cannot overwrite the source because the file is open by Avidemux and thus becomes read only for a while, so you have to choose any other file name anyway.
This is true only for Windows.
I hope, Mean will be able to find a free minute to look at the MediaInfo output for a video which you say is played in Avidemux with U/V swapped. A sample, just a few seconds long, would be nice anyway.
edit: by the way,
QuoteWriting application : Lavf56.1.100
Adobe Premiere can't use libavformat, can it? You've likely posted wrong MediaInfo output.
Quote from: eumagga0x2a on February 20, 2017, 08:09:24 PM
Quote from: acritum on February 20, 2017, 09:55:06 AM
I don't think automatic renaming is required IF/WHEN the "save-as" dialog is shown. You just cannot overwrite the source because the file is open by Avidemux and thus becomes read only for a while, so you have to choose any other file name anyway.
This is true only for Windows.
If it's true, Avidemux has to (or even must) implement internal protection from the source being overwritten. You can load a text file into RAM, make some modifications, and dump the text from the RAM to the source text file, but when you deal with videos, you can't load the source into memory completely, so it should remain in the original form until the encoding is complete. So, as I understand, writing to the source file directly will not lead to anything but data loss and should be prohibited by the software when the user tries to do it by mistake or on purpose.
Quote
Adobe Premiere can't use libavformat, can it? You've likely posted wrong MediaInfo output.
It looks like this avi was made by some other software, but I use only Premiere, Avidemux and very rarely Free Video Editor to work with avi. If it's not from Premiere or Avidemux, than it's from Free Video Editor. Anyway, I tested it and it also shows blue skin color in Avidemux. Here is a short real sample from Premiere (the cat shouldn't be blue):
http://acritum.com/temp/test-premiere-320x240-5fps.avi
General
Complete name : C:\sample\test-premiere-320x240-5fps.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 4.78 MiB
Duration : 5 s 200 ms
Overall bit rate : 7 710 kb/s
Recorded date : 2017-02-21T09:03:08+03:00
Writing application : Adobe Premiere Pro CC 2015.4 (Windows)
Video
ID : 0
Format : YUV
Codec ID : UYVY
Codec ID/Info : Uncompressed 16bpp. YUV 4:2:2 (Y sample at every pixel, U and V sampled at every second pixel horizontally on each line). A macropixel contains 2 pixels in 1 u_int32.
Duration : 5 s 200 ms
Bit rate : 6 144 kb/s
Width : 320 pixels
Height : 240 pixels
Display aspect ratio : 4:3
Frame rate : 5.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Compression mode : Lossless
Bits/(Pixel*Frame) : 16.000
Time code of first frame : 0 / 0
Time code source : Adobe tc_A / Adobe tc_O
Stream size : 3.81 MiB (80%)
Audio
ID : 1
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Duration : 5 s 200 ms
Bit rate mode : Constant
Bit rate : 1 536 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 975 KiB (20%)
Alignment : Aligned on interleaves
Interleave, duration : 867 ms (4.33 video frames)
Interleave, preload duration : 1000 ms
Quote from: acritum on February 21, 2017, 06:28:42 AM
Quote from: eumagga0x2a on February 20, 2017, 08:09:24 PM
Quote from: acritum on February 20, 2017, 09:55:06 AM
I don't think automatic renaming is required IF/WHEN the "save-as" dialog is shown. You just cannot overwrite the source because the file is open by Avidemux and thus becomes read only for a while, so you have to choose any other file name anyway.
This is true only for Windows.
If it's true, Avidemux has to (or even must) implement internal protection from the source being overwritten.
AFAIK this is not possible. Missing file locking brings also great benefits, e.g. you can load and save excerpts from a growing file like an ongoing video recording on Linux. Try this on Windows :P
QuoteHere is a short real sample from Premiere (the cat shouldn't be blue):
http://acritum.com/temp/test-premiere-320x240-5fps.avi
Thank you very much, I've opened a pull request (https://github.com/mean00/avidemux2/pull/99) for the fix.
Thank you. Still when you don't have more important suggestions, please ponder on the following tweak. It will not bother the users who got used to the existing way of saving files but will help a lot to those users who have many sources in many folders and want to create the edited video in the same folder with the source file avoid confusion. Then the quality of the output can be tested and the unneeded source file can be deleted at once without undesired switching from folder to folder and copying files to and fro that only waste time a lot if you have many files to work with. I think it will be accurate and will not bother anyone if implemented like this:
(https://avidemux.org/smif/proxy.php?request=http%3A%2F%2Fsavepic.su%2F7640470.jpg&hash=d8487f767be3c5b2d200ee2ac8f67928e9cb0fc4)
I've submitted a pull request (https://github.com/mean00/avidemux2/pull/101) for a quickly thrown together patch implementing your suggestion.
Thank you. You fix everything faster than I can think of new suggestions :) With all these fixes Avidemux seems to become the best. I only can't find any way of removing A/B markers without any changes to the editing process. I tried various ways: "undo" is not exactly the same (it can remove the last marker only if it was just added) , "reset edit" also removes all changes made to the video. The only way of saving the complete video after using markers seems to be setting maker A to the beginning and marker B to the end of the video, and this is not very convenient. Maybe there is a simpler method, but it is not obvious to me. I think this feature is required by many users and should be at the finger's touch distance but I don't see any buttons to get rid of the markers. Maybe it exists somewhere and I just don't see it? If not, a good solution would be to add a button to the navigation bar, after [ A ] and [B ], yet another button [Remove markers]. Additionally, in the menu [Edit], after [Set Marker B], add another item [Remove both markers].
Technically, the markers A and B are never unset.
Then make them point to the beginning and the end of the video with one button (actually, bring them to the state they are when the program has just been loaded). By now, we go to the beginning, click A, go to the end, click B, and these are 4 actions instead of one when we need to select the complete footage.
@acritum: Are you certain?
Quote from: eumagga0x2a on February 22, 2017, 07:18:27 AM
Technically, the markers A and B are never unset.
When you load video these should be set:
Time Index @ bottom right hand shows begin and endpoint are set
A: [00:00:00.000]
B: [00:00:37.930]
Quote from: Jan Gruuthuse on February 22, 2017, 08:49:39 AM
Are you certain? When you load video these should be set:
Time Index @ bottom right hand shows begin and endpoint are set
A: [00:00:00.000]
B: [00:00:37.930]
So, now select any parts in the middle. Now you decide that you don't need the selection anymore and want to save the complete video. And how are you going to set the markers back to the beginning and to the end, so that it could be fast and convenient?
Make up your mind before you select markers :)
If you did set unwanted markers, either:
- 2 times keyboard shortcut [Ctrl][Z] (undo once)
- or select Avidemux Menu: Edit: Reset Edit
The developers just did go to a great length to simplify the avidemux GUI!
It is still a simple tool.
source: Avidemux Quickstart (http://www.avidemux.org/admWiki/doku.php?id=using:quickstart)
Quote from: Jan Gruuthuse on February 22, 2017, 09:09:17 AM
Make up your mind before you select markers :)
If you did set unwanted markers, either:
- 2 times keyboard shortcut [Ctrl][Z] (undo once)
- or select Avidemux Menu: Edit: Reset Edit
The developers just did go to a great length to simplify the avidemux GUI!
It is still a simple tool.
source: Avidemux Quickstart (http://www.avidemux.org/admWiki/doku.php?id=using:quickstart)
As I wrote at 06:06:05 AM, all these methods are not universal.
When you have a lot to do, you can select a part, delete it, select another part, delete it, select another part... now you already cannot use Reset Edit to remove markers, because you will loose all the work that you have done cutting the video. Now, if you go to filters and add some filters, you notice that the markers are still there and you don't need them anymore. If you use Undo, you will remove the filters that you have just added, but the makers will remain in their places. "
Make up your mind before you select markers" seems to work the best but unfortunately, it doesn't help every time :) In the simplest case you can just select something not accurate, look at it and find out that it was much better before the selection. This often happens when the place that you want to cut starts not from an I-frame, and the selection you get goes before or after that place. Another case: you may want to work with parts of the video, select and save all the original streams of the required (best) parts to separate files, and finally do something with the whole video (for example, resize 1080 to 720 to win some HDD space), and again, you need to get rid of the markers before you can do it. Of course you may say "work with the whole video first and then use markers", but this is a never-ending chat. There are many ways of working but we choose the ones that are more convenient to do every single task that we have to do. All I'm trying to say is that I do have to get rid of the markers more often than you may imagine and probably I'm not alone with this issue. If it were a matter of 1-2 times, I wouldn't even raise this subject up. Simple GUI is a great idea but not for the price of losing the ease of use! If one button helps to replace 4 clicks with one click, then it's a worthy button [imho].
You are aware there is a big time deficit on developing side.
Let see what the developer(s) do? Maybe sometime in the (near) future, like tomorrow, next month, next year, next decade, ... .
After all I'm a basic user.
Quote from: acritum on February 22, 2017, 08:45:18 AM
Then make them point to the beginning and the end of the video with one button (actually, bring them to the state they are when the program has just been loaded). By now, we go to the beginning, click A, go to the end, click B, and these are 4 actions instead of one when we need to select the complete footage.
These actions (pressing Pos1, Ctrl+PgUp, End, Ctrl+PgDown) take 2 seconds max (if someone is super slow). This wouldn't justify any effort.
However, these steps don't exactly restore the initial values of the markers (zero for A, the total duration for B). Most videos don't start at zero, so setting marker A initially to zero is strictly speaking invalid. The same applies to marker B, which is initially set to a time sometimes quite far after the last frame. You have a point in the sense that Avidemux doesn't offer GUI for resetting the markers to these, often illegal initial values. Funny enough, this limitation is used by some logic in the application as a way to detect if markers were moved by the user or not.
Nevermind, pull request (https://github.com/mean00/avidemux2/pull/102) filed.
@acritum this could be your lucky day, wait and see.
Quote from: eumagga0x2a on February 22, 2017, 10:02:17 PM
These actions (pressing Pos1, Ctrl+PgUp, End, Ctrl+PgDown) take 2 seconds max (if someone is super slow). This wouldn't justify any effort.
I was in love with keyboard shortcuts when I was using MS-DOS, but Windows makes people kind of lazy. Imagine a user laying on a sofa with a notebook upon his stomach and a wireless mouse in his hand. He controls the system only with the the mouse 99% of the time so he became too lazy to stretch his hand towards the keyboard and press a button. It's a typical Windows user. I know, you Linux guys are of different nature. You spend your life in console and use keyboard 99% of time and only rarely take the mouse in your hand. Of course, shortcuts make you happy, you have 835 shortcuts in your mind for every possible need in your life. I tried to live in Linux maybe 10 years ago but it didn't last long because there were no drivers for my printer, scanner and other rare equipment such as a camera, pocket PC, power meter, digital multimeter with usb out for logging and so on (suppliers of many rare gadgets never make any drivers for Linux), and I had to load Windows too often anyway to work with the equipment. Some powerful software such as Adobe Premiere or 3DS Max don't have Linux versions as well and I need Windows to work with them. Finally, it was too inconvenient to live in 2 OSes and switch between them several times every day, so I gave up using Linux. After good cleaning and configuration, Windows 7 is fast enough on my 10-years old ASUS notebook, runs all modern software and stable enough to rely on.
Another reason why I don't like some shortcuts is that my notebook has a shortened keyboard without a numeric pad and you may break your fingers to press some shortcuts unless you are a certified piano player :) The lack of numeric pad is compensated by the Fn button with some keys in the middle of the keyboard labeled with a very dark blue color on the black background, and it is surely not faster and easier to use them than clicking on a software button. For example, Ctrl-Shift-NumMinus becomes Ctrl-Shift-Fn-P. This is a rare type of keyboards of course and the developers should not take it into consideration, I'm just sharing my experience that shortcuts are not always faster and easier way to do something. If it replaces a bulk of 5 actions, I would probably use it, but if it replaces a button that lays on the screen before my eyes, I'd rather prefer clicking the button. The only exception is made for the shortcuts that are the same in all programs such as Ctrl-A, Ctrl-C, Ctrl-V, Ctrl-X, Ctrl-S, Ctrl-Q. All these buttons are close to each other and can be easily pressed with one hand and closed eyes. But if I need to press Ctrl-Home, I will think twice because I'll have to put the mouse off and free the right hand and stretch it to the keyboard, thus loosing more time and calories /grin/ than when just moving the mouse pointer to some button or menu item.
What I write here is just a set of my thoughts. I don't request or demand anything, just writing here my thoughts about the software. I know that some developers are willing to know the weak points of their software from the POV of a typical user. I'm not a pro as you, but also not a dummy who bought a PC just yesterday. I'm dealing with computers since MS-DOS 5.0 on IBM PS/2 Model 30 with 21Mb HDD and 640Kb RAM. I also was in programming for DOS (Turbo Pascal) and Windows (Delphi). I know users sometimes asked to improve my software by adding strange things that I never needed but finally it's the developer who decides what will be implemented and when. Of course, if I knew that the software crashes for unknown reasons, I would spend time on finding the solution rather than on adding some stupid buttons that only duplicate existing shortcuts. Anyway, thanks for all your efforts, this community seems to be surprisingly alive and active, this is why Avidemux became so powerful.
Those who prefer or have to rely on mouse would be able to reach their goal with two clicks if the patch gets accepted. My concern about a function which extends markers to include an appended video relying on markers still at their initial locations seems to be unfounded: the new ability to reset markers is well aligned with this design IMVHO and doesn't result in unexpected or confusing behaviour.
Just a short note. These guys came to this idea without my hints. It's was simply obvious to them or maybe someone like me asked for it a lot and they decided that it was easier to add it rather than reading "please please!" all the time :) It is made both as a menu item and as a shortcut so everyone is happy :) Also note other useful features to work with the selection in this menu.
The most important feature on your VirtualDub screenshot is a disabled state for menu entries. This should be really implemented for undo/redo entries. Another one on my priority / wish list would be a stepless zoom adjusting to the current window size (but no upscaling) as an option.
There is no such thing as clearing a selection in Avidemux. A selection always exists. Cropping to selection is not bad from the usability standpoint, but not really necessary IMHO. It could be easily added once disabling menu entries has been sorted out.
Quote from: eumagga0x2a on February 23, 2017, 10:20:02 PM
There is no such thing as clearing a selection in Avidemux
OK, I've got it. The selection always exists but it is not always visible. I mean that blue rectangle that appears when we select something and never disappears again until we close the file. The initial idea to clear the selection only supposes that the user becomes able to save the complete video (in situations when the selection exists in the middle of the video and the user cannot save the complete video until he takes any further actions with the selection). From the user's POV, it doesn't matter if the selection doesn't exist or it selects the whole video, because in both cases we save the complete video. If we compare it to VirtualDub, the required action in Avidemux can be identical to"Select All" Ctrl-A. And I like this shortcut because it is classic and universal in all programs (at least in Windows) when we need to "select all", but unfortunately it is already assigned to "Append file" in Avidemux.
I'm going to reach the monthly suggestion count limit, but still there's another one (taken from Virtual Dub).
When saving a large file, it is quite useful if the software could calculate not only average bitrate but also expected final file size using the currently written data size or even the average bitrate during the time the encoding was in progress. It happens too often that some Rate Factor setting that was tested on a short 10-20 seconds footage gives acceptable bitrate, but when it comes to encoding the whole video, the bitrate may increase drastically at some moments. Suppose the file size between 1-2 Gigs can satisfy me, but if I see in the middle of the encoding that the projected file size is going to be above 3 gigs, I'd rather stop the encoding and tweak some settings instead of waiting 3-4 hours only to find out that the file that was finally created is too large and I don't need it. So, knowing what the final file size is expected to be can save a lot of time because the user can stop the encoding if he sees that the file is going to be larger than he expected.
And yet another suggestion [FRAMES] and [SAVE AS BMP].
I'm working with long videos now and I need to select and saveseveral hundred frames from these videos (kind of BMP thumbnails). First of all, I find it more convenient to refer to singe frames by a frame number rather than by time. If I need to remember a single frame to get back to it later, I'd rather write down 3652 as a frame number on a paper, than something like 00:02:11.633. Virtual Dub shows both time and frame number, but I'm not sure if it is possible with all file formats (Vdub works with AVI only). If it is possible, having this reference would be useful. And also a possibility to jump to a frame number (like "Go to time" button that we already have).
The next problem is that the frame saving process is too much boring. It's OK if we need to save one frame, but no more than that... When we press Ctrl-M, the default name shows 20161001_122859.bmp, but it is only fine for one file. If we save many files, we'll have to make up some unique names manually and this is not cool at all. As a solution, I suggest to set default file name to "sourcename_framenumber.bmp" when saving a single image. So, if we save many images, the names would be like 20161001_122859_1.bmp, 20161001_122859_554.bmp, 20161001_122859_15852.bmp... Alternatively (if it's hard to calculate the frame number), time offset of the frame can be used as a suffix making the fname unique (something like 20161001_122859_00_02_11_633.bmp). The work will become even faster if we could save frames without showing the confirmation window at all (as an option). Or maybe ask the target folder and file name template once for the first image, and then name and save the following frames automatically. I know this is not easy to implement and the perfect solution is not obvious, but again, these are just my thoughts and nobody has to do anything to make them real if he doesn't want to. By now I found another solution, I just used ffmpeg.exe to extract all I-frames as BMP files and now review them and select the images that I need to keep and delete the others. This is really faster than saving single images with Ctrl-M in Avidemux and enter and confirm file names for every file, at least now.
A layman's interpretation:
Avidemux 2.6 branch is not a frame based video editor.
AFAIK this means that ADM its not aware of what the video decoder is doing wrt spitting out the next frame from the sequence of virtual frames in the video buffer.
You need to know all about the frame ordering before you can pinpoint a full frame.
Avidemux 2.5 branch was a frame based video editor.
It was doing the frame ordering itself on those simpler codecs.
I other words - its a consequence of dealing with advanced video codecs using time stamps.
Maybe Mean or Eumagga will explain better.
Quote from: eumagga0x2a on February 20, 2017, 07:47:40 AM
It would be interesting to investigate in which situations exactly the program directory gets automatically chosen. This is definitely not right...
Well, now I can tell you. This happens when we install the software ;-) I've just installed 170313 and the "save dialog" default folder was C:\Program Files\Avidemux 2.6 - 32 bits, but it seems to happen only once after installation.
The very first second I ran the software, I seem to have found a new bug: dragging a file to Avidemux seems not to trigger "file opened" state and the software thinks the file is not loaded. I mean, it is actually loaded, but many menu features such as save, append, close, zoom and others are grayed out and not available. This is not happening when we open the same file with Ctrl-O.
Quote from: acritum on March 13, 2017, 05:58:24 PM
The very first second I ran the software, I seem to have found a new bug: dragging a file to Avidemux seems not to trigger "file opened" state and the software thinks the file is not loaded. I mean, it is actually loaded, but many menu features such as save, append, close, zoom and others are grayed out and not available. This is not happening when we open the same file with Ctrl-O.
Are you referring to this issue: Menu access availabilty 2.6.18 / Qt5 (http://avidemux.org/smif/index.php/topic,17587.0.html)
Quote from: eumagga0x2a on February 21, 2017, 06:53:22 PM
I've submitted a pull request (https://github.com/mean00/avidemux2/pull/101) for a quickly thrown together patch implementing your suggestion.
[prefs] Add preference to save in the same folder as the currently loaded video, avoid file name conflicts #101
Please check it out: when dragging a file to Avidemux, it doesn't understand that the file has been opened, so it tries to save not to the directory of the file that was dragged, but to the directory of the last file that was opened with Ctrl-O.
Quote from: acritum on March 14, 2017, 06:12:17 PM
when dragging a file to Avidemux, it doesn't understand that the file has been opened, so it tries to save not to the directory of the file that was dragged, but to the directory of the last file that was opened with Ctrl-O.
Right. Do you really think that Avidemux should behave on drag'n'drop the same way as when loading a video using the filepicker? I sort of like that this doesn't mess with the last read folder record. What about loading a video on the command line? Should it set the last read folder to the location of that video too?
Quote from: eumagga0x2a on March 15, 2017, 06:19:12 PM
Right. Do you really think that Avidemux should behave on drag'n'drop the same way as when loading a video using the filepicker?
I think it depends on workflow habits ;-) Personally I rarely use Ctrl-O dialog to open a file. Here is how I work:
(https://avidemux.org/smif/proxy.php?request=http%3A%2F%2Fsavepic.su%2F7617868.jpg&hash=93122de884fa77c4263f99b56f12dac285625f33)
There is a small explorer window on the right side and 10-50 files in a folder that I need to cut. I drag them one by one and save as source_cut.mp4. Then press Ctrl-W and drag the next file. Since the files source.mp4 and source_cut.mp4 go one by one, I always see what file should be dragged next. When I need to join videos, I do not pres Ctrl-W and drag several files one by one and they become automatically merged (Append function works here). So, drag and drop seems to be the fastest and easiest way of dealing with
many files, so I think drag and drop should behave exactly as Ctrl-O with a single file and Ctrl-A with multiple files to avoid confusion. Of course, if I need to work with one file only, it would be faster to use Ctrl-O but if explorer window is already opened in the right folder, I would prefer drag and drop anyway.
As far as the command line is concerned, I never used it. Maybe you are right here and it should not interfere with GUI features because Ctrl-O and drag and drop are GUI features and command line is not.
Quote from: eumagga0x2a on February 20, 2017, 07:47:40 AM
It would be interesting to investigate in which situations exactly the program directory gets automatically chosen. This is definitely not right [...]
This happened e.g. on a pristine Avidemux install or upon clearing the list of recent items and should be fixed by [file dialog] Go to the homedir instead of the current one if we have no last files (https://github.com/mean00/avidemux2/commit/f17aa23f8b5670712611c22430bbced94242b363).