x264 Settings... Help Needed

[mirkosp]

QT has a lot of playback issues and unsupported basic features, which is why it fails playing that encode. You'd have to limit the settings, if you wish to support it. Imho it's just not worth it: it's better to get people to use better players, on OSX there are mplayer osx extended and mplayer2, there's not even the need to use vlc, nevermind qt.

Re: segmentation fault... perhaps see if lowering the rc-lookahead helps? Just a random guess, though. :\

Code: Select all

./x264 --preset veryslow --tune animation --rc-lookahead 40 --deblock -1:-2 --aq-strength 0.8 --psy-rd 0.7:0.2 --output "test.mkv" "TEST UNCOMPRESSED.mov"

[TheRyuu]

it's better to get people to use better operating systems

ftfy

As far as the segmentation faults are concerned, maybe the binaries just don't like you. You could try compiling them yourself if all else fails.

[Qyot27]

The segfault is probably due to colorspace and bit depth issues, because I'm fairly sure I duplicated it on Windows (it doesn't report a Segmentation fault, it just makes x264 crash after reporting the exact same things).

You need to use the --vf option to convert to a colorspace/bit depth x264 understands. So see if one of these fixes it:

--vf resize:csp=yv12:8
--vf resize:csp=i444:8 --output-csp i444



Alternatively, re-render from the NLE and make sure it outputs in a colorspace/bit depth that won't get choked on.

[Kira_Douji]

Mirk - Yeah, I do have other players, it's just that they can't integrate as well as QT. Really wish I could tell QuickLook to run through something else (movist/mplayer etc...) This would probably solve the majority of my irritation.

Ryuu - I'm sorry, I fail to see the point of your post?

Qyot27 - Helpful as always, I'll try that. It was previously in:

Code: Select all

Color space                      : YUV
Chroma subsampling               : 4:2:2
Bit depth                        : 10 bits
Compression mode                 : Lossless

So I figured it'd be okay - I forgot about the YV12. Whoops. I'll see if changing it helps.

[Kira_Douji]

Update:

The colorspace tag resolved everything It's got me looking for a YV12 codec for the system...

As for the rest - CLI and MPEGStreamClip methods are both working, I have a better understanding of what had caused me some confusion before (mainly QuickTime, of course >>) and I appreciate all the help you've all given.

Now, I'm just curious if any of their QuickTime upgrades in Lion fix any of this mess.

[Qyot27]

Qyot27 - Helpful as always, I'll try that. It was previously in:

Code: Select all

Color space                      : YUV
Chroma subsampling               : 4:2:2
Bit depth                        : 10 bits
Compression mode                 : Lossless

So I figured it'd be okay - I forgot about the YV12. Whoops. I'll see if changing it helps.

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.

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.

[Kira_Douji]

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.

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.

Hm... I wonder if just exporting in 8bit with everything else otherwise the same would work? I'll have to test it.

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).

!!! That makes so much more sense now I guess I'm still used to DOS where if it could see it, it'd run. -_- I'm still getting the hang of navigating via Terminal on OS X - I frankly haven't really needed to know it like I did with DOS back in the day. This gives me a bit of an incentive, though, ty

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.

I might dig into this a bit - it's not terribly difficult to poke around, but I do know the default preset for MPEGStreamClip in x264 is "Medium" and if I left it at default values, it never had a problem - only when I tweaked. I'll have to run some encodes to track it down, though I think I remember seeing something about QT not liking certain qpmin values... Aya I swamped myself with forum digging to figure this out so I don't remember where.

I do have Perian, though - it's one of the first things I install, which was part of the reason I didn't originally think QuickTime itself was the culprit for the artifacts. Not sure what you mean about issues with FC, though? It really hasn't given me any problems with that... At least, that I know of.

[gotenks794]

MPlayerX from the Mac App store is much better than Quicktime. Just about every video I throw at it works.

[Mister Hatt]

MPlayer2 craps on MPlayerX, but if you care about GUI you should be using Perian in the first place. Also Apple fucked up again? Colour me unsurprised.

[Kira_Douji]

I have players that work, thanks - I was just hoping to get the integrated one working... Maybe someday you'll actually be able to set a default player other than Quicktime.

One can hope, I guess.