Hello, I noticed that when I cut OBS videos (directly, without re-encoding), the result becomes broken.
I just get a grey garbled image in VLC.
Example videos (Enter the Gungeon shop):
https://drive.google.com/file/d/1Ud4yCLwVOCJ0i5cR6iFgwhopzBJqkDv8/view?usp=sharing
https://drive.google.com/file/d/118Su4EAYeSW6fCxJA9L1q2eu0y7O1L0p/view?usp=sharing
I see this in VLC:
https://drive.google.com/file/d/1VF2zJsRPMDfA6YKgEUOJz8AZDTtsw-oC/view?usp=sharing
Do you know why?
P.s: and re-encoding to H265 sometimes works, but other times I get a video with freezing frames
Thank you for the sample. mpv complains
[mkv] This is a broken file! Packets with incorrect keyframe flag found. Enabling workaround.
when playing the source video.
I'll look into this later. Probably the file is really broken, but it would be interesting to investigate whether we could deal with it better.
The H.264 video stream in the sample is indeed broken in the following way: it doesn't contain proper IDR (instant decoder refresh) frames except of the very first frame but uses recovery, i.e. some non-IDR frames (P-frames) are encoded in a way which allows forward decoding to succeed when initiated at these frames. For this purpose, these frames must be announced in a preceding NAL (network abstraction layer) unit of type SEI (supplemental enhancement information) as recovery points. These SEI units are absent in the sample. Instead, non-IDR recovery frames are marked as IDR at the NAL layer, profoundly confusing decoders – at least in case of libavcodec at heart of VLC, mpv and Avidemux.
Freezing frames when re-encoded are probably the result of problems during the decoding phase, e.g. when a recovery frame is somewhat damaged and the decoder has to wait until the next recovery point passes by.
Thank you for replying.
Then this seems an OBS problem.
Tomorrow I'll write to the devs and point to this thread.
Btw, can these files be repaired in a non-destructive way? :\
Quote from: phaolo on July 12, 2019, 01:06:23 AM
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.
Thank you. I really hope it will be possible.
In the meantime, OBS devs are checking this issue too.
Changing the color to NV12 instead of I444 seems to avoid the error, even if it's not really a solution for me.
Quote from: phaolo on July 16, 2019, 10:33:02 PM
Changing the color to NV12 instead of I444 seems to avoid the error, even if it's not really a solution for me.
Could you please provide a short sample in NV12 colorspace which works?
I can't! The forum program blocks me when I add the Google Drive link :/
An Error Has Occurred!
CleanTalk: *** Forbidden. Please enable JavaScript. ***
CleanTalk is a disaster, topped only by the disaster without CleanTalk. Please provide the link per PM.
Thank you for the sample. The video stream is indeed fully okay. It is yuv420p, not nv12. What did you mean by "changing color to NV12"?
Quote from: eumagga0x2a on July 18, 2019, 01:10:47 PM
Thank you for the sample. The video stream is indeed fully okay. It is yuv420p, not nv12. What did you mean by "changing color to NV12"?
OBS has these color options:
format:
- NV12 (default)
- I420
- I444 (what I prefer)
- RGB
space:
- 601 (default)
- 709 (what I use)
range:
- partial (default)
- full (what I use)
The broken samples were obtained with I444, 709, full.
The last correct one, instead, with NV12, 601, partial.
I don't know why it's wrong.
Btw I'm just a normal user, ideally you devs should talk directly ;P
Here is the thread, in case you're interested to suggest something to OBS:
( CleanTalk stopped me again -_- )
What happens if you strip the protocol prefix from links, making them unclickable?
I understand, you refered to OBS settings, not the real properties of the output.
It doesn't work, I''l send you a PM.
Thanks, I post the link here so that everyone can follow: https://obsproject.com/forum/threads/cut-recorded-x264-video-becomes-garbled-obs-creates-files-with-errors.108348/ (https://obsproject.com/forum/threads/cut-recorded-x264-video-becomes-garbled-obs-creates-files-with-errors.108348/).
They finally replied again.
So, the culprit is the old x264 version they're using.. I hope they'll update it soon (not in years).
I'd prefer not to go back to those crappy NV12 or i420 colors as they suggested.
I'll keep using i444 and fix all the files with your method at some point in the future.
(I hope it will be also scriptable, because I made a ton of recordings)
Quote from: eumagga0x2a on July 12, 2019, 05:26:22 PM
Quote from: phaolo on July 12, 2019, 01:06:23 AM
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?
Did have spare time for that yet, I'm sorry.
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.
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.
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?
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 (https://github.com/mean00/avidemux2/commit/db235b6925b98255afeb913c3bda53fb982c1ec4), 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.
Quote from: phaolo on October 02, 2019, 03:54:24 AM
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.
Quoteis 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.
QuoteAre version-specific workarounds frequent or rare?
They are always too frequent, as any common evil in life.
Fresh nightlies have been uploaded, please try the 191003 one --> https://avidemux.org/nightly/win64/
Ah, thank you. But are those beta releases? Maybe I'll wait for a stable one to be safe.
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.
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.