Audio Frame Cuts for audio copy mode

[Cormy1]

I recently installed MP3DirectCut and was rather amazed by it.
Would it be possible to get a similar function in Avidemux so that we can edit audio on "keyframes" just as we do video without needing to re-encode?

The primary purpose of this is for importing external audio tracks that need to be offset by a greater value than permitted in Avidemux.

When video is edited in copy mode, what happens to the audio in copy mode? Is it also cut on audio frames and then accordingly offset or does the entire audio track remain intact while being offset to match the cut duration of the video? Especially when shift is applied, I'd assume the entire audio track is still retained while simply being shifted in playback.

A visual audio reference track like that in MP3DirectCut would also be tremendously helpful, since audio playback always mismatches video playback that doesn't match AviDemux's playback rate (again this 60fps video problem vs 30fps playback)

[eumagga0x2a]

Would it be possible to get a similar function in Avidemux so that we can edit audio on "keyframes" just as we do video without needing to re-encode?

This is what "copy mode" for audio does.

The primary purpose of this is for importing external audio tracks that need to be offset by a greater value than permitted in Avidemux.

You should use

Code Select Expand

ffmpeg -ss <offset in seconds> -t <duration in seconds> -i <input audio file name.extension> -c copy <output audio file name.extension>
to roughly trim the source for the external audio track. This works for mp3 and ac3, but not for aac (neither raw nor ADTS-encapsulated).

When video is edited in copy mode, what happens to the audio in copy mode? Is it also cut on audio frames and then accordingly offset or does the entire audio track remain intact while being offset to match the cut duration of the video? Especially when shift is applied, I'd assume the entire audio track is still retained while simply being shifted in playback.

Audio is always cut off (all later packets dropped) at the end to match the duration of the video. The delay is eventually written to the container by the muxer, if the container supports this and the library doing the muxing thinks it is necessary.

If the shift value is negative, packets which are too early for the start are dropped too.

A visual audio reference track like that in MP3DirectCut would also be tremendously helpful, since audio playback always mismatches video playback that doesn't match AviDemux's playback rate (again this 60fps video problem vs 30fps playback)

I don't think waveform display makes sense in Avidemux. There are great video editors with all the bells and whistles. Avidemux can't and IMHO should not try to compete with them.

The GUI becoming unresponsive at 60fps problem is a Qt event handling / screen repaint issue, probably related to multithreading or lack thereof (I don't know yet). If your hardware is not capable of decoding and displaying 60fps at given resolution in real time (assuming you have enabled hardware accelerated decoding, which you really should do), a future fix for the Qt issue won't help here at all.

[Cormy1]

I don't mean unresponsiveness, I just mean playback speed is capped at 30fps, so any 60fps content immediately has sync issues within Avidemux.
This isn't a decoding speed issue, it's just Avidemux doesn't playback at 60fps.

[eumagga0x2a]

I just mean playback speed is capped at 30fps

This is generally untrue. I don't observe this behavior contrary to the Qt GUI responsiveness issue with your sample on my really old hardware with H.264 at 1080p at 60fps (I do experience it with HEVC).

You can test the pure decoding + color conversion speed by selecting the "null" video encoder.

[Cormy1]

null encoder is only for outputted video though...?
How can I use it? Doesn't seem to work with MKV muxer which I found weird.
On AVI muxer I see it encoding about 45 frames/second.
What does this mean?
I have always had this issue, and I'm on an i7-5700HQ with a GTX 950m

Why would this issue exist solely in Avidemux when I can playback the files fine outside of Avidemux?

[eumagga0x2a]

null encoder is only for outputted video though...?

The null encoder is for benchmarking purposes only, to test how fast decoding and filtering is. As the name says, it doesn't provide any output. You should combine it with the dummy muxer, which also doesn't output anything.

On AVI muxer I see it encoding about 45 frames/second.
What does this mean?

It means Avidemux on your system with current settings is unable to decode the source video in real time, which is strange as I get ~ 100 fps with your sample using decoding in software on my 8 years old dual-core Athlon II, mid-tier back than, absolutely low-end nowadays.

[Cormy1]

Running on i7-5700HQ with GTX 950M on Win8.1

[eumagga0x2a]

Off-topic:

Code Select Expand

[extractSPSInfo_mp4Header] 04:46:45-385 Context created, ticks_per_frame = 2
Used bytes 0/40 (+5)
Scale : 120000, tick=1001, fps=59940
Taking crop into account, left: 0, right: 0, top: 0, bottom: 8
[extractSPSInfo_mp4Header] 04:46:45-385 Width2 : 1920
[extractSPSInfo_mp4Header] 04:46:45-385 Height2: 1080
[extractSPSInfo] 04:46:45-386 width:1920
[extractSPSInfo] 04:46:45-386 height:1080
[extractSPSInfo] 04:46:45-386 fps1000:59940
[extractSPSInfo] 04:46:45-386 hasStructInfo:0
[extractSPSInfo] 04:46:45-386 hasPocInfo:1
[extractSPSInfo] 04:46:45-386 CpbDpbToSkip:0
[extractSPSInfo] 04:46:45-386 log2MaxFrameNum:4
[extractSPSInfo] 04:46:45-386 log2MaxPocLsb:5
[extractSPSInfo] 04:46:45-386 frameMbsOnlyFlag:1
[extractSPSInfo] 04:46:45-386 darNum:1
[extractSPSInfo] 04:46:45-386 darDen:1
[parseStbl] 04:46:45-386 stts:0
[parseStbl] 04:46:45-386 Time stts atom found (1166)
[parseStbl] 04:46:45-386 Using myscale 90000
[parseStbl] 04:46:45-387 Stss:8
[parseStbl] 04:46:45-387 ctts:0
[parseStbl] 04:46:45-387 Found 1173 elements
[parseStbl] 04:46:45-387 0 frames /1173 nbsz..
[parseStbl] 04:46:45-387 nbCo: 843
[indexify] 04:46:45-388 Build Track index, track timescale: 90000
[indexify] 04:46:45-388 Histogram map has 2 elements.
Frame duration 1501 count: 585
Frame duration 1502 count: 587
[indexify] 04:46:45-388 Video index done.
[indexify] 04:46:45-388 Setting video timebase to 1 / 90000
I wonder whether Avidemux is at fault here or you have chosen to override the time base. Actually, it should be 1001 / 60000 with all frames having uniform duration. It might help to remux to MKV and back to MP4 to get rid of jitter.

Now back to the topic: The log shows that you indeed get very low decoding speed (~41 fps) when performing decoding in hardware. Could you please retry with DXVA2 decoding disabled?

Meanwhile, I have benchmarked both latest official Avidemux nightly builds for Windows on my Windows 7 installation in software decoding mode using your sample. I get the same values about 100 fps as on Linux – on a CPU which is significantly slower than yours.

[Cormy1]

Where do I disable it?
There is the HW Accel options "Decode video using DXVA2 (Windows)"
But also the Display option "Video Display: DXVA2"
Does sdl driver matter?

[eumagga0x2a]

Where do I disable it?
There is the HW Accel options "Decode video using DXVA2 (Windows)"

Selfquote:

Could you please retry with DXVA2 decoding disabled?

It is the former then.

If it turns out to be that choosing video decoding purely in softwarte rather than in hardware helps with decoding speed, we'll see whether display poses a problem too or not.

Does sdl driver matter?

No, it doesn't. The log shows that the primary problem is decoding, not display.

[Cormy1]

That solved it. Why would I be getting this behaviour? Could it be the result of it being run on the intel iGPU rather than the dedicated NVidia card?
I tried changing the settings to force the use of the NVidia card in the NVidia control panel and using DXVA HW Accelerated decoding improved my results quite a bit.
So I guess that solves that mystery, iGPU fail.

Unrelated, but someone sent me an interesting WebM whose playback frame size seems to change dynamically? It starts out small and increases in steps.
After importing it to Avidemux, pressing pressing play or seeking at all immediately gives a fatal error.

https://files.catbox.moe/af07ge.webm

[eumagga0x2a]

That solved it. Why would I be getting this behaviour?

Bad graphics drivers? Intel iGPU, at least gen. 6, are quite good, especially at video stuff.

someone sent me an interesting WebM whose playback frame size seems to change dynamically?

Variable video dimensions are completely unsupported in Avidemux, we should safely crash on such input. No need to try.