News:

--

Main Menu

Broken Navigation - Two Most Recent Nightlies

Started by jimmy, December 27, 2023, 11:16:35 PM

Previous topic - Next topic

jimmy

Hello.

Once with the Dec 17 nightly and twice now with the Dec 23 nightly all the "go to"
navigation features break. Even the slider can not reach first or last frame.

The first two times I was appending, today it was a simple copy/paste from the start
of the project to the end which broke the navigation. "Go to first frame" took me to
the cut point near the end of the project, first and last frame became inaccessible.

But it is tricky and hard to duplicate because it does not happen immediately.
For example, I load the project, do any appending or copy/paste, check the cut
points, check all the navigation options, everything is perfectly normal. Then
I select a small segment of the project to test encode and figure out settings.
By the time I am done and reset the A and B markers, the navigation is broken.

Work around is simply close ADM, reload the project pretty much the same way I did the first time, but
now I know all the settings/filters I can start the encode before any navigation problem presents itself.

Today when navigation broke I tried "Reset Edit" and got a warning box and crash. ADM log attached.

https://we.tl/t-gfvmr30nni

jimmy

Update:

OK, so when I subsequently ran the project in the above post that caused a crash (Dec 23 nightly)
the target file size was much lower than entered and the encode was riddled with frozen frames.

I tries resample to 23.976 and the target size was met, but still the same frozen frame problem.
Both encodes had the right number of frames, but a massive amout of duplicates in both cases.

I rolled back to the Dec 10 nightly and ran the exact same project script, without resample fps.
The file size target was met and there are no duplicate frames. ADM logs attached for both.

https://we.tl/t-4V1JSSA4WM
https://we.tl/t-kRzbadUCUp

eumagga0x2a

Things go south when the graphics driver stops supplying Avidemux with hw surfaces to store decoded video frames. There have been zero relevant changes between Dec 10 and Dec 23. Will try to look deeper into the logs later.

eumagga0x2a

Is the problem specific to a particular source video? 16 ref frames and an average total (audio + video) bitrate of about 17 MBit/s at a resolution of just 720x480 are pretty intense^insane.

In any case, please provide the project script able to trigger the issue.

As a workaround, please try disabling the DXVA2 hw decoder and enabling the NVDEC one (the latter is able to allocate hw surfaces dynamically). If, despite successful probing, NVDEC doesn't work with your hardware where presumably only the Intel GPU is directly connected to display while the NVIDIA one writes to a buffer managed by the Intel graphics driver, please try disabling hw decoding entirely.

If the DXVA2 hw decoder runs out of hw surfaces, there is no way back other than closing the video.

jimmy

#4
Thanks for your time, hope I am not wasting it.

Quote from: eumagga0x2a on January 02, 2024, 10:59:37 PMIs the problem specific to a particular source video?

No. That's the thing. Exact same problem, unseen before, three projects, over about 10 days, two different builds.
Only with the third problem project did I even consider posting here. Ultimately, all projects turned out fabulous.

1st - (DEC 17 nightly) Bluray, 1080p, mkv, encoded to about 10GB, re-encoding with an append operation
2nd - (DEC 23 nightly) Full Bluray, remux, mkv, about 23GB, encoding with an append operation
3rd - (DEC 23 nightly) DVD, decimated in handbrake at ridiculous, very slow rate factor 4, ecoding with copy paste operation

Since your last post, I can pretty much consistantly, not quite invariably, recreate the problem with DXVA2 in all
three recent nightlies, with a bit of difference. Encodes are worse with even more duplicate frames, navigation not
frozen but main window playback is like the encode, occasion live frames but with long duplicate frame display.

I can not recreate with HW disabled or with NVDEC. For your information, I have been using DXVA2 for years. Original project script attached.

One observation, the bottom left input pane is flashing a lot of "video is late by XX ms" warnings when playing
in main window. This is occurring with a variety of input files, with HW disabled, with NVDEC and with DXVA2.

https://we.tl/t-JSOyY3tF4a

eumagga0x2a

#5
Thank you for the project script. I would strongly recommend not to exaggerate with MaxRefFrames for the sake of compatibility with various hardware decoders. I would not go beyond 6.

Quote from: jimmy on January 03, 2024, 11:58:06 PMI can not recreate with HW disabled or with NVDEC.

Good, please use NVDEC then. I'll try to look at DXVA2 later.

Please provide (as attachment or via WeTransfer) the output of mediainfo for all source videos where we run out of available hw surfaces with DXVA2.

Quote from: jimmy on January 03, 2024, 11:58:06 PMOne observation, the bottom left input pane is flashing a lot of "video is late by XX ms" warnings when playing
in main window. This is occurring with a variety of input files, with HW disabled, with NVDEC and with DXVA2.

This is a feature kindly contributed by szlldm and a purely informational one. Before that, there was no way to detect and especially to quantify loss of sync due to slow decoding / post-processing during playback.

jimmy

Quote from: eumagga0x2a on January 04, 2024, 07:24:40 AMexaggerate with MaxRefFrames

Understood. With full concern about hardware compatibility this is the guide I have been using:

https://planetcalc.com/3321/

Quote from: eumagga0x2a on January 04, 2024, 07:24:40 AMuse NVDEC

Ok, and is openGL video display best with NVDEC?

Quote from: eumagga0x2a on January 04, 2024, 07:24:40 AMmediainfo for all source videos

Alas, none of my projects are for my own consumption, thus the rather exaggerated settings, I would be content with a quick and dirty ultrafast encode.
I archive nothing. Especially since I was blaming myself for the first two problem encounters those are gone, I only have mediainfo for problem three.

I should have several projects on the go for the next few days, I shall keep using DXVA2 for now, just to see if I can get more relevent information to you.

You cannot view this attachment.
You cannot view this attachment.

eumagga0x2a

Quote from: jimmy on January 04, 2024, 04:51:37 PMis openGL video display best with NVDEC?

No, please keep using "DXVA2" (actually, DirectX) video display on Windows whenever possible. Just not the hw decoding infrastructure (the true DXVA2).

Quote from: jimmy on January 04, 2024, 04:51:37 PMI shall keep using DXVA2 for now

You might also try to reduce the size of editor cache in Avidemux from 16 to 12 or even to 8, which should theoretically reduce the number of hw surfaces in use.

jimmy

#8
Found partial mediainfo for the second problem project on the web, the full bluray one that I erroneously described as a remux in the earlier thread:

Disc Title: redact
Disc Size: 28,602,071,040 bytes
Protection: AACS(v6
Playlist: 01002.MPLS
Size: 27,553,892,352 bytes
Length: 1:37:38.853
Total Bitrate: 37.62 Mbps
Video: MPEG-4 AVC Video / 34000 kbps / 1080p / 23.976 fps / 16:9 / High Profile 4.1
Audio: English / DTS-HD Master Audio / 2.0 / 48 kHz / 1668 kbps / 24-bit (DTS Core: 2.0 / 48 kHz / 1509 kbps / 24-bit)
Subtitle: English / 36.317 kbps

eumagga0x2a

Quote from: jimmy on January 05, 2024, 06:23:29 PMTotal Bitrate: 37.62 Mbps
Video: MPEG-4 AVC Video / 34000 kbps / 1080p / 23.976 fps / 16:9 / High Profile 4.1

Thank you, the number of reference frames would be the matter of interest here, other pieces of information not that much.

jimmy

Quote from: jimmy on January 03, 2024, 11:58:06 PMsame problem, unseen before, three projects, over about 10 days, two different builds

If it were not for the above observations, I would feel even more foolish.

As it is, over a dozen encodes, a variety of input files, unchanged DXVA2 settings, no problems at all. Thanks.