Avidemux Forum

Quote from: RocketJet on September 02, 2024, 03:23:02 AM

Quote from: blazini36 on September 01, 2024, 07:37:16 AMHandbrake usually picks the angles up but it's failing on this one,

Try DVDShrink in Re-Author mode. It has the capability of selecting a specific angle,
and can produce lossless output. It's free, so you haven't lost anything if it does not work..

I don't often use Windows so I was reluctant to bother trying this but it looks like it does work. Thanks

Well, finally, I was able to test on Windows with my own cross-build and yes, no extend() with that build either. Therefore, please replace the relevant section of the script with

if upperList is not None:
    if not fullList:
        fullList = upperList
    else:
        fullList += upperList
The script works fine for me with this change.

Hello,
i have some information and maybe it can help to fix the issue with the transparent window under Wayland.

I run Avidemux on Fedora with QT6 and Wayland. As known, there is the issue with the transparent video window.The xcb option solves the issue but runs Avidemux via XWayland and not natively under Wayland.

A long time ago when I switched from Windows to Linux I searched for program to cut my mpg2 files. I found ttcut in the Internet and used it. I ported it from qt4 to qt5 and now compiled it under QT6. It also uses OpenGl. I got the same problem as Avidemux under Wayland. The Video frame got transparent under Wayland. Using the xcb option solved the issue.

By accident I found the reason for the issue. The code used the method glClearColor(0.0f, 0.0f, 0.0f, 0.0f) to set the black background of the video window of type QOpenGLWidget (PS: the default values are also all zeros). The last parameter of this method is transparency. The value 0.0f means fully transparent and this is what Wayland is doing. It seems that X11 ignores this. I changed the value to 1.0f and now the program runs without the xcb option natively under Wayland and QT6. No issue with a transparent video frame.

Maybe the issue in Avidemux is similar and could be solved easily.

Set environment variable ADM_NOINDEX_MP4 to 1 to disable loading and saving the results of decoding frame type in MP4 files. The feature saves sometime minutes of waiting when opening a large MP4 file with a H.264 video track a second time.

Same error. Does "later version" mean VC++ (compiled natively on Windows) or MinGW (cross-compiled for Windows on Linux)?

Quote from: eumagga0x2a on September 07, 2024, 10:43:17 PMMXE has been regenerated. Presumably due to a packaging error an old (v3.5) libx265.dll got packaged with the new Avidemux cross-compiled build where the x265 plugin had been compiled against x265 v3.6.

Big thanks! I test new build v2.8.2 r240907 in to download Digiraty WinX MPEG 4 part 10 file "test.mp4"- real MPEG-TS use Nvidia H264 and Nvidia HEVC encoder on system:

Xeon E5 2697v2 / Intel MD82C602J / 64 (4 x 16) REG ECC DDR3-1866 Quad Channel / NVIDIA GTX 16600 Ti, OS Win7 SP1 x64 and NVIDIA driver R474.44 x64

both test success, Huawei MediaPad M5 Lite 10 (SoC Kirin 695) play test video success, w/o error's or lost frames.

H.264 test (Process Hacker SI, CPU load, GPU load):



H.265 test (Process Hacker SI, CPU load, GPU load):



bug fixed, OK!.

Just upgraded to the later version and now the error has changed. 

Also happens with MP4 files since few builds ago, super annoying, cant disable ?

Understood. So far, I "chewed" - corrected the name of the call - he believes that the video was not damaged. True X265 I checked for not the largest video, but the Huawei Mediapad M5 Lite 10 tablet lost without problems. And x264 - there just "gift" came - Winx YouTube Downloader V6.8 (Latest) when downloading with RUTUBE if you come across a video with a constant framework in 70% of cases will save it with variables and the equipment does not take this, or the downloaded utility had the size of a gigabyte , and the saved file is hundreds of megabright and damaged - choose less resolution and download again. So you have to catch in ./<target>/<random*>/temp.mp4, make a hardlink on it with the name ../<<name>.TS because Hosting gives MPEG-TS, and FFMPEG 4.2.2 built in WinX converts him "correctly". And if the same .ts counting in ADM there are no errors. The only thing you have to is to use the Resample filter indicating the frame rate - otherwise we will get a variable and indicate the parameters of the recoding sound - the reasons are the same. Well, the source is such, adapted.

MXE has been regenerated. Presumably due to a packaging error an old (v3.5) libx265.dll got packaged with the new Avidemux cross-compiled build where the x265 plugin had been compiled against x265 v3.6.