This video uses non-IDR recovery points

[niczoom]

Hi,

I'm using video straight out of my Sony FDR X3000 4K handy cam. I've set the cam to encode 4K 25fps 100Mbps video. In avidemux, I'm doing some basic editing using the up & down keys (Intra frames) as the edit points. When saving this video (copy mode) I get a popup "This video uses non-IDR recovery points ....". The resulting video plays fine until the (edit point) appended video, then the video picture stops and the audio keeps going.

I'm assuming its the built-in encoding of this cam which I can do nothing about unless I re-encode the video?

[eumagga0x2a]

You can try different cut points to find a combination which doesn't result in POC going back. You can also ignore the warning if the resulting video is not meant to be played in ffmpeg-baserd video players (the problem seems to be limited to ffmpeg due to the way how it handles irregular picture order count values). If neither is an option, then you would need to re-encode.

If you can configure the encoder in the camera to output a proper closed GOP stream, this would be really "handy".

[niczoom]

Its a shame, there doesn't seem to be any settings on the  Sony 4K cam regarding this, only a 100/60Mbps option for 4K XAVCS.

On v2.7.3 I don't get this warning, I only started seeing this when I downloaded the latest nightly 2.7.4 r190814.

PS: I always use the up/down arrows to cut on intra frames, this is the correct method right?

[eumagga0x2a]

On v2.7.3 I don't get this warning, I only started seeing this when I downloaded the latest nightly 2.7.4 r190814.

Not getting the warning doesn't mean that the outcome would have been any different, you just could not know in advance whether the saved video would be smoothly playable in vlc & co. or not. Now Avidemux is capable of identifying the issue in advance and warn. If you ignore the warning once, it won't be shown for this particular sort of problem anymore for the current source video during the current Avidemux session.

This feature was added on 2019-07-19 and then refined a bit.

PS: I always use the up/down arrows to cut on intra frames, this is the correct method right?

Yes, it is, always, even in IDR-less streams like those produced by this Sony cam (and many, many DVB broadcasts).

[TCmullet]

I'm running into this problem, too, but with files created by the Hauppauge PVR-2.  2014-2015, I used the PVR-2 a lot, and used Avidemux a lot, editing successfully on I-frames.  I've not used the PVR-2 for a couple years due to unrelated problems it has.  Have been using my Hauppauge Colossus I pci-e card, as it doesn't have the aforementioned unrelated problem.  But my Colossus is down and I have to go back to relying on the PVR-2.

I don't think the PVR-2 is behaving any (or much) differently than in the past.  Only change I've made since 2015 is to ensure that GOPs are never more than 12 frames (with 3 B frames between each I or P frame).

Please help me (us) deal with this new problem that didn't seem to exist before.  I cannot recreate the files, and need to edit them.  On the first edit in the program, I was able to experiment with, maybe, five I-points (there was a LOT of black footage, several seconds), but they all resulted in the long message.  At the very least, I need to know that "accepting the error" will not cause my file to lose audio sync.  But obviously, it must play, as well.

Based on this thread, I probably don't need to share a file sample (but I'd be willing to).   But I can give the message.  This is the text that comes out at each edit point (but not after you say yes the first time).

"This video uses non-IDR recovery points instead of IDR as keyframes. Picture reordering information in the video stream is not reset at non-IDR frames. The chosen start and end points of the deletion may result in playback interruption due to reversed display order of frames if saved in copy mode.  Proceed anyway?"

Then when you're about to save the file, it gives another warning, about the same length but slightly reworded at a couple of spots.

[eumagga0x2a]

The only new thing is the ability to detect the problem. If you ignore the warning once, you won't be bugged anymore for this session and this source video. Earlier, the playback problems in ffmpeg-powered video players (VLC, mpv etc.) due to cuts at keyframes which resulted in POC diminishing were completely unpredictable. Now you get warned.

If the target player is not ffmpeg-based, you should probably ignore the warning (neither my smartphone nor the video player preinstalled on Windows 10 exhibit any problems playing videos with POC going back at recovery points).

If you are sure that the detection lands false positives with the output of your PVR card, please provide a sample.

[TCmullet]

I have no way of knowing, as all we users can see is whether the current frame is an I, a P or a B frame.  (Unless there's a feature I'm not aware of).  Gee life was simple in the Mpeg2 days, ha ha!   (I will upload a sample.)

Yes, I knew that once I say "yes", then the warning never comes out again (at all my edit points for which the warning is relevant), except for the slightly reworded version at the point of saving.

All this is reminiscent of when I used to violate GOP boundaries and get a warning.  It'd give the warning only up to me saying "yes" the first time, then if I said yes at all during the show, it'd give the warning at the save also.  I've since STOPPED doing that as I found it often threw off audio sync when I'd do post processing with DGIndexNV and Virtualdub (in those cases where I needed to).

[TCmullet]

Here's a sample of where a transition has so much black (seconds of it) that one would think there is a clean point somewhere in there, but all points I tested got your warning.

http://www.tomsgoodfiles.com/2019-08-30.1400.TCMullet's-bad-IDR-segment.TS

BTW, this was the very first edit (commercial break) in my first TS file of hundreds to create in the next few months.  I said no and went to the 2nd commercial break.  It too gave the warning.  Are you saying that this problem has been there all along but you simply never detected and warned about it?

There ought to be a way, even without visually seeing which "I frames" are valid for editing, that we could use a key-stroke to jump to the next VALID (editable) I-frame.

[eumagga0x2a]

I had to try really hard to find a combination of the start and end markers to trigger the warning, but I finally succeeded 

Black doesn't matter at all, it is the internal structure of the stream which matters.

There ought to be a way, even without visually seeing which "I frames" are valid for editing, that we could use a key-stroke to jump to the next VALID (editable) I-frame.

I thought of that and dismissed this as not practicable as every A marker position has its own set of "valid" keyframes for the B marker.

[TCmullet]

Yes, black doesn't matter.  But large lengths of black DO allow flexibility in where I cut in order to make an esthetically clean edit.

I don't see why it should be hard to find a trigger.  For the A marker (the marking of the beginning of the commercial break), there was only one I frame between the end of 1st content and the start of the commercial segment.   Then every black I frame after the commercial break triggered the warning.  I could not find a spot that DIDN'T get the warning.  (But I might have missed some.)

[eumagga0x2a]

Are you saying that this problem has been there all along but you simply never detected and warned about it?

Forgot to extra confirm: yes, exactly that.

The problem may disappear one day once FFmpeg changes its handling of POC discontinuities at recovery points and everyone updates to the latest and greatest (did not test with 4.2 or git master yet).