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. |
![]() |
#21 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,787
|
Quote:
If there's much of a colour difference between 16 and 32 bit colour I must admit I'm not seeing it. For some reason the hardware decoder in my phone doesn't play AVIs all that well. Movement looks a little jerky at times so I always use the s/w decoder for those. I wonder if the color/speed difference is something peculiar to your phone? Or maybe something else is hogging your CPU? PS Actually thinking about it doesn't the "bravia engine" do contrast enhancing and sharpening etc to try to make the image using the LCD screen look better? If that's the case then using software decoding very possibly does bypass it, which would be why using the s/w decoder has the same effect as disabling bravia when using the hardware decoder. Last edited by hello_hello; 3rd January 2013 at 17:03. |
|
![]() |
![]() |
![]() |
#22 | Link |
Registered User
Join Date: Dec 2012
Posts: 16
|
but s/w 32bit works fine,atleast better.I don't if it's only my phone's problem or all the xperia u's.could it be with the gpu(mali 400,not so common as adreno or powervr).cause I cannot play games as well(nfs shift,hot pursuit etc).any way not because too much process stealing my cpu.I always terminates unwanted background apps,allows only basic processes,usually 4.
|
![]() |
![]() |
![]() |
#23 | Link | |
Registered User
Join Date: Dec 2012
Posts: 16
|
Quote:
Last edited by h3nry; 3rd January 2013 at 20:02. |
|
![]() |
![]() |
![]() |
#24 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,787
|
I suspect 480p means 720x480, and a wider width would be considered more than 480p, but according to the info here there's no ref frames restriction for level 3.2 under 720p. http://en.wikipedia.org/wiki/H.264#Levels
The easiest way to find out is probably to run a short encode at 854x480 using the veryslow preset while specifying level 3.2. If the encoder doesn't reduce the number of ref frames to less than 16 you should be safe to use 16. If you're letting the encoder decide the level it's just guessing really. |
![]() |
![]() |
![]() |
#26 | Link | |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 4,653
|
Quote:
1,280×720@60.0 (5)Even Levels 4.x are limited to 9 for 720p, and 13 at Level 5.0. You need to get to Level 5.1 before 14 refs is allowed for 720p. That said, 854x480 is still legal in Level 3.0 (still fewer macroblocks than 720x576). But I have seen hardware decoders (or their middleware layers) that only go up to Level 3.0 also require a max width of 720 and a max height of 576 for 25 fps or less and a max height of 480 for >25 fps. |
|
![]() |
![]() |
![]() |
#27 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,787
|
Quote:
I think x264 uses High Profile unless you tell it to use something else, but looking at the HandBrake guide and how x264 speak is converted to mplayer speak, this would be my best guess: profile=high and level=3.2 should do it, so if you wanted to combine them with preset veryslow I think the command line you'd add to either HandBrake or VidCoder would be: profile=high:level=3.2:Preset=veryslow (I just capitalised the "P" for preset to stop the forum from turning it into a smiliy. ![]() Last edited by hello_hello; 4th January 2013 at 21:52. |
|
![]() |
![]() |
![]() |
#28 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,787
|
Quote:
I wasn't sure how it works myself though, whether for 480p you can use 16, for 720p it's 5, but whether the number of ref frames allowed "scales" for resolutions in between 480p and 720p (ie 12 for around 680p etc), or whether it's a free-for-all right up to the 720p 5 ref frame barrier. I guess if 854x480 is still "legal" 480p and there's no ref frame limit for 480p using level 3.2, x264 should use 16 if one of the slowest presets is also used. If so I guess h3nry can easily test an encode using his phone to see if it's hardware decoder minds. |
|
![]() |
![]() |
![]() |
#29 | Link | |
Registered User
Join Date: Dec 2012
Posts: 16
|
Quote:
I tried it on my phone.though most of the time it showed "video cannot be played" it managed to play a few times.the playback began with white strips,false colors,and huge artifacts.it recovered within 5-10 seconds though. let me see if I can enforce level using handbrakes command line.I had already tried setting the tuning and preset using command line. I thing it didn't worked |
|
![]() |
![]() |
![]() |
#30 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,787
|
If you manually set any of the advanced options such as reference frames or add them to the command line they'll over-ride the chosen speed preset and profile/level. The x264 speed presets won't over-ride the profile/level though, so to be sure it's compliant you might want to use the veryslow or placebo speed preset to get the maximum number of reference frames while setting the level 3.2. You can still change any of the other options if you don't want to use the exact speed preset settings (number of b frames etc). I'm pretty sure that'll work.
I gather some decoders check the video stream differently to others. For instance MPC-HC's DXVA decoder has options to do a full check, skip the level check, skip the ref frames check or not check anything. By default it just skips the level check but I guess different decoders might do it differently. |
![]() |
![]() |
![]() |
#31 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,787
|
If you want to be completely compliant you might want to check if there's any bitrate restrictions in the phone's specs, and x264 doesn't automatically enforce them for a specificed profile/level as far as I know, so you might want to add the appropriate --vbv-bufsize & --vbv-maxrate settings to the command line. There's a table of them here. I'll go with the assumption it's correct.
http://www.encoding.com/do_you_have_any_information_on_h.264_levels |
![]() |
![]() |
![]() |
#33 | Link | |
Registered User
Join Date: Dec 2012
Posts: 16
|
Quote:
then I tried a 1080p video with reframes=16 and set the level to 3.2.the resolution itself won't fit in the level.still mpc-hc showed level 3.2 with reframes=16 for a 1920*1080p video. |
|
![]() |
![]() |
![]() |
#34 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,787
|
Quote:
I just ran 4 short encodes using x264 defaults and the veryslow preset. High profile Level 3.2. I changed nothing but the resizing in the script each time. According to MediaInfo: 1280x720, 5 ref frames. 854x480, 12 ref frames. 720x480, 15 ref frames. 720x400, 16 ref frames. And just to be 100% certain it was x264 adjusting the number of reference frames and not MeGUI being clever, I created a script and opened it with AvsPmod and used it to run two encodes using the same command line. According to MediaInfo: 1280x720, 5 ref frames. 720x480, 15 ref frames. So I guess my suggestion there are no ref frame restrictions for level 3.2 under 720p was wrong, while I guess my theorising that it might work on a sliding scale according to resolution is correct. Well the x264 encoder seems to think so..... Quote:
1280x720, 16 ref frames, Level 3.2 Given my VidCoder encode still used 16 ref frames at 1280x720, it shows VidCoder can no more use an x264 speed preset than HandBrake can. The obvious conclusion would be it's simply letting you select a speed preset but adding the appropriate x264 advanced options to the command line behind the scenes instead of requiring you to enter them manually as HandBrake does. I had no idea VidCoder's x264 speed preset option is really only VidCoder playing pretends. You learn something every day. I think that makes it a bad program in some ways. Users might expect the chosen speed preset will have it's ref frames kept in check by the x264 level used as it should. At least Handbrake is honest about it. Last edited by hello_hello; 7th January 2013 at 22:04. |
||
![]() |
![]() |
![]() |
#35 | Link | |
Registered User
Join Date: Dec 2012
Posts: 16
|
Whatever,if it doesn't work,the video should be showing appropriate level.why is it still showing level 3.2 for 1080p video with 16 reframes?how's that possible?
Quote:
|
|
![]() |
![]() |
![]() |
#36 | Link |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
If the thing uses libx264, it would have to implement reference frame limits by itself. The library does not have this feature built-in. In it, just like in x264cli quite some time ago, the level setting is just a flag. Nothing more, nothing less. If you used libx264 and got reference frames limited automatically, then something implemented that and set the settings for libx264 manually.
On the other hand, x264cli, which is used by, f.ex., MeGUI, does actually limit reference frames to the level limits if the user does not override. It is implemented in x264.c: Code:
/* Automatically reduce reference frame count to match the user's target level * if the user didn't explicitly set a reference frame count. */ if( !b_user_ref ) { int mbs = (((param->i_width)+15)>>4) * (((param->i_height)+15)>>4); for( int i = 0; x264_levels[i].level_idc != 0; i++ ) if( param->i_level_idc == x264_levels[i].level_idc ) { while( mbs * 384 * param->i_frame_reference > x264_levels[i].dpb && param->i_frame_reference > 1 ) { param->i_frame_reference--; } break; } }
__________________
[I'm human, no debug]
|
![]() |
![]() |
![]() |
#37 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,787
|
Quote:
According to JEEB's post above this one however, I got that wrong. The version of x264 which HandBrake/Vidcoder uses simply doesn't have the ability to limit reference frames according to the specified level as the command line version does. If that's the case I'm sorry, I was completely unaware of the differences in x264 versions and as a result I've probably led you on a bit of a wild goose chase. |
|
![]() |
![]() |
![]() |
#38 | Link |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
Not really a case of versions. The x264 provides libx264 (the library) and x264cli (the command line encoder).
x264cli uses libx264, and then implements a command line application around it to encode stuff with easily (input modules, ability to read data from files etc.). It also implements that piece of code I posted. In other words, if any application uses libx264, it won't get that feature. For example ffmpeg and libav lack this for that exact reason in their libavcodec libraries, as they do not implement it themselves. And Handbrake, for example, if I recall correctly, uses libavcodec to encode with libx264. Thus, setting the level there is a case of just setting a flag to a value. I recommend people either poke x264 developers to get this feature into libx264, or start poking the projects using it to implement the feature ![]() I've been thinking about implementing it in libavcodec for a while, maybe when I get the time...
__________________
[I'm human, no debug]
|
![]() |
![]() |
![]() |
Thread Tools | Search this Thread |
Display Modes | |
|
|