Bugs report + suggestions

[acritum]

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.

[eumagga0x2a]

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.

[acritum]

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.

[acritum]

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.

[acritum]

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.

[AQUAR]

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.

[acritum]

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.

[Jan Gruuthuse]

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

[acritum]

I've submitted a pull request 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.

[eumagga0x2a]

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?

[acritum]

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:



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.

[eumagga0x2a]

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.