Cannot go to next keyframe

[GZU]

Hi,
On Windows 10,version 2.7.8 64bit version., I'm getting quite a lot of "Can't go to next/previous keyframe" errors.
Is there any fix or workaround for this in 2.7.8?
I've never seen this error before and will probably have to downgrade to previous version as it makes editing hard/impossible.
Thanks.

[eumagga0x2a]

If 2.7.8 fails to seek to some keyframes 2.7.6 could seek to, please provide a sample via WeTransfer, Mega, Dropbox or Google Drive which allows to reproduce the issue.

If it is just a legitimate error, then you can silence (almost) all errors by setting the message level in Avidemux preferences accordingly.

Some background: In 2.7.6 and earlier versions, this error message could multiply until the system became unresponsive. At the same time, sometimes it wasn't shown when it should. Both bugs have been fixed in 2.7.8, meaning that some users may get to see this error dialog more often, but always in a consistent way and without provoking a system crash.

If you got used to seek in Avidemux by continuously pressing up/down arrow keys or previous/next keyframe buttons: please don't, always use the navigation slider instead.

[GZU]

Hi
File below shows the errors in 2.7.8 but not in 2.7.6
https://drive.google.com/file/d/1_qApJV7Y29CJyJOV_BlFI_8-jres0C1Z/view?usp=sharing
Turning off error reporting in 2.7.8 only turns off the error message, I still can't use the keys to get past the error.
I can get past the error using the navigation slider but it does not allow accurate location of segment to cut.
Thanks

[eumagga0x2a]

No errors seeking to any of keyframes in the sample on my system. Please try either with DXVA2 decoding enabled or with the number of threads reduced to 4 or even to 2. Don't forget to restart Avidemux after switching HW accelerated decoding or multi-threading on or off.

From release notes:

Multi-threaded video decoding is now available for the bundled FFmpeg. On powerful multi-core CPUs, this can drastically improve decoding performance. A maximum of 8 threads can be created, but a conservative custom upper limit of 4 is recommended. Values above 8 cause decoding failures. Multi-threaded decoding and HW accelerated decoding are mutually exclusive, changes require application restart to have effect.

[butterw]

I did not encounter any errors with the provided file on Win10 using dxva2+hw-dec.

I only got the cannot seek error msg when seeking beyond the last or first keyframe, which is expected.

[szlldm]

I can replicate the seek error. However it looks like the video stream is damaged:
h264 at 0x55a387d4b320 mmco: unref short failure
h264 at 0x55a38823ec60 mmco: unref short failure
h264 at 0x55a38823ec60 Reference 3 >= 2
h264 at 0x55a38823ec60 error while decoding MB 90 10, bytestream 20487

[eumagga0x2a]

I can replicate the seek error.

With how many threads? In my experience with other interlaced samples, I had to go all the way down to 2 to completely avoid decoding errors with field-encoded streams. With 4 threads it sort of worked, but libavcodec already started to protest.

Please also specify the PTS of that keyframe.

[eumagga0x2a]

CleanTalk misbehaves again, so I post szlldm's message with his permission:

PTS :1185 PTS=47800 ms, 47800000 us
With 4 threads it throw seek error, with 2 wont.
Regardless if single or multithreaded, it indicate errors at that PTS:
mmco: unref short failure
mmco: unref short failure
mmco: unref short failure
Missing reference picture, default is 4
decode_slice_header error
mmco: unref short failure
mmco: unref short failure
number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one

In the my previous reply i checked for error with ffmpeg -v error:
h264 at 0x55a387d4b320 mmco: unref short failure
h264 at 0x55a38823ec60 mmco: unref short failure
h264 at 0x55a38823ec60 Reference 3 >= 2
h264 at 0x55a38823ec60 error while decoding MB 90 10, bytestream 20487

The video stream is clearly broken.

Cleantalk thinks this is spam 

[GZU]

Looks like I've been using avidemux with DXVA2  disabled because until recently I had a pretty basic graphics card.
Turning on DXVA2 gets rid of the errors.  Not sure if this is impacting other users using software decoding?

[eumagga0x2a]

DXVA2 matters for the seek failures ( = decoding failures) only because it disables multi-threading. Using hw accelerated decoding reduces energy consumption which is a good thing on its own, however.

Not sure if this is impacting other users using software decoding?

Of course it does. There is no easy solution yet. Restricting the maximum number of threads to two would be very safe, but at the same time this would give away performance benefits with other types of video streams which can be decoded without issues with 4 or more threads.

So far field-encoded interlaced H.264 streams start to cause issues with more than two threads. Frame-encoded H.264 streams seem to be fine with four. VP9 worked for me even with up to 8. MPEG-4 (divx, xvid) is restricted to 2 (doesn't work with more).

I hope that the reason for decoding failures at a pretty low number of threads will be understood and, when possible (i.e. when we are doing something wrong and not FFmpeg), fixed in the near future.

[hako]

Since there does not seem to exist a thread like this for Linux, I just report my experience with this problem here.
Running the appimage on Ubuntu 20.04, I noticed the problem with 2.7.8, regardless of thread or hw-acceleration settings. Going back to 2.7.6, I found that the problem occurs there also, only without error message. Seeking does not move the position beyond certain points; only play or move the slider can overcome the situation.
I went back to 2.7.4 to avoid the problem.

[eumagga0x2a]

Running the appimage on Ubuntu 20.04, I noticed the problem with 2.7.8, regardless of thread or hw-acceleration settings.

This is a different decoding problem then, with similar symptoms.

I went back to 2.7.4 to avoid the problem.

Please provide a sample which allows to reproduce the problem, preferably with the info which keyframe (frame number or timestamp) cannot be decoded in 2.7.8.

[hako]

My problem under Linux seems to come from defects in the media files. Seeking with the earlier versions 2.7.4 and 2.7.6 also stop at the problem points, and cannot move the pointer a frame or key frame beyond; however, sometimes no error messages are shown with the earlier versions. Playing does not have any problem.
Unfortunately, the limit for attachments is too low.

[eumagga0x2a]

Seeking with the earlier versions 2.7.4 and 2.7.6 also stop at the problem points

This indeed points to damaged video streams or containers.

however, sometimes no error messages are shown with the earlier versions.

Exactly, this issue was fixed on the way to 2.7.8 --> [gui_navigate] Avert DoS from never-ending flood of error dialogs when using auto-repeat for keyframe-based navigation buttons, show error message the very first time seek to previous or next keyframe fails.

Unfortunately, the limit for attachments is too low.

Not relevant for this topic anymore, but in the future, when asked for a sample, please use one of the following services: WeTransfer, Mega, Dropbox or Google Drive.

[fish]

I am also experiencing the problem in v2.7.8 that GZU describes in the first post. The same problem does not occur with the same files using v2.7.7. I didn't have DXVA2 HW ACC on and I do tend to use the up/down keys to seek, so I will give the suggestions a try.