Ah, yeah. I've been seeing reports of yuv422p10le being misread as yuv422p16le. Looking at it again, FFmpeg does support V210, which is uncompressed 10-bit 4:2:2. x264 doesn't seem to have a problem if it's specifically in V210 as output by FFmpeg, although it still converts it to 8-bit. It just doesn't crash or misread it as being 16-bit.Kira_Douji wrote:Qyot27 - Helpful as always, I'll try that. It was previously in:So I figured it'd be okay - I forgot about the YV12. Whoops. I'll see if changing it helps.Code: Select all
Color space : YUV Chroma subsampling : 4:2:2 Bit depth : 10 bits Compression mode : Lossless
Basically,
ffmpeg -i input.mov -vcodec v210 output.avi
(or output.mov, since it doesn't seem to really matter, as long as the container supports it)
And then give the output to x264. At least the --vf option makes it work, though.
As a further note on a previous part of the thread, the ./ needed to make the programs run is solely because they aren't on the PATH, and *nixen won't run programs that aren't on their PATH without the user explicitly overriding that behavior (it's a security measure); the ./ is simply the most common method of overriding it. To avoid needing to do that, just copy x264 to /usr/bin (sudo cp x264 /usr/bin).
Do you have Perian installed? That's generally the go-to solution to resolve the issue of Quicktime not supporting H.264 properly, even though it's usually just easier to rely on one's favored variant of mplayer (especially with the reports of Perian doing odd things to Final Cut). Otherwise you have to pretty much gut your encodes. I'm not sure where QT's compatibility cut-off is with x264's presets, although I'd guess any of the 'fast' presets would be fine.