2.81-release (64,W10) incorrectly saves edited video encoded AOM AV1 by OBS

[OCE]

First of all: Avidemux is THE great software by all means! Very big THANK YOU to all of you involved in Avidemux, you make this cyberworld a beter place  

Edited file was: merged in Avidemux 2 files of recorded screen grabbed with OBS studio, encoded AOM AV1, CPQ=50, base 1900x600 downscaled to 960x540, saved mkv and VLC plays both OK before editing. I edited: merged in Avidemux (open 1st and then open 2nd in Avidemux) deleting fragment betweem A&B markers (1st cutting point) and cut&past at end of file fragment between other A&B markers.

If I posted this in wrong place then kindly ask moderator to move it to place where this should be posted. Sorry, I am new here.   
1) finding next/previous key frame with [>>] or [<<] sems to me failing to find the nearest key frame, like it normaly does when mkv x264 encoded is edited. It jumps even a few minutes foreward or backward what makes editing senseless, as that would be about 10-20 key frames in whole about 2h video - perhaps Avidemux can't recognise keyframes properly when AV1 encoded?
2) Because of above in 1) I set A&B markers finding nesessary frames with jump to specific time and then using [>] and [<] frame by frame - what is not the most convenient way ofc , and deleted set fragment with Avidemux red (X) button. Cutting points were not in key frames. 
3) 1st time when tried to save obtained: "muxer can't be loaded". Closing some tabs in browser in YT solved this, lack of free RAM obviously, mentioned here just for every case.
4) 2nd time, before saving displayed warning "in copying mode but cutting points not in key frames, video will be damaged there, do you want to continue despite of this?" After "yes" edited video was saved, appeared info about "sucsesfully saved", but it was saved not correctly: at first cutting point, marked A, video was frozen and still image of this one frame remains to the end. Audio was saved OK as edited. Settings of video output and audio output were "copy". I tried output format mkv and mp4 (as in one of posts at forum here I've found something like "mp4 is AV1 compatibile" or similarly. But in both cases mkv and mp4 the effect was a frozen frame from 1st cutting point to the end, with correct audio, in saved file. While in Avidemux internal player edited file plays OK as edited.
5) Inside Avidiemux 2.81 - release (64) the file from OBS studio  video encoded with AOM AV1 plays correctly after my edition, but when it was saved then in VLC it plays with still image from 1st cutting point to the end, both mkv and mp4. With x264 video files from the same OBS studio it has never happened with Avidemux so far, hence I suspect it is about AV1 support in Avidemux perhaps.
6) AOM AV1 encoder outputs for me even about 40% smaller files with compareable quality and seems to me AV1 is replacing x264 and x265 also. Also I am changing permamnently to AOM AV1, well in fact I haven't yet completely because of described above problem in Avidemux 2.81. Could you improve editing and saving with AV1 to be as functionally as it is with x264 now?
7) Perhaps I caused this failure. Could you give me any advise what could I change or use? Or what am I missing? How to edit and correctly save AV1 encoded video? This does not work ATM, at last for me.

THX in advance. 

Anyway change to AV1 as default encoder is unstopable by all means in predictable perspective I think. Especially when, to my best knowleadge, it is open source and free, hence no payments for legal use and even 40% smaller output files motivates many IMHO. So I think it is needed in Avidemux, at last for me, as I am going to use AV1 as default encoder, instead x264.

If I posted this in wrong place I ask moderator to move it to proper place - sorry, I'm newbie here.

[eumagga0x2a]

Please provide a sample which allows to reproduce the issue with keyframe-based navigation via WeTransfer, Mega, Dropbox or Google Drive.

1. In case of MKV with a H.264 video track, Avidemux decodes slice headers to verify whether a frame is a keyframe. In case of AV1, it trusts the container. Technically, a video with a single keyframe at the start may be fully valid (but unseekable, of course), impossible to tell without having looked at a sample first.

2. If selection end is not on a keyframe, you cannot delete the selection when in copy mode and expect to get anything useful as the result, period.

3.

4.+5. See 2.

6. Saving in copy mode in MKV should be fine, but need to have a look at sample(s) first.

7. The general rule is always to use the latest nightly whenever possible as long as there hasn't been an explicit warning pinned in the forum. However, I don't remember any changes related to AV1 handling since the last release (which is very old now), so I wouldn't expect much difference in this regard.

As hardware with AV1 decoding capabilities slowly spreads, AV1 becomes more and more viable, but it is a poor choice when it has to be decoded in software. The software encoder for AV1 is AFAIK still terribly slow.

As I have finally upgraded my hardware, some progress related to AV1 hw decoding and sw encoding can be expected medium term.

[Elstar`]

Btw, in case of Avidemux copy mode, there should not be a B-frame before selection start, P is ok usually.

Indeed, never save a video that ends not on keyframe in copy mode, you will damage the next segment. When it warns about something like non-IDR, you cannot cut on specific keyframe without damaging next segment and should try the next one.

I wonder, if AV1 codec uses the same I/P/B frame logic as H264, though...

[eumagga0x2a]

I wonder, if AV1 codec uses the same I/P/B frame logic as H264, though...

AV1 way to do frame reordering is called Superframe, similar to a sequence of P- and B-frames, but mashed together in one frame. A decoder outputs multiple pictures (all flagged as P-frames) in display order from a single superframe.