libx264rgb broken after OBS Version 28.
Operating System Info
Windows 11
Other OS
No response
OBS Studio Version
28.0.1
OBS Studio Version (Other)
No response
OBS Studio Log URL
https://obsproject.com/logs/WJYoEE6b10n-fLO0
OBS Studio Crash Log URL
No response
Expected Behavior
The same behaviour dosen't happen with OBS 27.2.4. Mediainfo: https://i.imgur.com/fqxeSCH.png mpv: https://i.imgur.com/LOG9iVd.png Log: https://obsproject.com/logs/h0GjkxmOZyZluDkX
Current Behavior
Currently in OBS 28, when trying to record with libx264rgb the footage ends up being in yuv444p Format as reported by Mediainfo and mpv media player. Mediainfo: https://i.imgur.com/W5cs2bJ.png mpv: https://i.imgur.com/u5Pyy8c.png Log: https://obsproject.com/logs/WJYoEE6b10n-fLO0
Steps to Reproduce
This guide from a Reddit post: https://www.reddit.com/r/obs/comments/c1798j/comment/erbpal6/?utm_source=share&utm_medium=web2x&context=3
Anything else we should know?
No response
works fine with UTvideo in custom ffmpeg output, so perhaps this would be better named "libx264rgb broken".
works fine with UTvideo in custom ffmpeg output, so perhaps this would be better named "libx264rgb broken".
Okay, good to know. I've changed the title as you suggested.
footage ends up being in yuv444p Format as reported by Mediainfo
Which is correct, because the only way to differentiate between rgb and YUV444P is matrix. And it is not set to identity as it should be. Just update ffmpeg to support rgb encoding with nvenc. Who cares about libx264.
https://github.com/FFmpeg/FFmpeg/commit/7555d6f74ce4845383e9297fd0989059739af4c2
As for this issue it is a known issue. Update to newer ffmpeg official https://github.com/BtbN/FFmpeg-Builds/releases
Sometimes you should remember that ffmpeg has a policy that only master is stable.
Same for 10 bit RGB, use nvenc: https://github.com/FFmpeg/FFmpeg/commit/85bc6b5abf287cbc38744b32b9e033158ab24780
@ValZapod I understand you believe that nvenc is superior for this usecase, but I dont personally think it's befitting to drop into an issue like this.
If you believe this (specific) issue is fixed upstream , please link to that instead, so that we can keep track of it, and close this once FFmpeg deps are updated. Thank you for your understanding.
This is very simple to fix. Change to
qp=0 preset=ultrafast colorspace=0
fixed. Same as in ffmpeg.
once FFmpeg deps are updated
I do not think you are using HEAD of master that is the recommended version until LTS is introduced.
It was fixed here: https://trac.ffmpeg.org/ticket/9132 (https://github.com/FFmpeg/FFmpeg/commit/2818b143929d86f6b67695b09bc7483da5cef434)
But there were 10 different issues around this after that.
And BTW, LOL, this is not best quality.
It does not look lossless. At all. Yes, I did set output to 4K.
Thank you for the link to the ticket and commit.
I'd appreciate if we could stay on topic, and exclusively talk about things pertaining to the issue.
things pertaining to the issue
But I fixed the issue. Just add colorspace=0 and you will not get the pink image, cause it is now tagged as Identity.
BTW, it crashed two times while I was testing. Here are stacktraces: crashonergb.txt crashtworgb.txt
We believe this should be resolved with the newer ffmpeg we ship. It also appears the issue is more with ffmpeg and expectation of setting correct params, which would fall in to unsupported territory with custom ffmpeg output and our stance on "best effort" for things there. Going to close this as we're reasonably sure the original issue is resolved.
I have the same problem. From the comments above it seems that it's fixed, but I still don't know how to make libx264rgb work again (it used to work a long long time ago). I am using OBS 30.0.0 (64 bit). By following this post, it works for me now. It might help someone else so I re-post it here.
A workaround mentioned in the bug report is to add Code:
colorspace=0to the Video Encoder Settings box in OBS, which will at least correctly flag the resulting h.264 video as RGB.
I recently ran into this issue as well, but only realized after recording many hours of video.
I was able to mostly recover the files by using ffmpeg to change the h264 metadata:
ffmpeg -i bad-file.mkv -map 0:v -map 0:a -bsf:v h264_metadata='matrix_coefficients=0' -c copy recovered-file.mkv
(edit: forgot to include -c copy to avoid transcoding, thanks @Kotsuha)
In my experience, the recovered video is still degraded (looks similar to chroma subsampling), but it's much better than completely mangled colors.
I recently ran into this issue as well, but only realized after recording many hours of video. I was able to mostly recover the files by using
ffmpegto change the h264 metadata:ffmpeg -i bad-file.mkv -map 0:v -map 0:a -bsf:v h264_metadata='matrix_coefficients=0' recovered-file.mkvIn my experience, the recovered video is still degraded (looks similar to chroma subsampling), but it's much better than completely mangled colors.
Thank you for sharing this. I just tried it with one of my broken files and it worked. I then tried it without re-encoding:
ffmpeg -i "bad-file.mkv" -map 0:v -map 0:a -bsf:v h264_metadata='matrix_coefficients=0' -c:v copy -c:a copy "recovered-file.mkv"
I don't know how to examine if it's lossless, but from the file size it generated, and the time it costed, it seemed to work as expected.