High Profile 5.1 -> 4.1

[wallstreetcrash]

I know a lot of x264 files are in high profile 5.1, but they would still fit under the criteria of 4.1

So is there a way of transcoding/chaing header to make it 4.1, so I can play it on my XBox360 without re-encoding.

Similar to this: http://forum.doom9.org/showthread.php?t=125668

Thanks!

[akupenguin]

And your xbox360 refuses to play it just because it says level 5.1? Lame.

[wallstreetcrash]

I haven't tried it personally, but yes :(

[Sagittaire]

h264info can make that ...

[Sharktooth]

EDIT: i just realized it was about the xbox360 player... so my comment was inappropriate.

[PuzZLeR]

As expert as the source may be, instead of all this speculation, can we get a report from someone who's physically actually tried it?

And yes, I agree. This whole nonsense about the level being a parameter that has constraints of acceptance is truly very lame, and annoying too.

[DarkZell666]

Well, I find that technically "normal".

Consider a VBR file : if the max bitrate goes over what the player can decode correctly in real-time (or read from the disk/media), it will choke, but there's no way in advance to know where the bitrate will max out without scanning the whole file. This is what the level indicator is for (among other things). It certifies what features are used. Now if someone encoded a file which is 4.1-compliant and mistakenly set "5.1" or "Unrestricted" it's another story all together.

Mind you, with "high-bitrate" profiles (4.x+ ?), the only differences are precisely the max allowable bitrates, so the event of a theorical-5.1-file being in fact 4.1-compliant is likely to happen often ;)

[akupenguin]

And what if it's 720p w/ 16 refs? that requires level 5.0 but takes only a few % more cpu than 720p w/ 1 ref, which can be level 3.1.
Or 1936x1088 at low fps?
Or high bitrate but CAVLC?
It only takes violating one constraint (out of res, res*fps, bitrate, cpb, dpb) to require a higher level. While each of those 5 values is a reasonable thing to limit, it's very unlikely that any given device would have its limits for all 5 exactly equal to the same level. If you e.g. have enough memory to handle level 5.1's cpb & dpb & res, but only enough cpu to handle level 4.1's res*fps & bitrate (which I think is the case for xbox360), then even if you assume every file has its level set to the minimum allowed value, you still have to choose between rejecting some files that would play vs accepting some files that might stutter. Even worse if your device's limits fall between levels.

IMNSHO the only sane behaviour is: try to play it, and fail only when and if it requires too many resources. But then I'm used to PC playback, where even if you knew the exact max bitrate and every other relevant parameter in advance, there's still no possible way for a program to know whether it can play a given video until it tries and measures cpu usage %.

[PuzZLeR]

I'm assuming (although assuming may make me, well, you know what...) that x264 selects level 5.1 by default to "open up the way", and create some sort of "buffer" for the higher level features, such as CABAC, 8x8, etc., HD rez, high bitrates, or whatever.

It's like choosing the biggest shopping cart at the grocer's to make sure you have enough space to carry your stuff, whether you choose 2 items, or a week's load of goods you will have enough space.

You can choose a smaller cart, but there's a chance you may not fit everything, so you stay safe with the larger cart.

Isn't that the reasoning behind the default 5.1?

But if the level indicator is only really a "flag", then it won't make sense. Since you can set it high or low, you can try to lie to the playback device. But it will just choke anyway if your video is non-compliant.

What does the level thing really do anyway?

So this is why I believe it's lame as well when a video may be compliant, but won't be accepted because the level flag > 4.1.

I have never heard of grocer refusing your business because you chose a cart that was too big for your purchases. What makes you a "non-compliant" customer is not being able to check out your groceries by carrying and paying for them, not a wrong selection in cart size.

If that was the case, I'd think that grocer was lame as well.

Just my rant...

[DarkZell666]

Then I would see trying to watch a 5.1 file with a 4.1-compliant decoder like having a cart so big it literally knocks down the shelves ;) (then the grocer would get all grumpy and throw you out, how's that for being a paying customer ? :D)

It's true that I'd like to at least try and play the file and see if it stutters only once somewhere when the bad guy get's his ass whipped by the cow-boy, or if it'll stutter also when Mary Jane says she loves Peter Parker (no action right ? :p). A warning would be welcome, rather than locking files out ... true enough :)

[PuzZLeR]

...like having a cart so big it literally knocks down the shelves ;) (then the grocer would get all grumpy and throw you out...

You may have made a point here actually. Maybe the device's decoder needs that level info up front to "open up just the right amount of optimal space" for you beforehand, otherwise it will be really ticked off if it doesn't fit, especially later when it punishes you by making your video all screwy (kind of like having the grocer throw you out because you messed up the store instead of just picking a smaller cart).

[akupenguin]

What would the device be doing with that memory if it's not using it to decode your video? Anyway, memory allocation is determined by resolution and dpb, which are signaled independently of level and with no estimation involved. There's isn't just an optimal space, there's only one space; lavc allocates memory only at startup.

[pspvideo9]

wallstreetcrash:
The Videora Xbox360 Converter (http://www.redkawa.com/blog/post.php?t=1442) can do that.

[PuzZLeR]

...memory allocation is determined by resolution and dpb, which are signaled independently of level and with no estimation involved.

Yes, I have this suspicion that level indicator is a separate entity. Then if so, in your opinion, what function does this level indicator serve after all, especially when it may be responsible for having a fully compliant clip rejected?

[foxyshadis]

Haha, you guys are amazing at stretching a metaphor.

The level indicator serves as a way for a company to categorically state that a video probably will work on its machine without flaw, that it may or may not, or that it probably won't. But rejecting it without giving the user any choice is heavy-handed, when there's no certainity in the indicator - it can be faked either way easily.

[akupenguin]

IMO the purpose of levels is so that the maker of a device can say "this device can play most videos up to level X", without having to specify lots of individual parameters if they don't want to get too detailed. Device makers that do consider it worthwhile (e.g. Blu-Ray) can still issue exact specs. Either way, it then gives encoders an idea of how much they can enable when targeting that device. Level wouldn't even have to be written in the bitstream to fulfill that purpose, it could just be a non-normative table in the standard. Writing it is just gravy, much like x264 writing it's encoding options in case anyone wants to look.

[PuzZLeR]

Grocer clerk: Hey, you can’t do that.
Me: What?
Grocer clerk: This line is for 8 items max, I can’t check you out with that load you got.
Me: There’s only 6 items in my cart, what gives?
Grocer clerk: No, the cart’s too big.
Me: You said 8 items max and I have less than 8 items max. What is it about 6<8 that you don’t understand?
Grocer clerk: Sorry, the cart’s too big.
Me: *Sigh* I can still easily fit the cart through the isle, and it doesn’t make a difference. Wanna see? I got 6 items. What’s your problem anyway?
Grocer clerk: I’m going to have to ask you to leave.
Me: Wha..
Grocer clerk: Security!
Me: You’re warped.
Security: Excuse me, but I’m going to escort you out of here.
Me: Excuse me? The sign said 8 items or less. I have 6. And here’s my money to pay for this stuff. What’s the problem with you and this whole store anyway?
Security: Your cart’s too big.
Me: Well what’s wrong with that?
Security: Well nothing actually.
Me: Then why are you throwing me out?
Security: Well, you scared the clerk into thinking that maybe you were carrying more than 8 items. Now this poor clerk is so traumatized.
Me: Oh boo-hoo. Are we done with this charade? Can I just pay for this stuff now and go?
Security: Actually no. You gave a bad first impression that can never be changed now, so I'm going to escort you out now.
Me: Huh? What are you people, morons?
Security: Yes.
Me: And lame too.
Security: Very correct.
Me: Ah, never mind. I can always find another store that accepts my business anyway.

I take the cart, kick it aside, give them the “salute” and walk off to another store. Meanwhile, I call the store's corporate offices and let them know what complete morons they are. Apparently they get this complaint all the time...

[PuzZLeR]

...and you know what? As the rep was adjusting the headset and forcing a smile, I was told to, "Have a great day!"

:mad:

[wallstreetcrash]

wallstreetcrash:
The Videora Xbox360 Converter (http://www.redkawa.com/blog/post.php?t=1442) can do that.

Cheers, I see the new version has MKV Passthrough. I'm no expert but it fools the 360/PS3 to think that the file is 4.1, great stuff.

Now the PS3/360 don't accept 5.1 sound when using h264 codec video!!!! WHY?!! 360 only accepts 2.0, and PS3 accepts 5.1 but downsamples it 2.0. What a shame, why are they limiting us like this?

[Ronin-7]

Cheers, I see the new version has MKV Passthrough. I'm no expert but it fools the 360/PS3 to think that the file is 4.1, great stuff.

Now the PS3/360 don't accept 5.1 sound when using h264 codec video!!!! WHY?!! 360 only accepts 2.0, and PS3 accepts 5.1 but downsamples it 2.0. What a shame, why are they limiting us like this?

They have to license the audio codec, simple answer is they don't want to pay it as I presume it would cost too much and game consoles are sold at a loss to begin with.

[wallstreetcrash]

Just a bump for anyone who has not seen this, this works very well to play x264 mkv files on 360, though only 2 channel audio.

[PuzZLeR]

Thanks for the update.

..this works very well to play x264 mkv files on 360...

"This" being? Are you referring to Videora Xbox360 Converter? Just making sure.

Thanks.

[kxmas]

Yes, I have this suspicion that level indicator is a separate entity. Then if so, in your opinion, what function does this level indicator serve after all, especially when it may be responsible for having a fully compliant clip rejected?

According to what I read in the spec, the value can be, and should, calculated at encoding time. It's defaulted to 5.1 by most open source tools, and I think that's a little odd.

It's easy to change the profile value using a hex editor. It's the 8th byte of a raw 264 file. 33 is hex for 51, so change 33 to 29.

Kevin

[akupenguin]

Level can be calculated at the end of encoding, but the encoder has to pick a value before returning the first frame.
x264's API does not allow it to change its decision, nor can I think of an API that would. The value will already be written to the output file, and only the muxer could know what file location(s) to change... but the muxer typically isn't h264-specific and thus wouldn't keep track of that information. So if you force the encoder to pick a level, and don't invoke all of the level-related constraints, it has to just guess. If it guesses aggressively you then risk generating a file that doesn't obey the level it signals.

If h264 had an "unrestricted" or "unspecified" level, I'd use that. But there isn't one, so I use the next best, which is the highest level.

[Trahald]

According to what I read in the spec, the value can be, and should, calculated at encoding time. It's defaulted to 5.1 by most open source tools, and I think that's a little odd. *snip*
Kevinthere are pro apps that default to a certain level. if that level is higher than your settings require, they will not downgrade after encoding. so you are still required to pick your own level or make sure the default is what u want

[kxmas]

Level can be calculated at the end of encoding, but the encoder has to pick a value before returning the first frame.
x264's API does not allow it to change its decision, nor can I think of an API that would. The value will already be written to the output file, and only the muxer could know what file location(s) to change... but the muxer typically isn't h264-specific and thus wouldn't keep track of that information. So if you force the encoder to pick a level, and don't invoke all of the level-related constraints, it has to just guess. If it guesses aggressively you then risk generating a file that doesn't obey the level it signals.

If h264 had an "unrestricted" or "unspecified" level, I'd use that. But there isn't one, so I use the next best, which is the highest level.

Couldn't x264 provide an API to return the statistics/calculated level after encoding (or return the level on what it has processed so far). That way a muxer could correct the profile level at the beginning of the file?

I looked for something in the x264 code that would do exactly that, and didn't see it. I'm not a C++ coder. It's possible I just missed it.

Kevin

[PuzZLeR]

I do understand what akupenguin says - choosing the highest level, 5.1, is the best option, and even though it's a level that is for UltraHDTV or something, way beyond what most people are using x264 for today, nevertheless, the 5.1 default should cover any options chosen.

I personally choose "level=41" in my options, and x264 allows that without complaint, assuming that it's your responsibility to make sure that the video is 4.1 compliant. I know mine is.

And hey, if you need to, you can always change it later right?

[kxmas]

I do understand what akupenguin says - choosing the highest level, 5.1, is the best option, and even though it's a level that is for UltraHDTV or something, way beyond what most people are using x264 for today, nevertheless, the 5.1 default should cover any options chosen.

I personally choose "level=41" in my options, and x264 allows that without complaint, assuming that it's your responsibility to make sure that the video is 4.1 compliant. I know mine is.

And hey, if you need to, you can always change it later right?

I understood what he said too. I don't appreciate your tone. Nor do I think you're helping.

Of course it's the responsibility of the encoder to make sure that he has the settings right. The problem is that no one takes this responsibility seriously and everything is marked 5.1.

Is it the encoder's fault? Yes.

Is there anything I can do about it? Yes. I can extract the raw video, change the profile, and repackage it.

Is that something I like doing? No.

If there is a way to help muxing programs get the setting right, don't you think it would be useful to have? I do. I fully understand that it might not be possible.

If you look at mencoder's man page, it's no wonder that the profile is always 5.1.


level_idc=<10-51>
Set the bitstream’s level as defined by annex A of the H.264 standard (default: 51 - Level 5.1). This is used for telling the decoder what capabilities it needs to support. Use this parameter only if you know what it means, and you have a need to set it.


That translates to, "don't worry about this one."

Kevin

[PuzZLeR]

Of course it's the responsibility of the encoder to make sure that he has the settings right.You’d be surprised how many will expect the app itself, such as x264, to inform them if their settings are correct or not. And that’s why there’s a default, the maximum level possible, the “safe” choice that covers you because, as you say …The problem is that no one takes this responsibility seriously and everything is marked 5.1.
And as for:I don't appreciate your tone. Nor do I think you're helping.I was trying to help by using a specific example: I choose 4.1 for my video knowing full well that it is MY responsibility for this being compliant, NOT x264’s via message or prevention. This is what every body should understand when choosing a level. I was implying that it’s YOUR risk, and don’t blame x264 if you're wrong. Sorry my message didn’t help you.

Is it the encoder's fault? Yes.Agreed. Going back to my example, if my video is non-compliant with 4.1, it is MY fault. If I wasn’t so sure, I should have just stuck with the default instead of 5.1 provided by x264.

Is there anything I can do about it? Yes. I can extract the raw video, change the profile, and repackage it.

Is that something I like doing? No.Who said it was pleasant? I was implying that it IS possible nevertheless, that if you screw up, it’s not the end of the world. Of course, an ounce of prevention prevents a pound of nuisance later.

If there is a way to help muxing programs get the setting right, don't you think it would be useful to have? I do. I fully understand that it might not be possible.Well, if any encoding doesn’t have VBV constraints no one can know in advance. I do agree that it would be a useful tool and I do agree that it may not be possible.

If you look at mencoder's man page, it's no wonder that the profile is always 5.1…. That translates to, "don't worry about this one." Same mindset there too. The “safe” choice.

[PuzZLeR]

Here's a link showing level compliance posted by Check in another thread in case it helps:

http://cccp.project357.com/utilities/h264levels_spreadsheet__by_zero1.png

Apparently there's a (new) Level 5.2. Just curious if this will be the new default in a near-future version of x264.

I know that H.264 is still very much a developing science.

[akupenguin]

According to Zero1's table, 5.2 differs from 5.1 only in max resolution, not in any of the parameters that need to be guessed.
I wonder why that table (and the one in the standard) stop at 172fps? SQCIF at level 5.1 should go up to 20480 fps, not 172.

[drmpeg]

Level 5.2 was proposed:

http://ftp3.itu.ch/av-arch/jvt-site/2003_12_Waikoloa/JVT-J032.doc

but never made it into the standard. I'll guess because 4kx4k at 15 fps just isn't very useful.

As for the 172 fps limit, I guess it has to do with the derived variable fR?

Ron

[akupenguin]

Huh. So it does arbitrarily limit framerate to 172. Oh well, that doesn't mean you can't make a standards-compliant h264 video at a higher framerate, it just means you have to leave the framerate field blank and put timestamps only in the container.