x264 enforcing --level instead of warning?

[turbojet]

Currently if you use: x264 --level 4 --ref 12 on 1280x720 you get 'x264 [warning]: DPB size (12 frames, 16588800 bytes) > level limit (9 frames, 12582912 bytes)' and a file that has an L4.0 header with 12 references and no vbv but it's not L4.0 compliant.

Instead when you use --level it would warn and also change the maximum reference and set maximum vbv allowed for the level if they don't already meet compliancy so in the case it would be changed to: x264 --level 4 --ref 9 --vbv-maxrate 25000 --vbv-bufsize 25000

This would cut down on a lot of posts about I can't get this file to play on my player even though they set L4. We would always be able to say use --level to ensure playback as well. Is there any downside to this?

Is there any other parameters that could be enforced for levels that I'm missing like FPS and mvrange?

Also on a little different note is there any purpose for using --aud outside of bluray encoding?
If not when --aud is used can it check --bframes and enforce maximum of 3?

[ajp_anton]

x264.exe isn't supposed to protect the user from his/her own stupidity. That's what front-ends are for. The warning is more than enough.

[turbojet]

x264.exe isn't supposed to protect the user from his/her own stupidity. That's what front-ends are for. The warning is more than enough.

Instead it's supposed to lie to the user when level is set but not followed?

[ajp_anton]

How is "x264 [warning]: DPB size > level limit" lying?

[turbojet]

Because it sets L4 header but it's using 12 references.

If usability is a priority which I think it is looking at recent reduction and names of switches, I would this would be right up there on the list but maybe it's forgotten.

[LoRd_MuldeR]

Because it sets L4 header but it's using 12 references.

If usability is a priority which I think it is looking at reduction of switches and names of functions, this should really be right up there on the list.

It's doing what you told it to do. Choosing inconsistent settings obviously is the user's fault :p

You should be happy that x264 gives a warning about your mistake at least.

People using the CLI encoder are supposed to know what they do. Newbies can use one of the GUI front-ends.

[turbojet]

It's doing what you told it to do. Choosing inconsistent settings is the user's fault :p

You should be happy that x264 gives a warning about your mistake at least...

True but a lot of people who don't spend hours reading forums like this will just assume if they set --level 4 in x264 it will be playable on their player advertised to support L4@High.

While I also agree frontends should also follow this few do really because they aren't aren't identifying resolution and fps while x264 already has the info.

[LoRd_MuldeR]

If people decide to use the CLI encoder they should be able to read the console output, see the warning and correct their settings.

Also x264 cannot enforce a specific Level anyway, because the resolution/framerate of the video may violate the target level and there's nothing x264 could do about that.

(Or do you expect x264 to resize and resample the video for you? ^^)

[turbojet]

If people decide to use the CLI encoder they should be able to read the console output, see the warning and correct their settings.

Also x264 cannot enforce a specific Level anyway, because the resolution/framerate of the video may violate the target level and there's nothing x264 could to about that...

x264 has the resolution and framerate so it should easily be able to do it.

Instead of asking about every frontend gui maker I think it's much easier to nip it at the bud.

It won't affect those frontend gui's but it will make it a lot easier for them to ensure playback.

[LoRd_MuldeR]

x264 has the resolution and framerate so it should easily be able to do it.

So x264 can see that the resolution/framerate doesn't comply to the desired level. Then it can display a warning. But what else should it do? :confused:

You really can't expect x264 to resize/resample the video for you. That doesn't belong to an encoder, that's Avisynth's business...

[turbojet]

I'm not asking x264 to resize anything and certainly wouldn't expect it to do so.

What I'm asking it to do is if --level is used it doesn't exceed that level and resolution, framerate play in role in this. Frontend's could make very good use of this too, so far I don't actually think any guii's limit you to use the maximum range of the level and it would be much more complicated for them to do so then it would be for x264.

[LoRd_MuldeR]

I'm not asking x264 to resize anything and certainly wouldn't expect it to do so. What I'm asking it to do is if --level is used it doesn't exceed that level and resolution, framerate play in role in this.

What you say makes no sense. If you specify "--level X" and then feed a video into x264 that already violates the level X (because resolution@framerate exceeds the level's restrictions), there's nothing x264 can do but detecting the violation. But it can't enforce the desired level, except by downscaling the video size or by downsampling the framerate. And that's something we don't want x264 to do. So if there is no practical way to enforce a specific level in x264 via "--level", the only reasonable consequence is to display a warning about level violations, so the user can correct the problem...

[Audionut]

You're asking the cli to adjust settings for you.

Use a gui if you don't understand options.

[turbojet]

What you say makes no sense. If you specify "--level X" and then feed a video into x264 that already violates the level X (because resolution@framerate exceeds the level's restrictions), there's nothing x264 can do but detecting the violation and give a warning. But it can't enforce the desired level, except by downscaling the video size or by downsampling the framerate. And that's something we don't want x264 to do...

I'm talking about typical resolutions anywhere from 352x240 to 1920x1080 but with DPB formula you really can enforce virtually anything that's asked for without any resizing or changing fps.

[turbojet]

You're asking the cli to adjust settings for you.

Use a gui if you don't understand options.

--direct temporal --tff/bff gives a warning and disables direct temporal so changing settings is nothing new.

Can you name a gui that gives you the maximum range without surpassing the level?

[kemuri-_9]

--direct temporal --tff/bff gives a warning and disables direct temporal so changing settings is nothing new.

Can you name a gui that gives you the maximum range without surpassing the level?

that's what 'Table A-1' in the h.264 spec is for; read it. there's also a rough copy with a missing column or two on wikipedia iirc which can be used as a starting point i guess.

[turbojet]

that's what 'Table A-1' in the h.264 spec is for; read it. there's also a rough copy with a missing column or two on wikipedia iirc which can be used as a starting point i guess.

This is our excuse for the billions of people who don't understand H.264 levels either except there's one difference. With --temporal --tff/bff x264 follows the standard, with --level it doesn't.

[lexor]

x264.exe isn't supposed to protect the user from his/her own stupidity. That's what front-ends are for. The warning is more than enough.

True, but it is supposed to produce a spec compliant stream. So, while correcting user's mistakes is not its job, it should not proceed with the encode if it knows the settings are contradictory.

Warning in this case is tantamount to a lie. If encoding job has succeeded, one must have a natural expectation that the result is spec compliant, if it's not then the encoder lies. User's stupidity, as it has been put, is not a valid excuse for encoder's failure.

[ajp_anton]

turbojet:
If the source video is 1920x1080 at 24fps, and you set the level to 3.1, what settings do you want x264 to change for you to make it work?

lexor:
The .exe is designed to do what the user wants it to do. It wouldn't helt anyone to make it stop doing the job at all.
If you want the level to be correct, you will see the warning and find out what's wrong. If you want it to be wrong (I've heard of players that can be tricked to play higher levels with a lower flag), then no worries as it can already do that.

[turbojet]

Here's a pretty realistic situation:

2 average joes (one on windows other on linux) that don't know much about video except for watching it, buy BD players that clearly say H.264@L4.1 on the box in the manual, online retailers, etc.
They google 'best h.264 encoder' which points them to x264
They google 'x264 best settings' and comes to a conclusion that --ref 5 is a common answer.
The one on windows googles 'windows x264 gui bluray player' and comes across <name your gui here>, loads a 1920x1080 video, sets it to 5 refs, L4.1, and BD25 output
The linux user who is far more comfortable in cli then in gui googles 'linux x264 cli bluray player', reads up on x264 and how to use it, eventually enters x264 --level 4.1 --ref 5 on a 1920x1080 stream
Encode starts after they've spent about 3 hours researching how to do this, they go to bed
When they wake up in the morning they go to burn the recently completed BD25
Test it to find out that it doesn't play, spend 3 more hours googling as to why it doesn't play and get very contradictory answers
They come across Doom9, open an account, and wait a few days
They make the 130th post (not accurate but it's not an exaggerated number) about why their BD player doesn't play this file they encoded
People here say to read this levels table and they get very confused
They come back saying they can't understand what High, Main, Low, max bitrate, etc. are
People ask them to download mediainfo and paste what it outputs
They paste what they get the next day and are told 1920x1080 needs 4 or less reference frames
They say oh but many guides were saying that 5 reference is a good number
They change their encoders to use 4 reference frames and go to bed
Wake up the next morning, burn it to watch that night
Watch it that night only to discover that some of the high action scenes play really jerky and eventually get annoyed and shut it off
Come back the next day to Doom9 and be the 50th post to ask why their encode plays jerky
They are asked to paste mediainfo line
They do and someone discovers they aren't using VBV and they are asked to use vbv-maxrate 50000 vbv-buffer 50000
So they go and encode again, go to sleep, burn BD25 next morning to watch
Watch it and success they finally have a good backup

So 10 days has past, they spent about 24 hours researching and all, did everything the Doom9 community asked them. Would anyone in their right mind call them stupid?

You also have to ask yourself how this all could have been avoided.
Warning? the windows gui never gave any warning, linux user saw it but didn't understand it and paid no attention since it's only a warning
Better gui? one doesn't exist but if it did it wouldn't have helped out the linux user
--level 4.1 complying to L4.1? Both problems solved

[turbojet]

turbojet:
If the source video is 1920x1080 at 24fps, and you set the level to 3.1, what settings do you want x264 to change for you to make it work?

1920x1080 not allowed at L3.1 use a different resolution or choose a different level and not continue.

I've never seen anything advertised as 1920x1080 @L3.1 and if there ever is it's obviously wrong info.

Level is referred to in the hardware world and commercial software as a compatibility term. I would think it should refer to the same thing in x264 unless I'm missing something.

What I meant by drawbacks is --level actually used for anything other than compatibility?

[Trahald]

Currently if you use: x264 --level 4 --ref 12 on 1280x720 you get 'x264 [warning]: DPB size (12 frames, 16588800 bytes) > level limit (9 frames, 12582912 bytes)' and a file that has an L4.0 header with 12 references and no vbv but it's not L4.0 compliant.

Instead when you use --level it would warn and also change the maximum reference and set maximum vbv allowed for the level if they don't already meet compliancy so in the case it would be changed to: x264 --level 4 --ref 9 --vbv-maxrate 25000 --vbv-bufsize 25000

This would cut down on a lot of posts about I can't get this file to play on my player even though they set L4. We would always be able to say use --level to ensure playback as well. Is there any downside to this?

Is there any other parameters that could be enforced for levels that I'm missing like FPS and mvrange?

Also on a little different note is there any purpose for using --aud outside of bluray encoding?
If not when --aud is used can it check --bframes and enforce maximum of 3?

Well.. x264 could also raise the level to match the settings. (the user may have input level 4 simply because hes seen the setting often in peoples command lines, not for compliance sake... and may prefer the possible compression benefit of 12 ref. ) Or the encode could abort. what would be the right thing to do.

The warning ensures its known there is a mismatch of settings and allows the user a chance to fix it. and allows a stream that in most cases will play fine to finish encoding.

[turbojet]

Well.. x264 could also raise the level to match the settings. (the user may have input level 4 simply because hes seen the setting often in peoples command lines, not for compliance sake... and may prefer the possible compression benefit of 12 ref. ) Or the encode could abort. what would be the right thing to do.

The warning ensures its known there is a mismatch of settings and allows the user a chance to fix it. and allows a stream that in most cases will play fine to finish encoding.

They are obviously using --level for compliancy and x264 should think the same way shouldn't it?

The warning is seen by few and understood by fewer.

[Trahald]

True, but it is supposed to produce a spec compliant stream. So, while correcting user's mistakes is not its job, it should not proceed with the encode if it knows the settings are contradictory.

Warning in this case is tantamount to a lie. If encoding job has succeeded, one must have a natural expectation that the result is spec compliant, if it's not then the encoder lies. User's stupidity, as it has been put, is not a valid excuse for encoder's failure.

Are you saying that it should say 'Error' instead?.. if i put diesel in my car, its the gas stations fault for only warning me not to but letting me do it anyway?

[ajp_anton]

Would anyone in their right mind call them stupid?

You also have to ask yourself how this all could have been avoided.
Warning? the windows gui never gave any warning, linux user saw it but didn't understand it and paid no attention since it's only a warning
Better gui? one doesn't exist but if it did it wouldn't have helped out the linux user
--level 4.1 complying to L4.1? Both problems solvedIf the GUI doesn't give a warning, it's not x264's fault. x264 can't do anything about GUIs that don't forward messages to the user.
And yes, I would call someone stupid if he ignores a warning because he doesn't understand it. It's clearly something about levels, and the user obviously already knows that the player has a level limit. He then googles the warning and finds out what's wrong.
Well.. x264 could also raise the level to match the settings. (the user may have input level 4 simply because hes seen the setting often in peoples command lines, not for compliance sake... and may prefer the possible compression benefit of 12 ref. ) Or the encode could abort. what would be the right thing to do.The user who ignored/didn't see the warning won't see the info about the raised level either, so this won't help. The video still won't play in their level restricted player.

However - if you do not set VBV, it should give you a warning after the encode is done if the limit was exceeded.

[turbojet]

If the GUI doesn't give a warning, it's not x264's fault. x264 can't do anything about GUIs that don't forward messages to the user.
And yes, I would call someone stupid if he ignores a warning because he doesn't understand it. It's clearly something about levels, and the user obviously already knows that the player has a level limit. He then googles the warning and finds out what's wrong.

Have you ever compiled in linux?
There's 100's of warnings that can usually be ignored.

The change I suggested for x264.exe fixes this problem with gui's that don't give warnings.

Even if both saw the warning how many posts in this forum are there about warnings? How many about this file won't play on this player? Not looking for an answer just think about it.

Also I don't know of any computer user that hasn't ignored a problem so I guess we are all stupid?

If you are on windows and look in event viewer I bet there's a warning you ignored. Same thing for dmesg on linux.

The user who ignored/didn't see the warning won't see the info about the raised level either, so this won't help. The video still won't play in their level restricted player.

Raised level? If you set --level 4.1 the header will be L4.1 no matter what--ref --vbv, framerate, resolution is.
It would play if the level did what I suggested and I bet no one could tell a difference of a 2 hour 1920x1080 movie encoded to BD25 with --ref 5 no-vbv vs. --ref 4 --vbv 50000.

However - if you do not set VBV, it should give you a warning after the encode is done if the limit was exceeded.

It doesn't.

[shon3i]

Dejavu :)

x264 devs are already say that not interest for compatibility and encoder will always been unrestricted. even now, when the BD primary medium for H264.

[ajp_anton]

Have you ever compiled in linux?
There's 100's of warnings that can usually be ignored.

The change I suggested for x264.exe fixes this problem with gui's that don't give warnings.

Even if both saw the warning how many posts in this forum are there about warnings? How many about this file won't play on this player? Not looking for an answer just think about it.

Also I don't know of any computer user that hasn't ignored a problem so I guess we are all stupid?

If you are on windows and look in event viewer I bet there's a warning you ignored. Same thing for dmesg on linux.
Sorry, I should've said "ignores a warning that says something they don't understand about something they care about". They obviously care about making the video work, and they obviously know about the level limit. Therefore they should care about a warning about levels.

Don't know how to fix GUIs that don't do their job, but I want an encoder to do what I want it to do, even if it's stupid.

Raised level? If you set --level 4.1 the header will be L4.1 no matter what--ref --vbv, framerate, resolution is.
It would play if the level did what I suggested and I bet no one could tell a difference of a 2 hour 1920x1080 movie encoded to BD25 with --ref 5 no-vbv vs. --ref 4 --vbv 50000. Read what I'm quoting.

It doesn't.Yes, hence "should" instead of "does".

[turbojet]

x264 devs also claimed at one point --trellis 1 should not be used for I believe it was psy-rd because it was 'worse' then 0 or 2. They actually went to the point of setting --trellis 0 if --psy-rd > 0.0 and --trellis 1 co-existed. Few weeks later they enabled it and recommended it.

If it's true x264 devs have no interest in compatibility then they should get rid of the level, unless there's something I don't know about that should be in there.
As it stands right now it's a misleading setting.

[turbojet]

Sorry, I should've said "ignores a warning that says something they don't understand about something they care about". They obviously care about making the video work, and they obviously know about the level limit. Therefore they should care about a warning about levels.

So people are supposed to compile things and not care about what they compile?
I really don't get your argument about you calling people who ignore a warning stupid.

Don't know how to fix GUIs that don't do their job, but I want an encoder to do what I want it to do, even if it's stupid.

So you use --level along with non-compliant settings?
If so for what purpose?
If not why do you care what --level does?

Read what I'm quoting.

Sorry misread.
But again it's why use --level if you don't care about compatibility?
Why not use --level if you care about compatibility?
Why shouldn't --level ensure compatibility?
Raising level is exactly what x264 does when --level isn't used, if they care enough about that I can't see why they shouldn't care about what --level does.

[kemuri-_9]

since you seem so determined on this when the devs (according to shon3i) have stated non-interest,
make your own patch to force level compliance and use that when you encode.

[turbojet]

I've never seen this topic discussed before.
I read months ago x264 dev's not caring about compatibility but I haven't seen it lately and some of the changes they've done recently would make someone beg to differ like caring about DPB and --b-pyramid not affecting --ref

I'm pretty much clueless when it comes to writing a patch plus I would have no use for that patch but there are many on this forum or future members that would. I've helped probably 5 or so in the past week that my suggestion would fix.

[ajp_anton]

So people are supposed to compile things and not care about what they compile?
I really don't get your argument about you calling people who ignore a warning stupid.
If they ignore compilation warnings, I hope they know why they can do that. Since they are new to x264, and they care about it, they should find out what the warning is about before they decide whether to ignore it or not. Especially as they know the player has a level limit and the warning message says something about levels.

If the warning message is changed into "this is a joke version of x264.exe, it will not output a real video", would you ignore it simply because you compile a lot and ignore the warnings there?

So you use --level along with non-compliant settings?
If so for what purpose?
If not why do you care what --level does?
I don't use --level because x264 does it automatically. But again, if I want to do something stupid, it should not prevent me from doing it but instead tell me it's stupid, maybe even why it's stupid (which x264 does), and let me decide what to do.

And maybe you missed the part where I said "I've heard of players that can be tricked to play higher levels with a lower flag".

[turbojet]

If they ignore compilation warnings, I hope they know why they can do that. Since they are new to x264, and they care about it, they should find out what the warning is about before they decide whether to ignore it or not. Especially as they know the player has a level limit and the warning message says something about levels.

If the warning message is changed into "this is a joke version of x264.exe, it will not output a real video", would you ignore it simply because you compile a lot and ignore the warnings there?

linux compile errors are pretty non-critical something like could not enter directory of something that isn't depended on. If something will come with undesired results it usually errors and asks what you want to do. x264 --level warnings will give undesired results to most (all?) people who use and it doesn't ask what you want it to do.

I don't use --level because x264 does it automatically. But again, if I want to do something stupid, it should not prevent me from doing it but instead tell me it's stupid, maybe even why it's stupid (which x264 does), and let me decide what to do.

So if you are using --crf 5 expecting a normal sized output it won't warn you, if you use --crf 50 and expect a good quality output it doesn't warn you. Both I think are stupid thinking and I don't think needs a warning but it's like using --level with non-compliant settings and letting it encode as normal.

And maybe you missed the part where I said "I've heard of players that can be tricked to play higher levels with a lower flag".

Now this is what I'm looking for when I asked about drawbacks in the original post. I've never read anything like this, would you care to explain?

[shon3i]

Maybe something like this?

http://www.hdimage.org/images/nhb4dfqbq4cc0zmj89j8_hc_thumb.jpg (http://www.hdimage.org/viewer.php?file=nhb4dfqbq4cc0zmj89j8_hc.jpg)

Anyway, MPEG2 without DVD/BD compatibility is usless, and nowdays H264 start same, when BD players started to be cheap. I think that H264 should be more Blu-Ray frendly, i am not saying that need to be restricted, just point user what should be happen if use some option.

[lexor]

lexor:
The .exe is designed to do what the user wants it to do.

I don't know what some arbitrary .exe is designed to do, but x264.exe is designed to produce a compliant h264 stream. Or at least I'm under the impression (perhaps erroneous, devs?) that it is.

[lexor]

Are you saying that it should say 'Error' instead?.. if i put diesel in my car, its the gas stations fault for only warning me not to but letting me do it anyway?

False analogy, gas station cannot control/stop you. x264 can. It must not execute if it knows user is an idiot and settings are irreconcilable.

/edit: sorry for the double post, I have terrible short term memory, I forgot I already replied a moment ago, to this thread.

[LoRd_MuldeR]

It must not execute if it knows user is an idiot and settings are irreconcilable.

The resulting stream will be a valid H.264 stream anyway. It just violates the level specified (and probably desired) by the user.

Hence any software player will accept the stream flawlessly, only hardware player might fail. A warning is sufficient to indicate this fact.

If people are seeking for hardware compatibility they must choose their settings more carefully or use a GUI with a suitable preset...

[ajp_anton]

x264 --level warnings will give undesired results to most (all?) people who use and it doesn't ask what you want it to do. I'd say it's the user's responsibility to read warnings in an application they are new to. Otherwise they fall into the "stupid" category that x264 doesn't and never will protect.

So if you are using --crf 5 expecting a normal sized output it won't warn you, if you use --crf 50 and expect a good quality output it doesn't warn you. Both I think are stupid thinking and I don't think needs a warning but it's like using --level with non-compliant settings and letting it encode as normal.x264 doesn't know what you expect. It can however assume that you expect the level flag to be correct, which is why it warns you.

Now this is what I'm looking for when I asked about drawbacks in the original post. I've never read anything like this, would you care to explain?I'm sorry but I can't remember where I read this, or even if it was just a dream, but things like that do happen.

I don't know what some arbitrary .exe is designed to do, but x264.exe is designed to produce a compliant h264 stream. Or at least I'm under the impression (perhaps erroneous, devs?) that it is.By "the .exe" I meant x264.exe.
AFAIK, the level flag is not part of the actual video stream.

False analogy, gas station cannot control/stop you. x264 can. It must not execute if it knows user is an idiot and settings are irreconcilableAgain, x264 doesn't and won't protect from stupidity.

[turbojet]

The resulting stream will be a valid H.264 stream anyway. It just violates the level specified (and probably desired) by the user.

While still H.264 compliant it's about as compliant as removing the header and x264 devs sure got furious about that hack. But at least it wasn't lying like --level can.

Hence any software player will accept the stream flawlessly, only hardware player might fail. A warning is sufficient to indicate this fact.

Software players are irrelevant as it doesn't care about level at all unless you are using dxva and in that case --level 4 --ref 16 won't play right anyways. Outside of dxva and hardware do level's play any role at all? If not why shouldn't levels refer strictly to compatibility in x264 like they do in all hardware and other h.264 encoders?

If people are seeking for hardware compatibility they must choose their settings more carefully or use a GUI with a suitable preset...

Gui's don't exist, very complicated to implement, etc. Setting suggestions are very contradictory on the web.

this thread. (http://i41.tinypic.com/2j1wmdj.png)

Care to specify?

[lexor]

Again, x264 doesn't and won't protect from stupidity.
Wow, I didn't know it was you, aku. I withdraw my argument.

[Shinigami-Sama]

Care to specify?

seeing as you're new to the internet I'll explain

that is the awesome face, in this case its used to express feeling of amusement at a silly troll


the tl;dr of this thread
--level is used to set the level flag, and warn if its violated, not to force a level
x264.exe on its own won't violate the level unless you tell it to violate it.

if dark or penvado wanted it to act another one way they would've changed it. And no amount of trolling will make them change their minds; in fact its likely to make them do exactly nothing :)

[thewebchat]

I for one specify --level 5.1 on all my encodes to prevent people from using DXVA and I would very much be upset if x264 suddenly started wasting my time enforcing 16 references because "it knows what I want".

[Trahald]

...and I would very much be upset if x264 suddenly started wasting my time enforcing 16 references because "it knows what I want".exactly

anyways..
since x264 is open source. the whole point is if you dont like something you can change it yourself (even if its just for yourself.) feel free to make your own level compliance patch (its a relatively simple part of the code) you just need the avc specs which are free and mingw. and then compile your own binary.
/me speaks from personal experience.

[akupenguin]

It must not execute if it knows user is an idiot
Are you seriously suggesting a "x264 [error]: pebkac" ?

[Shinigami-Sama]

Are you seriously suggesting a "x264 [error]: pebkac" ?

then how would MSU do their tests?

[roozhou]

exactly

anyways..
since x264 is open source. the whole point is if you dont like something you can change it yourself (even if its just for yourself.) feel free to make your own level compliance patch (its a relatively simple part of the code) you just need the avc specs which are free and mingw. and then compile your own binary.
/me speaks from personal experience.

I agree. "A CLI doesn't and won't protect from stupidity" is just an excuse for "x264 is under GPL. It is given to you 'AS IS'. I am lazy and plz do not ask me for new feature. Get the source code and implement it yourself".

Here is an example about "stupidity":
When the output file exists, x264 will overwrite without prompt while ffmpeg will show "File 'xxx' already exists. Overwrite ? [y/N]". Both are open source CLIs.

[Gusar]

I agree. "A CLI doesn't and won't protect from stupidity" is just an excuse for "x264 is under GPL.
It's not an excuse. It's a design decision by the developers. The way I see it is this: x264cli is a low-level tool. If you want high-level features, create a high-level interface - or use one of the many that have already been created.

Yeah, the developers could put in a safe-guard so x264cli would not blindly overwrite. But must they? No. Mencoder doesn't have this safe-guard either - I know, because I've been burned by it once. So now I'm more careful, and if I use scripts I build safe-guards into those.

[Dark Shikari]

It's not an excuse. It's a design decision by the developers. The way I see it is this: x264cli is a low-level tool. If you want high-level features, create a high-level interface - or use one of the many that have already been created.

Yeah, the developers could put in a safe-guard so x264cli would not blindly overwrite. But must they? No. Mencoder doesn't have this safe-guard either - I know, because I've been burned by it once. So now I'm more careful, and if I use scripts I build safe-guards into those.Also, such a safeguard would be extraordinarily annoying, as whenever I do development and need an output file, I output to the same file repeatedly a few hundred times.

Anyways, this thread is really phenomenally stupid. There is a way to convince developers to add more failsafes into their applications: this isn't it.

[turbojet]

seeing as you're new to the internet I'll explain

that is the awesome face, in this case its used to express feeling of amusement at a silly troll


the tl;dr of this thread
--level is used to set the level flag, and warn if its violated, not to force a level
x264.exe on its own won't violate the level unless you tell it to violate it.

if dark or penvado wanted it to act another one way they would've changed it. And no amount of trolling will make them change their minds; in fact its likely to make them do exactly nothing :)

I am not new to the internet and probably been involved with encoding tools longer then you. I date back to almost the beginning of DVD encoding and was one of the earlier bug reporters. Asking an encoder to do what it is documented to do is far from trolling.

from cli help
--level <string> Specify level (as defined by Annex A)

As it is now you can specify a level so it doesn't follow Annex A. I would say this is more like forcing then really following the level specs. This help would be a lot more accurate currently if it said it tests against a level and warns if it's exceeded.

I for one specify --level 5.1 on all my encodes to prevent people from using DXVA and I would very much be upset if x264 suddenly started wasting my time enforcing 16 references because "it knows what I want".

Any number of references would be allowed and no references would be forced in this case. Just like if you used --ref 2 --level 4.1 it would use 2 references. I only suggested to revert to maximum when it exceeds the limit if/for the level set.

x264 is 'forcing' level flag on us for all who don't use it. I never heard anyone complain about that and frankly I wouldn't be surprised if all the people objecting to it so far will never be affected by my proposal.