Auto aspect ratio does not work any more for 4:3 h264 re-encoded files in 2.2.6

[theBored]

I re-encode the recordings using handbrake. Before 2.2.6, if the aspect ratio initially did not work for a recordings, I just had to toggle the full screen button on the remote (or alt+Enter on the keyboard) twice, and the correct aspect ratio was chosen. Now, for 4:3 ratio files, I have to choose pillarbox, the auto setting does not work any more. Usually the files have a resolution of about 528x400. (the height is fixed to 400, handbrake autocrops them).

Is there any quick fix for this? Thanks!

[sub]

I re-encode the recordings using handbrake

What type of file are they after this?

If it's still a .ts, can you make a small sample file (<40MB) that shows the aspect ratio problem.

[theBored]

I remux them into a .ts file using vlc, and then run them through mpeg2repair because of another error (I started a thread about that a while ago, somebody suggested mpeg2repair, and it worked).

Here is the link to the file:
http://www.megaupload.com/?d=Y79CO4E0

Thanks!

[sub]

Give this patch a go.

Until 2.2.x, NextPVR had never had any detection of H.264 aspect ratio, and you were just getting lucky. It now does attempt to determine the aspect ratio, but because H.264 doesnt have any simple indicator of the aspect ratio it has to guess based on the resolution. 1080i/720p etc are very easy to guess based on the resolution. Unfortunately it didnt have the foggiest idea what aspect ratio your 528x400 files are, since these are non-standard resolutions, so it assumed they were widescreen 16:9, which is usually try for H.264.

It adds a special case rule for that resolution.

[mvallevand]

Rather than special casing all the non-standard crap that people make themselves or find online, wouldn't it be better to calculate the ratio and put it in the closed ratio? Alternatively you could just leave non-standard ratios alone and not reset them when you find one.

Martin

[sub]

Rather than special casing all the non-standard crap that people make themselves or find online, wouldn't it be better to calculate the ratio and put it in the closed ratio?

Unfortunately its not that simple. To determine the aspect ratio in H.264 you pretty much need to decode a frame, but thats too much effort required and doesnt really make sense in a source fiter, so for now the application will just do the best it can with the information it has available.

Alternatively you could just leave non-standard ratios alone and not reset them when you find one.

You cant "leave non-standard ratios alone", the application always has to assume something (and always has), since the video needs to be positioned somewhere on the screen. The default assumption has changed from 4:3 to 16:9, which is why the very few 4:3 H.264 users have noticed a difference, but it's fixed the aspect ratio for a much larger set of users (standard definition H.264 channels in Europe/NZ/etc).

[mvallevand]

Unfortunately its not that simple. To determine the aspect ratio in H.264 you pretty much need to decode a frame, but thats too much effort required and doesnt really make sense in a source fiter, so for now the application will just do the best it can with the information it has available.

I understand that it is complicated but you do it now and eventually find it .

2011-09-18 16:59:05.537 [DEBUG][1] Aspect ratio now: 16x9
2011-09-18 16:59:05.537 [DEBUG][1] Resolution is now: 528x400
2011-09-18 16:59:05.537 [DEBUG][1] Source Aspect Ratio: 16x9

Instead of forcing it to 16x9 which could reset a user F7, you could leave it alone because it is not known if calculating that 528/400 = 1.32 is closer to 1.33333 then 1.77778 is too difficult.

Martin

[sub]

I understand that it is complicated but you do it now and eventually find it .

2011-09-18 16:59:05.537 [DEBUG][1] Aspect ratio now: 16x9
2011-09-18 16:59:05.537 [DEBUG][1] Resolution is now: 528x400
2011-09-18 16:59:05.537 [DEBUG][1] Source Aspect Ratio: 16x9

Instead of forcing it to 16x9 which could reset a user F7, you could leave it alone because it is not known if calculating that 528/400 = 1.32 is closer to 1.33333 then 1.77778 is too difficult.

In that particular example I could have looked at the pixel resolution to guess it was 4:3, but doesnt work for the majority of standard def resolutions, where for example 720x576 or 720x480 can be either 16:9 or 4:3 and the pixel resolution as no bearing on the choice.

I will try to improve it to be smarter though.

[theBored]

In that particular example I could have looked at the pixel resolution to guess it was 4:3, but doesnt work for the majority of standard def resolutions, where for example 720x576 or 720x480 can be either 16:9 or 4:3 and the pixel resolution as no bearing on the choice.

I will try to improve it to be smarter though.

Thanks a lot, the fix worked!

Now probably what I am saying makes no sense, but would it be possible that for standard resolutions NVPR does what it has been doing, and for non-standard resolutions calculates the aspect ratio from the pixel resolution?