non-IDR recovery points

[jchhenderson]

I am only ever cutting/trimming video recorded from my HDHomerun box - they are ts files.

When I record HD video, I sometimes get the below error when cutting a section.  However, it can be OK and not-OK in the very same file.  When it is not OK, I cannot cut as the result is bad.

How is it possible that it can work and also not-work in the same file and is there anything I can do about it?

thanks,
James.

---
Full message:
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 cut may result in playback interruption due to reversed display order of frames if saved in copy mode.
Proceed anyway?

[eumagga0x2a]

First of all, please update to the last macOS nightly, the release version contains some substantial bugs in cut point check code which can result in some bad cut points missed (and very few good cut points marked as bad), fixed in the nightly.

However, it can be OK and not-OK in the very same file.  When it is not OK, I cannot cut as the result is bad.

Yes, exactly so.

How is it possible that it can work and also not-work in the same file and is there anything I can do about it?

In most H.264 and HEVC streams, each frame includes a counter in its header which reflects the order in which the decoded picture should be displayed – POC (picture order count). This counter is reset only on IDR (instant decoder refresh) frames.

In a video stream with closed GOPs, each keyframe is an IDR frame and we can cut at every keyframe not caring about POC. But in H.264 and HEVC streams used for digital broadcast, the closed GOP mode is not viable because of huge variability in bitrate between frames in this mode. Therefore broadcasters use open GOP mode, where keyframes just mark a point in the stream which can be directly accessed (technically it means that parts of the picture which don't depend on other pictures to be decoded are spread over a number of frames, reducing bitrate fluctuations).

When we cut at a non-IDR keyframe, we can run into the situation that the POC of the next frame after the cut is (much) less than the POC of previous frame. Here the trouble starts.

Some if not most decoder libraries and hardware players discard such a sudden jump of POC and just carry on, so everything works fine. But the most important library at the heart of most popular players and video editors including Avidemux – libavcodec – actually evaluates the invalid POC jump at the boundary of the cut and will not continue with playback until a frame with POC higher than before the cut or an IDR frame arrives.

As we cannot command millions of people to stop using VLC, we need to avoid triggering this problem by checking the POC values at the cut points.

The only other option is to re-encode the video.