Cut OBS x264 video becomes garbled

[phaolo]

Btw, can these files be repaired in a non-destructive way? :\

Probably yes. It might be possible to inject a SEI NAL unit of the recovery type before each recovery point. I'll look into available options later.

The OBS team just released a new version and they updated their dependencies like the x264 codec.
This should resolve the problem mentioned in this thread.

All my old recordings, however, are still affected by the error.
Can you please tell me if you found a way to fix them eventually?

[eumagga0x2a]

Did have spare time for that yet, I'm sorry.

[eumagga0x2a]

Injecting SEI recovery info before keyframes turned out to be ineffective. Probably poor analysis, looks like I'm back at square one. It is also remarkable that it looks like just keeping the first keyframe is enough to make all subsequent video, even when edited, decodable. I must look deeper into this issue.

[eumagga0x2a]

It turns out to be that libavcodec needs to know the x264 version used to encode a particular stream to apply version-specific workarounds. This information is stored in a SEI message of type H264_SEI_TYPE_USER_DATA_UNREGISTERED, present in only in the access unit with the first keyframe of the original sample video. Cutting away the first GOP drops this essential piece of information and decoding fails.

This looks like a general problem, not just some rare edge case. Will try to implement a fix sooner rather than later.

[phaolo]

Oh, thank you for checking this again.

Does this mean that the glitch isn't exactly a problem in my files (so I can avoid fixing them), but more like an Avidemux error?

I guess that the program just needs to add such info to the new first keyframe, every time a video clip is cut at the start.

However, I wonder.. is this going to negatively affect other x264 files cut with Avidemux in the past? Are version-specific workarounds frequent or rare?

[eumagga0x2a]

Should be fixed for stream copy operations between AVC formats (mp4/mkv) by
[coreUtils/editor/muxerGate] Inject SEI message with x264 build info into the first access unit when in copy mode and saving not from the start of ref video, AVC type H.264 streams only for now, please try a future nightly.

It is not that easy to put blame on someone. There are very few and rarely used H.264 features which FFmpeg treats differently depending on x264 build used to generate the stream. Additionally, FFmpeg itself doesn't bother to preserve this info in stream copy mode.

I don't know whether changes in the bitstream format occured due to bugs in x264 getting fixed or due to specifications evolving. By all means, as a libavcodec user, I'm not happy that quirks depend on an easily discarded supplemental unit which is usually present only once in the whole stream.

I guess that the program just needs to add such info to the new first keyframe, every time a video clip is cut at the start.

This is exactly what my patch is doing. The thing is that it is absolutely legal to start decoding from any later keyframe if desired, skipping the first GOP. It just happens that Avidemux probes loaded H.264 videos by decoding the first 100 frames and the H.264 context created during this probing is preserved.

is this going to negatively affect other x264 files cut with Avidemux in the past?

No, why should it? If this SEI message is not present anymore, it is not present, period. Estimated in 99,99% of cases this has no ill effects.

Are version-specific workarounds frequent or rare?

They are always too frequent, as any common evil in life.

[eumagga0x2a]

Fresh nightlies have been uploaded, please try the 191003 one --> https://avidemux.org/nightly/win64/

[phaolo]

Ah, thank you. But are those beta releases? Maybe I'll wait for a stable one to be safe.

[eumagga0x2a]

No, nightlies are not beta releases, they are just snapshots of the current state of development.

Most of the time, they are both more stable and generally better than releases. They are mostly less polished in sense of translations broken or even more incomplete or such minor stuff. Exceptions confirm the rule. The only drawback is that there are no officially published checksums.

[eumagga0x2a]

Right now is such a moment when VC++ nightlies are broken due to the MSVC build environment being updated.

The 191104 build is known good.