Question / Help YUV 4:2:2 w/ PCM possible?

[Blink]

I've tried doing it with ffmpeg/libx264 custom flags and such but it doesn't work. usually comes out messed up with funky colors too, or like the flags were ignored.

It seems the Color Format options in the advanced tab is also causing trouble with the process as it wants to overwrite whatever custom flags you are setting.

i444 is the closest I've got to 422, but if I try to capture i444 with ffmpeg (not setting any flags related to color) I get a top half normal picture and a bottom half green picture. So its kind of throwing a wrench into things. I need to be able to capture PCM out as Adobe Premiere takes forever prepping the file if you import compressed audio, so captuing 4:4:4 with the standard x264 isn't really an option imho.

(reference)
Micomsoft SC512N-L/DVI
1920x1080 @ 59.94 Hz
capable of YV12 / NV12, YUY2, RGB24, RGB32

 

[NalaNosivad]

I've tried doing it with ffmpeg/libx264 custom flags and such but it doesn't work. usually comes out messed up with funky colors too, or like the flags were ignored.

It seems the Color Format options in the advanced tab is also causing trouble with the process as it wants to overwrite whatever custom flags you are setting.

i444 is the closest I've got to 422, but if I try to capture i444 with ffmpeg (not setting any flags related to color) I get a top half normal picture and a bottom half green picture. So its kind of throwing a wrench into things. I need to be able to capture PCM out as Adobe Premiere takes forever prepping the file if you import compressed audio, so captuing 4:4:4 with the standard x264 isn't really an option imho.

(reference)
Micomsoft SC512N-L/DVI
1920x1080 @ 59.94 Hz
capable of YV12 / NV12, YUY2, RGB24, RGB32

Strange... I've had 4:4:4 working just fine for me in Premiere Pro, but I've only ever done that losslessly using the standard x264 output. I just tested using the ffmpeg output, and I get exactly the same result - green lower half of the screen.

It does seem that using the ffmpeg output results in that problem, where using the standard x264 output is fine.

One workaround you could obviously do is to demux the audio streams and convert them to PCM, but that's hardly ideal.

 

[Blink]

yeah. For now I have decided to go back to amarectv and do just capture to x264vfw and PCM audio then remux the streams to separate files.. I might run another test later with OBS and the standard x264 lib and see how fast demuxing the AAC stream is vs the raw PCM (can't imagine it would make much difference).

I may have misspoke earlier as well. I swear I had some streams where it would process them very quickly in Premiere, however now that appears not to be the case. Possibly related to using lossless codecs like UT, though.

What is certain is that if I demux and have a standard PCM/wav file, premiere will zip right through it if imported by itself.

The ideal solution I suppose, would be for OBS-MP to support writing audio/video to independent output files in this case. Being able to keep the video wrapped in MP4 (premiere seems to hate raw .264 files) with a separate audio file in PCM would make importing and getting to work editing a breeze. As it stands now if I have a file that turns out to be an hour long or more it could waste almost as long trying to process it on import because of the audio track.

 

[Harold]

saving directly to mp4 can cause problems.
Tried using a codec like utvideo for the video stream and flac for audio?

 

[Blink]

Why should saving directly to an mp4 cause problems? Plenty of programs write MP4 streams on the fly when encoding for H.264/AVC.

I have issues with framedrops (for some reason) using UT, Lagarith etc. Or at least their VFW varieties. x264 and its vfw variety however is pretty consistent and doesn't miss a beat, plus its nice to be able to tweak QP values for smaller files, while still being perceptibly lossless.

FLAC would probably get transcoded to PCM by Premiere as well. The only way to get around the additional long import step is to split the video and audio and import a WAV file.

 

[Harold]

There are actually multiple problems saving directly to mp4, not least of which is the container's reliability if the encoding process is interrupted. There are also some performance issues while recording.

OBS' use of utvideo and huffy are NOT VFW.

 

[Blink]

I see now you meant via ffmpeg. Regardless my issues with file size still stand, however I'm gonna look into it just for testing purposes. Because I have another potential issue to whine about that I noticed (related to colorspaces, yay.....) so I guess I'll go play with that for a while.

as far as MP4 goes, I can't imagine its worse than shoving an AVC stream into an AVI file at least. Anything that could go wrong with an interrupted encoding sounds more like an edge-case issue imho. At least in the context of streaming or saving a file, if something happens to interrupt your encoding it is probably a crash, which means any reliability issues with MP4 as a container are probably the least of your worries.

 

[Harold]

Anything that could go wrong with an interrupted encoding sounds more like an edge-case issue imho.

That "edge case" happens far more often than normal edge cases. Program crash, system crash, power outage, cat chewing on your power cord, cat sitting on your power bar's power button and turning your computer off. ALL would cause a 6h recording session in mp4 to become a waste of 6 hours.

FLV works well on formats it supports, but I typically recommend MKV if you're using exotic formats or multi-track audio.

 

[Blink]

I could probably live with mkv, although sometimes its a pain to get it into some apps (Vegas won't take it, Premiere will, TMPGenc VM Works will, etc)

That being said. I did some experimenting with various things. No matter what color format I choose, or which encoder (x264rgb, utcodec etc) the "RGB" output produced is... not quite up to snuff. Mainly some issues around high-contrast colors like neons and stuff (ffmpeg CLI warnings, etc). It also causes issues with text quality as a result, especially in say, a command console.

YUY2 output via x264vfw from amarec looks slightly better, the biggest improvement being the text quality.

And just to be sure, I set my capture card to an RGB input mode in amarectv, and selected UT's RGBA codec (VFW), and that came out pretty much perfectly especially the text quality.


other interesting notes. UTCodec (VFW) gives me issues with dropped/duped inserts, and utcodec via OBS/ffmpeg just gives me a warning about encoding being overloaded. Meanwhile CPU is sitting around 20% and its writing to a RAID 0 that can easily do 300MB/s. It's very strange. I know from my amarecTV outputs/log that encoding can peak above 16ms and just on average sits higher than when encoding to x264VFW, which usually doesn't even hit 10ms and hovers around 3 -4 ms without breaking a sweat. Very odd behavior for an FX8320 with plenty of write-bandwidth all things considered.

If anyone has a custom command line I could try to make sure I'm getting proper RGB output from OBS / x264rgb then feel free to share it and I'll give it a try. Ditto for any setups to try i444

 

[Blink]

Strange... I've had 4:4:4 working just fine for me in Premiere Pro, but I've only ever done that losslessly using the standard x264 output. I just tested using the ffmpeg output, and I get exactly the same result - green lower half of the screen.

It does seem that using the ffmpeg output results in that problem, where using the standard x264 output is fine.

One workaround you could obviously do is to demux the audio streams and convert them to PCM, but that's hardly ideal.

Just to clarify on this further. I have found that if I select the standard encoder and i444 I do indeed get a proper picture, with very clean colors etc and no weird issues.

all the trouble seems to be stemming from trying to use the advanced ffmpeg options.