Recent Posts

Pages: 1 ... 8 9 [10]
Windows / Encoding takes too long (which is the fastest?)
« Last post by avidemoxie on November 09, 2019, 12:27:13 AM »
I have an i7 laptop. Right now am encoding an hour-long video, a 1 GB MKV file. Btw, I am not using my PC to do anything else during the encoding. It has taken 45 minutes and it's almost done. Is this normal?

More info: The video is a screen recording of me video chatting with my teacher.  I used the H264 video codec; specifically, Mpeg4 AC (x264) video output. Only one pass (constant bitrate, 350kbit/s). One video resizing filter. Audio output is Mp3/lame. Output format is Mkv muxer.

The odd thing is I remember using the same settings before on my old PC and that taking half the time it does on the new PC. So it is perplexing.

I'm looking for a way that this take less time without major loss of quality. I know very little about Avidemux but the time issue got me looking at other settings so if you have any suggestions to cut the time, I appreciate you sharing.
Windows / Re: Cut OBS x264 video becomes garbled
« Last post by eumagga0x2a on November 08, 2019, 12:16:14 PM »
No, nightlies are not beta releases, they are just snapshots of the current state of development.

Most of the time, they are both more stable and generally better than releases. They are mostly less polished in sense of translations broken or even more incomplete or such minor stuff. Exceptions confirm the rule. The only drawback is that there are no officially published checksums.
Definitely not a feature. Haven't seen this as I don't use xscreensaver. Does checking the "minimize to tray" checkbox in the encoding dialog help as a workaround?
Example "20191107-154534-214.jpg"
The left 8 digits represents the date = YYYYMMDD
The middle 6 digits represent a time of day = hhmmss, using a 24 hour clock.
The right 3 digits are additional milliseconds.
All fields are padded with zeros, so the full timestamp is always 19 characters long, not including the filename extension (.jpg, .png, .tif, or .bmp).
So the above example represents 2019 Nov 7, at 15h45m34.214s

There's no problem with this sorting correctly under Windows, by name, on an NTFS-formatted drive. Quoting from

The default Sort Order, if you don’t specify anything with /O, on an NTFS drive will be in sort-of-alphabetical order or on a FAT USB thumb drive, then the order will be based on the order in which files were created and deleted and the lengths of their names.

So, now we come to the problem of the image names not being sequential. Using FFMPEG, there is no need to copy or sequentially rename/renumber these files, as FFMPEG can accept a list of filenames. So the first step in this exercise is to produce a set of files that have their frames showing sequential numbers. This will be used to make a set of test JPGS so you can confirm that the correct sort order is used and that no frames are missing: each image shows one frame-number.

Note: I reduced the dimensions of this screen capture to save display space in the forum, so it looks more jagged here than it really is.

If distributed as an un-compressed AVI, this clip would be enormous. But as an MP4 it's only 2.5MB. Here is a 1000-frame MP4, with its frames numbered from 0000-0999, available for download:

While you could use this file to create 1,000 separate image JPGs, which is what I did for much of setting this up, I think 250 frames, which is 10s at 25fps, will be a better choice for when we later change the duration of the sequence, as it makes the mental arithmetic easier. I'd suggest creating a C:\Test directory, copying FFPMEG.EXE to this directory if it's not in your PATH list and, from there, using the md extracted command to make a C:\Test\extracted sub-directory for all the test images.  All our actions will performed from the directory a level up from extracted.

To extract the first 250 images from 1000_sequence.mp4 use:

ffmpeg -i 1000_sequence.mp4  -qscale:v 2 -frames:v 250 extracted\output_%03d.jpg

This will produce this sequence of image files: 20191107-154001-214.jpg to 20191107-154250-214.jpg in the extracted sub-directory. Each is 1680x1050. It doesn't matter here that this is not correct HHMMSS naming. The important thing for this test is that the filename ending ("-214") is not varying sequentially. This will confuse programs that look at the end of the filename to determine the suitability for sequential loading.
-qscale:v 2 controls the quality of the the JPGs. "2" is fine.
-frames:v 250 limits the extraction to the first 250 frames. Leave it out if you want the full 1000 frames.

Now, FFMPEG is flexible enough to auto-load this sequence:

ffmpeg -i extracted\20191107-154%03d-214.jpg -c:v copy test.mkv

But this wouldn't work if the naming format was actually HHMMSS. For that we need to read from a list of name-ordered filenames. This list can also be used to alter the duration each image will be displayed.

Code: [Select]
@echo off
SETLOCAL EnableDelayedExpansion
if exist mylist.txt del mylist.txt
for %%I in ("extracted\*.jpg") do (echo file '%%~fI' >> mylist.txt)   
start /i mylist.txt

The start of mylist.txt looks like:

file 'C:\Test\extracted\20191107-154001-214.jpg'
file 'C:\Test\extracted\20191107-154002-214.jpg'
file 'C:\Test\extracted\20191107-154003-214.jpg'

The concat demuxer in FFMPEG wants each entry in this list to start with "file".
'%%~fI' produces the full pathname. If I had used just "%%I" it would have produced the relative path of

file 'extracted\20191107-154001-214.jpg'

While that works, it's probably safer to use the full pathname.

To assemble the MKV (which will be in C:\Test) use:

ffmpeg -f concat -safe 0 -i mylist.txt  -hide_banner -y -c:v copy output.mkv
-f concat forces FFMPEG to use Concat demuxer, which can read from a filelist, for input.
-safe 0, before specifying the name of the input list, stops the demuxer getting upset over the presence of hyphens in the filename (valid under Windows).

Output.mkv is 10s, 25fps and 17.8MB. If your media player has a blank screen, (probably won't be an issue with MJPEG), include the -pix_fmt yuv420p option.

In actual use, you'd create the list and then use it to concatenate the file and wrap it up a MKV, using just one batchfile, rather than the two, separate operations I've showing here. If needed, you could put a pause command between these two sections of the batchfile, allowing you to delete any untanted lines in mylist.txt in Notepad, before saving the changes, closing Notepad and pressing Enter to continue on to the concatenation stage.

Say the time-lapse action is too fast or too slow in the output file. The file list can include 2-lines per image, with the 2nd line specifying the image duration in secs. To add this feature, change the main line in Create_list.bat to:

for %%I in ("extracted\*.jpg") do (echo file '%%~fI' >> mylist.txt & echo duration 0.04 >> mylist.txt)

The start of the list then looks like

file 'C:\Test\extracted\20191107-154001-214.jpg' 
duration 0.04
file 'C:\Test\extracted\20191107-154002-214.jpg' 
duration 0.04 

An image duration of 0.04s is the duration of one frame at 25fps (40ms). Increasing this will start replicating frames, slowing down playback, while reducing it will drop some image frames, speeding up playback. You can alter the image duration value in the batch line above to suit yourself. 

An example: setting the duration to 0.2 changes the overall duration of the output clip from 10s -> almost 50s. And MediaInfo shows a change in framerate from 25fps -> 5fps.  It also changes the number of frames in the clip from 250 -> 1245. Due to a minor bug in the Concat demuxer, it drops the last image (here, 5 frames) if you specify duration. The work-around for this is mentioned in

(Due to a quirk, the last image has to be specified twice - the 2nd time without any duration directive)

But the small difference in overall duration is usually not worth worrying about.

Despite the reported increase in frames with this playback slow-down, (I checked this out in VirtualDub), the output file is still 17.8MB.


I am using Lubuntu and try to process a set of video files using Avidemux. Great tool and provides exactly the features I need :-)

I noticed that at the moment when the screensaver is turning on (better to say if the screen in blanked and locked) Avidemux pauses processing and continues once a user unlocks the PC. So when I process a longer video file and my screen blanks after 10 minutes I need to move the mouse or I need to continuously walk by my PC and unlock it.

Is this a "feature" or a bug? Can this behavior be turned off? Is this an environment (OS, Desktop, Libraries installed...) dependency or something that is in control of Avidemux? Anybody else seeing this?


Windows / Re: Cut OBS x264 video becomes garbled
« Last post by phaolo on November 08, 2019, 02:19:36 AM »
Ah, thank you. But are those beta releases? Maybe I'll wait for a stable one to be safe.
User interface and Usability / Re: Zoom video to window, is it so hard?
« Last post by eumagga0x2a on November 07, 2019, 11:58:29 PM »
The direct cause of the problem on Windows is the reversed order of resize event and window state change events relative to Linux. On Linux, the window state change signal (transitions between normalized, maximized and minimized states) is fired before the resize event, on Windows it is the other way round.

Seemingly trivial to fix, it turns out to be difficult to get all the details right.
User interface and Usability / Re: Zoom video to window, is it so hard?
« Last post by eumagga0x2a on November 07, 2019, 08:19:18 PM »
...but confirmed with the latest nightly on Windows. The first maximizing step is still ignored, the window has to be normalized and maximized again to enable fit-to-window.
User interface and Usability / Re: Zoom video to window, is it so hard?
« Last post by eumagga0x2a on November 07, 2019, 08:10:21 PM »
This should have been fixed by [mainWindow] Always zoom video on maximize, limit the scope of needsResizing to file, present in 2.7.4, there haven't been any further changes to this code and it works for me with git master upon a quick test on Linux:

1. Launch Avidemux.

2. Load a video (zoom is set to the maximum value with denominator being power of 2 which doesn't push parts of Avidemux GUI out of the available screen real estate).

3. Maximize Avidemux window.

Video zoom changes to a float value to fit increased available space.

Avidemux never upscales a video on load, this is by design. To zoom it to the available size in the window, the window must be resized (or the state changed between maximized and normal) beyond a certain small threshold.

Drag&drop is identical with performing the append action in the "File" menu, this is so by design and is not going to change without a very valid reason. When a file is passed to the code which probes its content, it is too late to decide that we actually wanted to treat it as a frame of a single Motion JPEG video, auto-appended in the "Pictures" demuxer.

Limiting auto-append to sequentially named image files allows to pass a single bounds-checked file name to the demuxer which then can deduce all file names by incrementing a counter. From the point of view of Avidemux, it has loaded just a single file, all the complexity of handling individual images encapsulated and entirely concealed by the demuxer.

However, it doesn't mean that we should waste memory in scenarios with images appended in the editor, [editor] Reduce editor cache size for ultra-short ref videos like images to save memory should substantially reduce memory usage here (the cosmetical part of the changeset unfortunately forgotten in the commit message).

Additionally, a bug in editor (seek to the end broken in a video consisting of individial images appended in the editor) was found and fixed, thank you for your input.
Pages: 1 ... 8 9 [10]