STICKY: HOWTO: Create Custom HDMI modes

[scottnla]

It does seem to be the aspect ratio. The former suggestion made it better (so the video was taking up 75% of the width of the screen) and the latter kept it about the same.

I'm tempted to make a video that's wider than 960 x 960, but I think that the video would still end up distorted in the playback, so that's not a real solution. Hmmm.

[dom]

It does seem to be the aspect ratio. The former suggestion made it better (so the video was taking up 75% of the width of the screen) and the latter kept it about the same.

I'm tempted to make a video that's wider than 960 x 960, but I think that the video would still end up distorted in the playback, so that's not a real solution. Hmmm.

The firmware thinks your screen is 16:9 by default, and so assumes the pixels are wider than they are tall.
If you have a video that is 960x960 with square pixels, omxplayer thinks it has to squash the width to make it display correctly.

If you modify the aspect ratio flags of the video to claim the display aspect ratio is 16:9 (but resolution is still 960x960) you should find it displays as you want.

[scottnla]

I tried changing the video's pixel size using ffmpeg:

Code: Select all

ffmpeg -i input.mov -sameq -vf crop=960:960 -vf setdar=16:9 -strict experimental -r 30 output.mp4

and then having the aspect ratio match that of the video by setting the last parameter of hdmi_cvt to 3. This causes the video to take up the entire screen (yay!) but it looks too skinny / distorted

When I run omxplayer, I just noticed the information:

Code: Select all

Aspect : num 9 den 16 aspect 1.333333 pixel aspect: 0.421875
Video codec omx-mpeg4 width 1920 height 1080 profile 0 fps 30.000000

So it seems like the pixel aspect is correct, but whatever the 'other' aspect is isn't quite right.

[dom]

Where's 1920x1080 coming from?

I tried changing the video's pixel size using ffmpeg:
Video codec omx-mpeg4 width 1920 height 1080 profile 0 fps 30.000000

Possibly the crop isn't doing what you want. How does the video play on a PC? What does mediainfo report its dimensions/aspect ratio are?

[scottnla]

I didn't know about mediainfo before -- that's a really handy command!

I did an experiment with three videos, each with a resolution of 960 x 960 pixels with display aspect ratios of 1:1, 4:3, and 16:9 (verified with mediainfo).

I then set the raspberry pi's aspect ratio to 4:3 (verified with tvservice).

The 1:1 video was too narrow, while the 4:3 and 16:9 videos were indistinguishable from each other.

I then changed the raspberry pi's aspect ratio to 16:9 and found that the 16:9 video was too wide (gaps on the top and bottom) while the 1:1 and 4:3 were too narrow, with the 4:3 having the last amount of gap space around the left and right edges. Very odd.

These results don't really seem to make much sense...

I might start trying other aspect ratios, but I really feel like I'm just taking stabs in the dark here.

[simon]

Hello,

First time posting on the forum but been getting lots of useful information from it for a few months now!

I use:

hdmi_timing=<h_active_pixels <h_sync_polarity <h_front_porch> <h_sync_pulse>h_back_porch> <v_active_lines> <v_sync_polarity> <v_front_porch> <v_sync_pulse> <v_back_porch> <v_sync_offset_a> <v_sync_offset_b> <pixel_rep> <frame_rate> <interlaced> <pixel_freq> <aspect_ratio>

to generate a set of video signals that are spot on. I know I checked with a scope however, the aspect ratio displayed on my screen is incorrect. The resolution is 1280x480 which is not one of those listed so I assume that this resolution is unsupported.

I set the aspect_ratio parameter to '7' (21/9) which is the nearest I could find to my resolution of 24/9 but as expected the results are incorrect.

I am a bit puzzled why the aspect_ratio parameter is required at all. As long as the other parameters are set to match the display in use that should be enough. Why modify the data with the aspect ratio? Is there ever a case where this parameter is different from the ratio given by h_active_pixels/v_active_lines? Am I misunderstanding something here?

Could I ask what effect this parameter has on the video data? I am guessing it alters the frame data by the aspect_ratio.
And if the aspect_ratio is the same as the ratio h_active_pixels/v_active_lines then there is no effect on the data!

If this parameter is necessary wouldn't it be an idea to replace it with <aspect_ratio_denominator> <aspect_ratio_numerator> so that any desired aspect_ratio could be used removing the limitation of the identifier currently in place? Just a thought.

Is there anything I can do to display the aspect ratio correctly on my display or have I had it? Is there a hidden identifier for 24/9?
BTW I cannot change the resolution of the display. Also I need to be able to display all sorts of random content so changing the aspect ratio of the content is a non starter.

I need to duplicate this setup a few times so this low cost solution is ideal should I be able to get it to work as required.

Thanks for a very useful feature!

Cheers
Simon

[simon]

Anyone know if its possible to set a 24/9 aspect ratio?
Thanks
Simon

[tzj]

It should be possible to have custom ratios, but AFAIK Dom is the only one to implement it.

[dom]

Anyone know if its possible to set a 24/9 aspect ratio?

The aspect ratio parameter is used for the AVI InfoFrame (an out of band signalling packet transmitted separately to the pixel data).
The options we support are the only options the HDMI spec allows.

There is no way of signalling 24:9 over HDMI.

The real question is what the problem is when it isn't set correctly. Are you tryinng to get omxplayer to scale correctly?

[tzj]

Wouldn't it be possible to go out of spec so long as a custom driver circuit for the display is made and doesn't exceed the allowed bandwidth?

[simon]

Anyone know if its possible to set a 24/9 aspect ratio?

The aspect ratio parameter is used for the AVI InfoFrame (an out of band signalling packet transmitted separately to the pixel data).
The options we support are the only options the HDMI spec allows.

There is no way of signalling 24:9 over HDMI.

The real question is what the problem is when it isn't set correctly. Are you tryinng to get omxplayer to scale correctly?

Hi. Thanks for the response.

Yes, the problem is that it does not scale properly. The video signals vsync, hsync, data enable etc are correct....and I don't want to mess around with the content to get it to scale as the content is not under my control.

The scaling is correct when I use a PC as the HMDI source with 24/9 (with the same porches, clock etc) rather than a RPi. But I'd rather use RPi's for my setup. Smaller, nicer, etc, etc

I'm not using omxplayer. The display I am using is a custom display that has specific requirements.

BTW I am using:

hdmi_timings=1280 0 140 40 140 480 0 10 10 25 0 0 0 30 0 25200000 7

Thanks.
Simon

[simon]

Wouldn't it be possible to go out of spec so long as a custom driver circuit for the display is made and doesn't exceed the allowed bandwidth?

The RPi is able to generate the the correct vsync, hsync, pixel clock etc. So yes electrically it can cope. Dom says that HDMI does not support the 24/9 aspect ratio I require.... and RPi conforms to the the HDMI spec. I guess I would like RPi to support custom aspect ratios.

Simon

[dom]

Yes, the problem is that it does not scale properly. The video signals vsync, hsync, data enable etc are correct....and I don't want to mess around with the content to get it to scale as the content is not under my control.

The scaling is correct when I use a PC as the HMDI source with 24/9 (with the same porches, clock etc) rather than a RPi. But I'd rather use RPi's for my setup. Smaller, nicer, etc, etc

I'm not using omxplayer. The display I am using is a custom display that has specific requirements.

What exactly is incorrect? X? The console framebuffer?

I don't think this is a HDMI issue. It's probably a software issue in determining the framebuffer size/scaling.
We are generating a framebuffer with the required number of pixels, and I assume they are filling the screen. Is the problem that circles are displayed elliptical?

Can you confirm:
what is the pixel resolution of display?
what is the width / height of the display (i.e. are the pixels square?)
How are you observing the problem?
What does

Code: Select all

tvservice -s
fbset -s

report?

[simon]

Hi,
Responses below.

I don't think this is a HDMI issue. It's probably a software issue in determining the framebuffer size/scaling.
We are generating a framebuffer with the required number of pixels, and I assume they are filling the screen.

Yes, the screen is being filled.

Is the problem that circles are displayed elliptical?

Yes, circles are elliptical horizontally.

what is the pixel resolution of display?

Resolution is 1280x480
I am using:

Code: Select all

## TIMING OVERRIDES
hdmi_ignore_edid=0xa5000080
hdmi_group=2
hdmi_mode=87

hdmi_timings=1280 0 140 40 140 480 0 10 10 25 0 0 0 30 0 25200000 7

I use aspect_ratio=7 as that is the closest to 24/9

what is the width / height of the display (i.e. are the pixels square?)

Yes, pixels are square.

How are you observing the problem?

On screen everything looks wider than it should be.

What does

Code: Select all

tvservice -s
fbset -s

report?

Code: Select all

pi@raspbmc:~$ tvservice -s
state 0x120016 [DVI  RGB full 64:27 (21:9)], 1280x480 @ 30Hz, progressive

Code: Select all

pi@raspbmc:~$ fbset -s
mode "1x1"
    geometry 1 1 1 1 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

Thanks
Simon

[simon]

I use aspect_ratio=7 as that is the closest to 24/9

I just noticed aspect_ratio=8 is actually nearer to my requirements . I will try this.
Simon

[simon]

I use aspect_ratio=7 as that is the closest to 24/9

I just noticed aspect_ratio=8 is actually nearer to my requirements . I will try this.
Simon

Makes no difference with this setting. tvservice reports unknown AR.

Code: Select all

pi@raspbmc:/boot$ tvservice -s
state 0x120016 [DVI  RGB full unknown AR], 1280x480 @ 30Hz, progressive

Code: Select all

pi@raspbmc:/boot$ fbset -s
mode "1x1"
    geometry 1 1 1 1 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

Simon

[dom]

I use aspect_ratio=7 as that is the closest to 24/9

I just noticed aspect_ratio=8 is actually nearer to my requirements . I will try this.
Simon

Makes no difference with this setting. tvservice reports unknown AR.

Code: Select all

pi@raspbmc:/boot$ tvservice -s
state 0x120016 [DVI  RGB full unknown AR], 1280x480 @ 30Hz, progressive

Code: Select all

pi@raspbmc:/boot$ fbset -s
mode "1x1"
    geometry 1 1 1 1 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

Simon

I'm confused. What are you running when you ran this command? I'd expect something like:

Code: Select all

pi@raspberrypi:~ $ fbset -s

mode "1872x1056"
    geometry 1872 1056 1872 1056 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

when using the console framebuffer (e.g. command line or X). Are you running something with EGL (like xbmc?)

[simon]

I'm confused. What are you running when you ran this command? I'd expect something like:

Code: Select all

pi@raspberrypi:~ $ fbset -s

mode "1872x1056"
    geometry 1872 1056 1872 1056 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

when using the console framebuffer (e.g. command line or X). Are you running something with EGL (like xbmc?)

Yes I am running xbmc and logging in with ssh. I am fairly new to RPi and didn't realise this matters.

[simon]

I'm confused. What are you running when you ran this command? I'd expect something like:

Code: Select all

pi@raspberrypi:~ $ fbset -s

mode "1872x1056"
    geometry 1872 1056 1872 1056 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

when using the console framebuffer (e.g. command line or X). Are you running something with EGL (like xbmc?)

Yes I am running xbmc and logging in with ssh. I am fairly new to RPi and didn't realise this matters.

OK - I did it using the command line (exit from xbmc, esc to enter command line ) and I get the same as before for tvservice -s. But for fbset I get the following:

Code: Select all

pi@raspbmc:~$ fbset -s
mode "1280x480"
    geometry 1280 480 1280 480 16
    timings 0 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/16
endmode

[dom]

Yes I am running xbmc and logging in with ssh. I am fairly new to RPi and didn't realise this matters.

Makes a big difference.
Try adjusting aspect ratio here:
http://wiki.xbmc.org/index.php?title=Se ... alibration...

[simon]

Try adjusting aspect ratio here:
http://wiki.xbmc.org/index.php?title=Se ... alibration...

Thanks, but this was one of the first things I tried. The xbmc video calibration didn't allow me to even come close to displaying a square. It is set to the best I could achieve which is a rectangle with the longer length on the horizontal.

[smudger]

Have update firmware rpi-update and rebooted

However both in Rasbian and Pidora can get no joy with hdmi_cvt
it returns command not found but i persist

In posts there seems to be inconsistency in syntax e.g
hdmi_cvt 960 540 60
hdmi_cvt=960 540 60
hdmi_cvt=960x540 60

hdmi_cvt=960x540 60 is most successful as error only returned at last argument i.e 60
so hdmi_cvt=960x540 I guess passes OK

any tips /suggestions most gratefully received!

UPDATE: Couldn't use resolution config on the fly with terminal. However did have success using CEA group and mode 4 (1280x720p) and had to tweak overscan enabling it and using - minus values between -20 and -35
Mode 4 I guessed would be successful because it is a factor/ratio? of the native 1920 x 1080 resolution.
Don"t know why DMT unsucessfull (or cvt) but there we are...
.

[arm2]

I've used 1920x1200 & 1200x1920 (I like portrait monitors!) fine.
I've seen Dom & Eben post that the maximum resolution is 1920x1200 but...
We’ve just received a nice 2048 × 1152 monitor which only 2.4% more pixels and the wiki does list it as
hdmi_mode=84 2048x1152 reduced blanking

So I've tried it and it almost works....
Under RISC OS selecting the mode allows the pointer into the corners of the screen and the Monitor reports it is receiving 2048x1152@60Hz but the desktop is indented on the left and on the right and truncated at 1920pixels, slightly in from the right edge. Vertically the image fills the screen. Though clicking the mouse causes actions scaled.
n.b. RISC OSs booting splash screen fills the monitor and it reports at that time it is getting 2048x1152@60Hz
The RISC OS driver author says there is no limitation imposed by RISC OS.

Under Debian with no explicit monitor settings in config.txt it seems to display 1920x1152 i.e. full height but indented left and right, cursor is bound by the desktop area. The monitor reports 2048x1152@60hz. On the desktop under Preferences ->: Monitor settings I get: Unable to get monitor information. adding to config txt
hdmi_group=2
hdmi_mode=84

If I set config.txt to 1080p the monitor reports that is what it is getting.

So it would appear to me that the GPU maybe at times running at 2048×1152!
Am I correct?
Could the firmware be tweaked?

n.b. the wiki also lists:
hdmi_mode=76 2560x1600 reduced blanking
hdmi_mode=77 2560x1600 60Hz
hdmi_mode=78 2560x1600 75Hz
hdmi_mode=79 2560x1600 85Hz
hdmi_mode=80 2560x1600 120Hz reduced blanking
Can someone confirm they should be removed from the wiki?

[boehm]

hello everyone

I tried to attach a 640x640 resolution display. As you said I can't find an aspect ratio which meets my display requirements. Did you have any success since last year? Is the RPi able to drive this resolution?
Thank you

greets

Michael

[dom]

I tried to attach a 640x640 resolution display. As you said I can't find an aspect ratio which meets my display requirements. Did you have any success since last year? Is the RPi able to drive this resolution?
Thank you

Probably best to create a firmware github issue requesting this.
It is possible in theory, but requires some plumbing and some testing.