Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd February 2010, 21:34   #1  |  Link
killmoms
Registered User
 
Join Date: Apr 2008
Location: Gaithersburg, MD
Posts: 22
Bizarre x264encoder problem

Hey all,

So I know QuickTime isn't the most beloved piece of software around these parts, but I'm trying to solve a very, very bizarre problem which involves QT and the x264encoder component for it.

Basically, I used to have a setup that worked. I could use x264encoder to create .mov files (and mux them to .mp4) that looked great and played great in QuickTime on Mac or PC, or any other software that supported H.264.

Now, any .mov or .mp4 files I make by encoding with x264encoder (a newer version) chug horribly in QuickTime—even at the same profile and level with the same (or less strenuous) settings. I cannot for the life of me figure out what is going wrong or what setting I've got checked that's causing such sub-par playback.

I compared the encodes I'm having trouble with now to ones I did using x264encoder in the past. The "old" files identify as High Profile @ Level 3.1, CABAC encoding with 5 reference frames at 6,406kbit/s in MediaInfo Mac, and they run great. Activity Monitor shows low CPU-utilization spread out amongst all 8 cores. These new ones (again according to MediaInfo Mac) are Main Profile @ Level 3.1, CABAC encoding with 2 reference frames at 3,961kbit/s. Considering every element is less intense, you'd think these would be even easier to decode—but they're not. They chug along at 17 - 21fps and Activity Monitor shows one core being pinged at 100% activity. I've tried turning off numerous options in x264encoder's settings (FLAG_LOOP_FILTER, FLAG2_WPRED, FLAG2_MIXED_REFS, FLAG2_8X8DCT, FLAG2_FASTPSKIP, and FLAG2_MBTREE among others) and nothing seems to make a difference.

Weirdest of all, I don't think it's a QuickTime playback bug because those old files still play perfectly fine now, right alongside the new files that play badly.

My source files are 10-bit Uncompressed 4:2:2 QuickTime files. I thought perhaps some internal weirdness with 10-bit data was responsible for the issues (even though I don't believe x264 can even create 10bpc H.264), so I tried creating files from 8-bit Uncompressed 4:2:2 as well.

Basically I'm at my wits' end and have no idea what I'm doing wrong. If anyone has any experience at all with a workflow like this, would you mind giving me some pointers?
killmoms is offline   Reply With Quote
Old 2nd February 2010, 21:38   #2  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,688
Paste the entire output of "strings file | grep x264" for both an old file and new file.
Dark Shikari is offline   Reply With Quote
Old 2nd February 2010, 21:49   #3  |  Link
killmoms
Registered User
 
Join Date: Apr 2008
Location: Gaithersburg, MD
Posts: 22
Seems I jumped the gun on posting—I believe I found something that's made a difference. Changing "weightp pred:" from "Smart analysis" to "Disabled" seems to have improved matters significantly. I'm still testing with other options to see what I can turn off and on and how those adjustments affect performance.

Dark Shikari: I tried running that command on a couple of my old MP4 files that I described above, but strings returned no output whatsoever. Could this be because x264encoder runs within QuickTime (and generates .mov files, which I then have to re-mux to .mp4)?

Last edited by killmoms; 2nd February 2010 at 21:52.
killmoms is offline   Reply With Quote
Old 2nd February 2010, 21:59   #4  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,688
Quote:
Originally Posted by killmoms View Post
Seems I jumped the gun on posting—I believe I found something that's made a difference. Changing "weightp pred:" from "Smart analysis" to "Disabled" seems to have improved matters significantly. I'm still testing with other options to see what I can turn off and on and how those adjustments affect performance.

Dark Shikari: I tried running that command on a couple of my old MP4 files that I described above, but strings returned no output whatsoever. Could this be because x264encoder runs within QuickTime (and generates .mov files, which I then have to re-mux to .mp4)?
Sounds like the muxer is stripping the userdata SEI then.

My guess would be that if the old x264encoder was sufficiently ancient, it would have generated multislice files by default, which Quicktime could have multithreaded on.
Dark Shikari is offline   Reply With Quote
Old 2nd February 2010, 22:02   #5  |  Link
killmoms
Registered User
 
Join Date: Apr 2008
Location: Gaithersburg, MD
Posts: 22
Define "sufficiently ancient." A backup of my previous installation (before wiping for upgrades) has an x264encoder that dates back to only October 2, 2009.

Though, to be fair, the "old" 6mbit file I was talking about dates back to late July of 2009, so that was likely generated by an even older version of x264encoder.

The muxer in question is QuickTime's MPEG-4 exporter, which has a "Pass-through" option for video and audio data that's alread AVC/AAC. God only knows what data it strips out.
killmoms is offline   Reply With Quote
Old 2nd February 2010, 22:04   #6  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,688
Quote:
Originally Posted by killmoms View Post
define "sufficiently ancient."
2006.
Dark Shikari is offline   Reply With Quote
Old 2nd February 2010, 22:08   #7  |  Link
killmoms
Registered User
 
Join Date: Apr 2008
Location: Gaithersburg, MD
Posts: 22
Quote:
Originally Posted by Dark Shikari View Post
2006.


Well, I doubt it was THAT old. I didn't even work here until 2008, and x264encoder wasn't installed when I got here.

Anyway, I'm going to chalk this one up to user error for not knowing which specific options (out of the millions possible) was responsible for my problem. And for not having any idea what "weighted p-frame prediction" is.

Thanks for the help!
killmoms is offline   Reply With Quote
Old 2nd February 2010, 22:18   #8  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,146
Anyway, latest x264 supports slices again (optionally). So you could try something like "--slices 4" and check if QT likes that better...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 3rd February 2010, 04:50   #9  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,732
I wasn't aware that the QuickTime H.264 decoder supported slice based multithreading! That's a reason to use slices, I guess!

I'm also playing with the "x264encoder" quicktime component for automated Quicktime processing via Compressor droplets. Interesting stuff... I wish the config GUI for "x264encoder" made a bit of sense... For example, there is a flag to enable CRF encoding, but there is no field to put the crf number in! Also, to get rate control to work at all, you have to put the QuickTime quality slider all the way up, otherwise you get massively undersized files. Meh....

Write me a ProRes decoder for libavcodec pls Dark_Shikari, then I can just use x264cli for everything

~MiSfit
Blue_MiSfit is offline   Reply With Quote
Old 3rd February 2010, 20:05   #10  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,146
Quote:
I wasn't aware that the QuickTime H.264 decoder supported slice based multithreading! That's a reason to use slices, I guess!
I'd say: If QuickTime doesn't support multi-threading without slices, that's yet another reason to get rid of QuickTime

As if there weren't enough reasons...
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Reply

Tags
mac os x, quicktime, x264

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.