Recent Posts

Pages: [1] 2 3 ... 10
1
Avidemux-German / Re: Linux Intel Quicksync QSV
« Last post by hylli on Today at 07:36:01 AM »
Habe gestern Abend/Nacht noch auf 2.7.6 aktualisiert. Hat sich leider nichts geändert.

Werde heute Abend mal ein kurzes Video entsprechend neu Kodieren und das Log dann anhängen.

Hylli
2
Avidemux-German / Re: Linux Intel Quicksync QSV
« Last post by eumagga0x2a on July 05, 2020, 08:03:56 PM »
Ich kann im Augenblick nicht selber testen. Bitte ein kurzes H.264 Video mit aktivierter Dekodierung durch LibVA mit einem der beiden libavcodec-basierten LibVA-beschleunigten Encoder neu kodieren, Avidemux beenden und admlog.txt aus dem Home-Verzeichnis komprimieren und anhängen.

Code: [Select]
avidemux3_qt5 > ~/admlog.txt 2>&1
Vielleicht davor noch auf den 2.7.6 Release aktualisieren.
3
Windows / Re: avidemux
« Last post by eumagga0x2a on July 05, 2020, 07:55:07 PM »
Copy the installation directory of an older VC++ build to another location (you may delete the maintenance tool, it is not needed), then install 2.7.6 VC++. This will uninstall the older version, but you have a copy which you can run from any location (at least from any local one).

Just never run both at the same time.
4
Windows / avidemux
« Last post by lenin38 on July 05, 2020, 07:15:29 PM »
good day how can I have installed both versions of the program in window 7  Avidemux_2.7.5 VC++ 64bits 200626  and  Avidemux_2.7.6 VC++ 64bits   
have both versions installed in window 7 :'(
5
Avidemux-German / Re: Linux Intel Quicksync QSV
« Last post by hylli on July 05, 2020, 06:50:20 PM »
Hi,

ich habe das gleiche Problem wie @kristatos. Ich habe eine Core i7-6700 CPU, mit der ich gerne HW-Beschleunigung nutzen würde.

Bei mir läuft eine Avidemux Version 2.7.5 vom 15.06.2020 unter Linux Mint 19.3, kompiliert aus dem Master Git, allerdings ohne den nVidia/nVenc betreffenden Teil.

Nutze ich ffmpeg im Terminal, funktioniert die HW-Beschleunigung sowohl beim Decoding wie auch beim Encoding.

Wenn ich in den Einstellungen von Avidemux HW-Beschleunigung via LibVA aktiviere, funktioniert wenn dann nur das Decoding. Das Encoding/Rendern eines Films von z.B. 83 Minuten, dauerte damit noch rund 60 Minuten bzw. evtl. die ein oder andere Minute mehr.

Nachdem ich HW-Beschleunigung via LibVA in den Einstellungen deaktiviert habe, dauerte der Vorgang bei diesem Film nur noch 22-23 Minuten.

Das ließ mich vermuten, dass bei mir das gleiche Problem besteht.

Lösung?

Hylli





6
User interface and Usability / Re: Non English input controls in edit preferences and Video output configuration
« Last post by JayMistry on July 03, 2020, 09:58:29 PM »
Thanks again

Let me give you some good news as you do not have to churn your code

I removed all the languages from Control panel Language page and just left the English (United States) and added English (Australia) to keep my regional format settings.

Straight after making this change Avidemux is showing all the digits in English.

What I have learnt from this is that windows can give you unexpected surprises by going away from the language it is coded in.

I appreciate all you help in resolving this issue
7
User interface and Usability / Re: Non English input controls in edit preferences and Video output configuration
« Last post by eumagga0x2a on July 03, 2020, 01:28:39 PM »
The native digits shown on screenshots seem to be actually Devanagari, but no matter which particular language is really in use, I cannot find a way to make Avidemux or any other application on my admittedly Linux desktop use native numerals instead of default Arabic. Without ability to test, no development is possible. Any help is appreciated.
8
Windows / Re: Consistent Invalid timestamps error while muxing from mkv to mp4.
« Last post by Amey8a on July 03, 2020, 01:11:08 PM »
Quote from: eumagga0x2a on July 03, 2020, 12:25:01 PM
Quote
a) Is it necessary to add this delay when none of ffmpeg or mkvtoolnix adds any?

This is the result of design decision to use unsigned values for timestamps in Avidemux, contrary to signed values in ffmpeg. For this reason it cannot shift decode timestamps of the first few frames into the negative range if B-frames are present to align the zero point of the timescale with the earliest PTS (in case of Avidemux, with the PTS of the first keyframe).

Quote
b) What will happen if the audio/video is not shifted at all?

uint64_t used to store DTS wraps around for the first few frames i.e. appears in a distant future, in any case the video won't play.

Thats the correct answer I was looking for. So, as the muxing is going well now, I will be muxing my entire library of MKVs to MP4s without worrying for cfr to vfr issue and the dts errors anymore, thanks to this current build and the builder.

Believe me, I have encoded more than 10 videos just because of the dts error, thinking that the copies that I have might be damaged as avidemux never failed on me before i.e. when I was using release build 2.7.5. But after realizing that the error occurred at the same timestamp with current builds, I had to at least ask if it is just me or the error happened to anyone else.

The current ffmpeg also have issues in maintaining the source framerate mode when muxing using copy, so I will also need to speak to them on this matter.
9
Windows / Re: Consistent Invalid timestamps error while muxing from mkv to mp4.
« Last post by eumagga0x2a on July 03, 2020, 12:25:01 PM »
Quote from: Amey8a on July 03, 2020, 11:24:05 AM
2. The result is really awesome for mkv to mp4 muxing. No dts error in testing. The output mp4 agrees with ffmpeg and mediainfo as a true cfr video.

Great, thanks, the fix seems to work.

Quote
a) Is it necessary to add this delay when none of ffmpeg or mkvtoolnix adds any?

This is the result of design decision to use unsigned values for timestamps in Avidemux, contrary to signed values in ffmpeg. For this reason it cannot shift decode timestamps of the first few frames into the negative range if B-frames are present to align the zero point of the timescale with the earliest PTS (in case of Avidemux, with the PTS of the first keyframe).

Quote
b) What will happen if the audio/video is not shifted at all?

uint64_t used to store DTS wraps around for the first few frames i.e. appears in a distant future, in any case the video won't play.
10
Windows / Re: Consistent Invalid timestamps error while muxing from mkv to mp4.
« Last post by Amey8a on July 03, 2020, 11:24:05 AM »
Quote from: eumagga0x2a on July 03, 2020, 09:33:46 AM
Nightly builds with changes which should fix the dts issue with MKV videos are available. MinGW 64bit build for Windows: https://avidemux.org/nightly/win64/

So, I did further testing for mkv to mp4 muxing using current avidemux build 20200703 with following files,

1. Mkv from mkvtoolnix
2. Mkv from avidemux
3. Mkv from ffmpeg,

Here are my results,

1. Avidemux_mkv always selects 83ms as a zero as seen from avidemux admlog which does not happen in case of  ffmpeg_mkv or mkvtoolnix_mkv.

2. The result is really awesome for mkv to mp4 muxing. No dts error in testing. The output mp4 agrees with ffmpeg and mediainfo as a true cfr video.

3.Output mp4 always delays audio tracks by -83ms (i.e delays video by 83ms) for all videos to keep pts>dts, my question is,

a) Is it necessary to add this delay when none of ffmpeg or mkvtoolnix adds any?
b) What will happen if the audio/video is not shifted at all?
Pages: [1] 2 3 ... 10