Generating web/mobile H264 from a CRF High Profile H264

[cali_axela]

Short background: we're attempting to streamline the delivery process of source files for a weekly web show. All source editing/exporting is done on macs in Final Cut via Compressor.

Currently, we encode from their HDV source to various H264 deliverables, which works fine... but transferring the longer source files (5 GB+) from remote editors to our servers for processing just takes too long.

I'm experimenting with having them export a really nice looking "compressed master" via the Compressor x264 plugin using CRF 17 etc, which looks damn near as good as the HDV masters with a much smaller deliverable (and is still in an MOV container).

The problem is, the smaller encoded mp4 files we generate based on the Compressor x264 have horrid playback issues; looking at the files that get output in MPEG Parser is a mess.

Are there any known issues with re-encoding from a High Profile H264 generated with x264 on a mac, to a couple smaller main and baseline versions using x264 on the command line? Anything in the settings I could tweak for better compatibility?

Let me know if you need any more details or examples, too, in order to help. I don't pretend to be a pro but I thought I had this down and the problems we're seeing are baffling.

[Blue_MiSfit]

No, this shouldn't be an issue.

I've used the x264 QuickTime component to transcode various QuickTime only codecs (like ProRes and its ilk) into H.264 in MOV for transport, then transcoded the result down to a lower bitrate using x264 cli.

What kind of playback issues are you seeing? Some samples would be helpful.

Derek

[cali_axela]

Seems like my keyframe period (30 for a 30fps video, or one per second) was just too high for my VBV and ABR settings, all the bandwidth was being eaten up by the i-frames. Cranked that GOP size up to 90 frames and it's much better now.

Still messing with optimal VBV bufsize/maxrate for mobile streaming, replied to an existing thread about VBV already asking for advice on that (and downloaded the VBV checking tool the thread is mainly about to help with tuning those settings as well).

Nice community here so far, hoping to learn more and maybe someday contribute helpful info too!

[Blue_MiSfit]

Yes, one second keyframe intervals is utter madness at anything but high bitrates (i.e. bluray). I Frames eat bits like crazy!

I saw your other thread. As I suggested, start with a 1-2 second VBV buffer size. The only reason to use a --keyint-max lower than the default (250 frames) is if you're really concerned with being able to seek quickly to any point in your video. If you're doing streaming, by all means leave it at the default.

Let us know if you have more questions. I hope you're using x264's --preset and --tune parameters. Also, 2 pass or CRF is usually preferred over 1 pass ABR or CBR. That being said, x264's CBR is pretty good these days!

Welcome to doom9!

Derek

[cali_axela]

I am doing two pass ABR for the smaller baseline streaming files, our HD file is a one pass CRF (that one is great, probably leaving keyframe at 90 on it). I'll do some more tests with an even higher keyint on the lower bitrate files -- we do see users skipping around a lot in our videos so I want it a little lower than the default, maybe I'll go up to 180 on these tests and see how much better that is than 90. Thanks for the tips!

[benwaggoner]

Yes, one second keyframe intervals is utter madness at anything but high bitrates (i.e. bluray). I Frames eat bits like crazy!
Well, if scrubbing, trimming, and editing is going to be applied to the mezzanine files, shorter Closed GOPs can be a whole lot easier to work with. It's a tradeoff between compression efficiency and workflow efficiency. If shorter GOPs are appropriate, than a larger VBV should be used.

Let us know if you have more questions. I hope you're using x264's --preset and --tune parameters. Also, 2 pass or CRF is usually preferred over 1 pass ABR or CBR. That being said, x264's CBR is pretty good these days!

I think CRF is definitely the optimum mode for this use, and will reduce keyframe quality issues a bunch with a reasonable VBV level. I've used CRF for my mezzanine files in the past, and the "as many bits as needed to look awesome, but no more" model is great.

[cali_axela]

Thanks, that's reassuring. My initial CRF tests with the lower bitrate baseline files were not good, but I think I have better info now to make them work right. What's a good CRF level to start off at, if trying to approximate the bandwidth requirements of ~1mbps ABR streaming file? And I think I'll try upping the bufsize to 3000k at the same time.

This is another issue I've heard conflicting ideas about -- if upping the bufsize to 3000k, should i also up the maxrate to 3000k or try leaving it at 1500k? Which one is more likely to cause underflows?

[benwaggoner]

Thanks, that's reassuring. My initial CRF tests with the lower bitrate baseline files were not good, but I think I have better info now to make them work right. What's a good CRF level to start off at, if trying to approximate the bandwidth requirements of ~1mbps ABR streaming file? And I think I'll try upping the bufsize to 3000k at the same time.
If you're just making a mezzanine file, perhaps CRF=16 to start? I've gone down to 12 in some cases, which is theoretically crazy, but was useful for grain retention (as was the appropriate --tune).

Is there any reason you need to set a busize? Why not just leave those blank, since you're not trying to make a file for delivering to end users. If you are trying to keep GPU decode compatibilty, maybe limit to Level 4.0 and use 25000 Kbps for maxrate and bufsize?

3000k is pathologically low for HD content, and very low for SD archiving.

This is another issue I've heard conflicting ideas about -- if upping the bufsize to 3000k, should i also up the maxrate to 3000k or try leaving it at 1500k? Which one is more likely to cause underflows?
Maxrate is in Kbits/second and bufsize is in Kbits, so they're somewhat orthogonal parameters; together they determine how long the buffer can be.

[cali_axela]

Ah, there's the rub. This is not for a mezzanine file, that's already set in stone basically (we use a CRF 17 without any VBV settings). I'm currently trying to manually generate a smaller mp4 from the mezzanine manually (this is a test of something in addition to an existing adaptive streaming setup that works fine). Does that make more sense?

[cali_axela]

That said (just curious, not related to my initial questions) -- if I were to put VBV on the CRF 17 file for allowing it to stream, what would be a reasonable buffer size? 8000k? (this is in kilobits still similar to how maxrate is in kbps, correct? So that's just under 1mb?)

[Blue_MiSfit]

I'm not an expert when it comes to this kind of thing. Listen to someone like benwaggoner over me, for sure ;)

Here's how I think about buffers for streaming:

1) Assume an average connection speed for your users. Let's say 8mbps. Then let's set --vbv-maxrate to 8000.

2) Assuming that the "average" connection can really stream 8mbps, bufsize / 8000 = number of seconds of buffer time. In other words, after clicking "play", this is how long you wait until the stream starts. You can fudge this by tweaking --vbv-init as well. So, to be honest, considering the default --vbv-init of .9 (90%), this changes the numbers a bit!

So, really you have to just consider how many seconds you're willing to wait for your customers to buffer a given stream.

Things get more complex with adaptive streaming as well.

By the way, x264's VBV is supposedly quite stable, even with extremely obnoxious input like /dev/random. In other words, it should basically never under/overflow.

Derek

[benwaggoner]

Ah, there's the rub. This is not for a mezzanine file, that's already set in stone basically (we use a CRF 17 without any VBV settings). I'm currently trying to manually generate a smaller mp4 from the mezzanine manually (this is a test of something in addition to an existing adaptive streaming setup that works fine). Does that make more sense?
Well, that's an entirely different question then.

What are the parameters? What protocol are you delivering with? Does it need to be fast startup real-time playback, or is progressive download okay? What devices, bitrate, frame size, quality targets do you have? What is the order of priority of those?

VBV should max delay * peak/CBR bitrate as Blue-MiSfit describes perfectly. You also want to make sure it is a legal setting for the profile@level you are targeting. But VBV is definitely NOT the starting point for your settings :).

[cali_axela]

Well, that's an entirely different question then.

What are the parameters? What protocol are you delivering with? Does it need to be fast startup real-time playback, or is progressive download okay? What devices, bitrate, frame size, quality targets do you have? What is the order of priority of those?

VBV should max delay * peak/CBR bitrate as Blue-MiSfit describes perfectly. You also want to make sure it is a legal setting for the profile@level you are targeting. But VBV is definitely NOT the starting point for your settings :).

These 3 files are for downloading (available as downloads in RSS feeds for users to do what they wish with), as well as within apps on devices not using the adaptive streaming server (we generate a small SMIL file containing these 3 videos and an mp3).

One thing I've been unsure about is the relation between h264 levels and profiles vs. x264 options. Is it better to target a specific profile and level explicitly in the x264 params, or hit the correct settings for a target profile and level without setting it explicitly? I undertand profiles, but not sure exactly what is supported at specific levels or how to calculate. Currently, we're producing 3 extra mp4 outputs from the mezzanine file:

1) Small -- 320x180 @ 29.97fps baseline 1.3 (for PSP and other small/old devices; this is used both as a progressive download link in RSS feeds for people to save the file themselves, as well as being the "low" streaming option within a custom android app). 600kbps two-pass ABR video; 96k AAC-LC audio; Keyframe period: 90; Ref frames: 1
2) Large -- 640x360 @ 29.97fps baseline 3.0 (for "low quality" web streaming via flash player progressive download, also as a medium quality RSS feed). 900kbps two-pass ABR video; 120k AAC-LC audio; Keyframe period: 90; Ref frames: 2
3) HD -- 1280x720 @ 29.97fps main 3.1 (for HD quality web streaming via flash player progressive download, also as a HD quality RSS feed for downloading). 2000kbps two-pass ABR video; 160k AAC-LC audio; Keyframe period: 90; Ref frames: 4

[CruNcher]

These 3 files are for downloading (available as downloads in RSS feeds for users to do what they wish with), as well as within apps on devices not using the adaptive streaming server (we generate a small SMIL file containing these 3 videos and an mp3).

One thing I've been unsure about is the relation between h264 levels and profiles vs. x264 options. Is it better to target a specific profile and level explicitly in the x264 params, or hit the correct settings for a target profile and level without setting it explicitly? I undertand profiles, but not sure exactly what is supported at specific levels or how to calculate. Currently, we're producing 3 extra mp4 outputs from the mezzanine file:

1) 320x180 @ 29.97fps baseline 1.3 (for PSP and other small/old devices; this is used both as a progressive download link in RSS feeds for people to save the file themselves, as well as being the "low" streaming option within a custom android app). 600kbps two-pass ABR video; 96k AAC-LC audio; Keyframe period: 90; Ref frames: 1
2) 640x360 @ 29.97fps baseline 3.0 (for "low quality" web streaming via flash player progressive download, also as a medium quality RSS feed). 900kbps two-pass ABR video; 120k AAC-LC audio; Keyframe period: 90; Ref frames: 2
3) 1280x720 @ 29.97fps main 3.1 (for HD quality web streaming via flash player progressive download, also as a HD quality RSS feed for downloading). 2000kbps two-pass ABR video; 160k AAC-LC audio; Keyframe period: 90; Ref frames: 4

The PSP supports SD NTSC 720x480 Main Profile 3.1 res from the getgo it was enabled after the fail of UVD for the public via a Firmware update (so the problem is Firmware dependency).
Sure the Screen cant cope with it but newer PSPs have a TV out (and firmware is unrestricted by default) (put into tv 640x360 baseline ?, or if your customers dont know how even 320x180 ?) ;) also most Smartphones and PMPs should @ least have arrived @ the SD H.264 age and you hitting the US market only ?
But yeah its a mess where we still are when it's about resolution dependent device encoding, and it's really surprising instead of pushing SVC we come up with 3D (being the revolution) or adaptive streaming :P

[cali_axela]

Oh cool, that's good to know -- I guess PSP people who want to can use the large instead of small then, for downloading manually if they know they can support it. We do still release the small MP4 mainly for our sizeable international crowd on slower connections who want easily-downloadable videos on ISDN speeds, as well as people still using what I would personally consider "legacy" mobile devices. I edited my above post to reflect that all 3 of these are available as RSS feeds, not just the small (as my post kind of implied at first).

[sneaker_ger]

Any reason why you are restricting yourself to main and baseline profile, even for "Large" and "HD"?

[cali_axela]

"legacy" device compatibility (the files are used for RSS feeds consumed by international end users). These files are pretty much designed to be as compatible as possible while looking relatively good. Think, original iPod Video... or random linux-based devices floating around which only support baseline and/or main. In fact, the majority of mobile devices do not support High profile. The only thing I'm uncertain about is the ideal level setting for these 3 specific bitrate/framerate/framesize variants.

Mezzanine file: primary "high quality" file, high profile CRF
Adaptive streaming server: for modernish mobile devices and other streaming uses.
These 3 files: RSS feed downloads, potentially used for legacy streaming by end users.

[sneaker_ger]

Sounds overcautious - at least for HD - to me, but I guess you know you users better than I do.

[CruNcher]

sneaker_ger high was only conceptualized for the Pro usage from the beginning, Devices that support High in the Mobile area are still rare. You risk to lose a lot of potential customers if you go high only and providing high and main from a cost point of view (bandwith,encoding time) compared to what the user value is like some sharper boobs which in motion are hardly detectable @ all isn't a really efficient investment, so in terms of balancing Money/Boob sharpness no High more cost efficient in those terms would be a better lens and camera equipment ;)

[cali_axela]

^ Exactly :)

Do my settings for these 3 baseline/main encodes sound sane? What would you guys use for VBV maxrate/bufsize params? Also is there any reason to ever set the VBV minrate for this application? It does drop super low during static screens, perhaps setting the minrate to something like 100k would help eliminate some of the larger prolonged bitrate spikes?

[sneaker_ger]

sneaker_ger high was only conceptualized for the Pro usage from the beginning, Devices that support High in the Mobile area are still rare. You risk to lose a lot of potential customers if you go high only and providing high and main from a cost point of view (bandwith,encoding time) compared to what the user value is like some sharper boobs which in motion are hardly detectable @ all isn't a really efficient investment, so in terms of balancing Money/Boob sharpness no High more cost efficient in those terms would be a better lens and camera equipment ;)

I'm not talking about going high only, after all he wants to offer three different encodes per video. Also you could achieve the same quality with less bitrate with high profile compared to main profile = less costs in your words. What device offers 1280x720, but not HP? Also, less bitrate may result in higher compatibility for mobile devices, because of varying connection speeds. And of course users could always fall back to "small" or "large" (640x360!) anyways.

[cali_axela]

AppleTV, for example, only goes up to Main 3.0, and doesn't like CABAC.

[Dark Shikari]

AppleTV, for example, only goes up to Main 3.0, and doesn't like CABAC.Completely false. To start with, Apple TV is a software decoder: it doesn't have arbitrary feature limitations like that; it can do whatever it's fast enough to handle.*

It can do CABAC 720p at 24fps, for example, but not 30fps. It can do 8x8dct just fine, that is, High Profile. Talk to the Handbrake folks for more specific details.

*Because Apple is stupid, their decoder cannot handle any kind of weighted prediction: they literally just didn't implement the feature even though it's required by Main.

[cali_axela]

^ Wow, thanks -- not sure how I missed that last bit in all the guides I've been seeing. The limitations I'm seeing on AppleTV are probably because of weightp being enabled in all my Main profile tests above that level.

My 720p 30fps CABAC files never work on the AppleTV, but the 720p CAVLC ones always do... further supporting my incorrect hypothesis (and supporting your correct explanation as well). Stupid Apple indeed...

[Mr VacBob]

Completely false. To start with, Apple TV is a software decoder: it doesn't have arbitrary feature limitations like that; it can do whatever it's fast enough to handle.*

It can do CABAC 720p at 24fps, for example, but not 30fps. It can do 8x8dct just fine, that is, High Profile. Talk to the Handbrake folks for more specific details.

*Because Apple is stupid, their decoder cannot handle any kind of weighted prediction: they literally just didn't implement the feature even though it's required by Main.

You're describing AppleTV 1.0. 2.0 is an iOS device and behaves the same as other current iOS devices.

[Blue_MiSfit]

And I do believe the AppleTV 2.0 does in fact have a hardware decoder - perhaps the same one as the iPhone 4 / iPad 2?

Derek

[cali_axela]

Yes, the AppleTV gen 2 is much better at decoding than the gen1. We don't necessarily need to support the gen1 AppleTV in this HD encode, but it would be nice if we can without hurting the quality vs filesize tradeoff too much.

Getting back to the VBV question, what are sane maxrate/bufsize values for the files I mentioned? And, is setting minrate ever necessary? I currently do not. The only time I ever use minrate is for specific hardware devices that require it, I doubt these generic downloadable MP4 files would need it but it never hurts to ask :)