Slow video on 1920x1200 screen


11 posts
by Martin Angove » Wed Jan 02, 2013 4:12 pm
I have a stand-alone video player that essentially just plays all the files in a particular directory using Omxplayer. It boots to the player (written in Python) in the command line and doesn't touch the desktop. The player also plots a "holding image" on screen which is covered by the video when playing, but shows between files (it takes a few seconds to start each file - I believe Omxplayer is buffering).

The video files are a mix of SD (usually around 720x576i) and HD files, all in h264, and all of them scale correctly and play correctly when attached to pretty much anything from a rather awful Panasonic plasma via composite video to a "full HD" (1920 x 1080) telly via HDMI. I have getting on for 20 RPis playing happily on a mixture of screens, the most common of which are 1280 x 1024, 1366 x 768 and 1280 x 768, all via DVI.

When I connect a Pi to my 1920x1200 Iiyama however (HDMI), the videos scale up but play like flickbooks. Some of them just play at a slow frame rate, others play at maybe 2fps until the file is nearly ended (reading stopped, playing from buffer?) whereupon the rest of the file plays at breakneck speed. Not sure about the audio as the main displays don't use audio so I've not connected that up.

The main problem is that the Iiyama is my "development" monitor, and it's obviously been rather difficult developing! Desktop works fine at 1920x1200 on the same monitor, so I don't think it's a problem with the monitor per-se. Also the demo video player (in /opt/vc/src/hello_pi/hello_video/) seems to work fine, though I haven't done extensive testing.

Any ideas? I have had a reasonable search through the forums but can't find a problem quite like this one.

I'm using the previous Wheezy image (will try 16/12 shortly), 256MB model B both rev.1 and rev.2, most Farnell-sourced. No keyboard or mouse attached. Network may or may not be attached (i.e. makes no difference).
Posts: 13
Joined: Wed Nov 23, 2011 6:43 pm
by dom » Wed Jan 02, 2013 6:14 pm
Nothing springs to mind.

Can you force the 1920x1200 monitor into a more common mode like 1080p? Try either:
Code: Select all
hdmi_group=1
hdmi_mode=16

or
Code: Select all
hdmi_group=2
hdmi_mode=82

in config.txt and reboot.

I'd like to confirm it is just the resolution that causes the problem.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3997
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Martin Angove » Thu Jan 03, 2013 3:26 pm
Thanks for that - I'll give it a go and let you know. Unfortunately I've just used up my last spare SD card so it probably won't be today.

(I do have a bit of trouble with SD card corrpution, but that's another issue!)

M.
Posts: 13
Joined: Wed Nov 23, 2011 6:43 pm
by Martin Angove » Wed Jan 09, 2013 11:47 am
I have now tested the two config.txt changes suggested. I also tested a bunch more:

key:
A = problem as originally described (video is jerky etc) but all files play. Holding image is often off-centre for some reason (probably related to my software)
B = first video file plays correctly but thereafter the screen is black (possibly a problem with my software - perhaps not reading the display dimensions properly?)
C = unsupported mode, monitor defaults to 640x480@60 and nothing plays
D = unsupported mode, monitor defaults to 640x480@60 but otherwise plays as A

hdmi_group=1:
mode = 4 (720p60): A
mode = 5 (1080i60): B (this one is labelled "native" in the output of tvservice -m CEA)
mode = 16 (1080p60): B
mode = 17 (576p50): A
mode = 18 (576p50H): A
mode = 19 (720p50): C
mode = 20 (1080i50): B
mode = 21 (576i50): C
mode = 31 (1080p50): B

hdmi_group=2:
mode = 4 (640x480@60): A
mode = 9 (800x600@60): A
mode = 23 (1280x768@60): D
mode = 35 (1280x1024@60): A
mode = 36 (1280x1024@75): A
mode = 51 (1600x1200@60): A
mode = 68 (1920x1200@60R): A (as the below doesn't work, assume this is native for monitor)
mode = 69 (1920x1200@60): D (thought this one would be native)
mode = 82 (1920x1080@60): D
mode = 83 (1600x900R): D
mode = 85 (720p60): D

The monitor is an Iiyama PL E2607WS by the way.

I chose the modes to test before using tvservice -m. I was very surprised that DMT modes 69 and 82 didn't work so made a listing using tvservice -m to find that they weren't listed.

Three things seem apparent:

1: left to its own devices, a Pi will play the files properly on any of the monitors I've tried except this Iiyama(*).

2: Even forcing the Iiyama to a mode that I know works on another monitor doesn't quite work, though there may be some glitch with my software that doesn't show up except under these circumstances.

3: Forcing 1080p wouldn't really solve the problem anyway as one of the beauties of the system is that it will sort itself out to the best resolution supported by whatever I plug it into. There's no point forcing a widescreen mode when half the monitors are 5:4, for example.

A fourth oddity was that I was able to get a sensible result from tvservice -m the first few times I tried it, but it now reports only the mode currently configured, or none if the configured mode is unsupported. tvservice -d dumped 0 bytes to file until I power-cycled the monitor whereupon it dumped 256 bytes. tvservice -m still doesn't work.

Interesting?

Hwyl!

M.

(*) monitors, specifically:

Panasonic TH42PH10; 1024x768 but widescreen. Connected by CV - I have to fiddle aspect ratios for films to show on this monitor. It has non-square pixels.
AOC E950SWDA; 18.5" 1366x768 by DVI. Bought because we needed a load of cheap monitors!
ELO ET1947L-8SWA-1; 19" 1280x1024 by DVI. These are used elsewhere in the museum and are (effectively) spares.
NEC LCD3000; 30" 1280x768 by DVI. Also museum spares
Posts: 13
Joined: Wed Nov 23, 2011 6:43 pm
by Mortimer » Wed Jan 09, 2013 12:11 pm
Could this be something to do with the CPU/GPU RAM split?
User avatar
Posts: 710
Joined: Sun Jun 10, 2012 3:57 pm
by dom » Wed Jan 09, 2013 12:31 pm
Martin Angove wrote:A fourth oddity was that I was able to get a sensible result from tvservice -m the first few times I tried it, but it now reports only the mode currently configured, or none if the configured mode is unsupported.

If you specify a hdmi_group/hdmi_mode in config.txt then "tvservice -m" will only report that mode. All other modes are filtered out.

Martin Angove wrote:tvservice -d dumped 0 bytes to file until I power-cycled the monitor whereupon it dumped 256 bytes. tvservice -m still doesn't work.

You should always be able to dump edid (even with hdmi_group/hdmi_mode settings). Possibly when you booted monitor wasn't responding (e.g. you powered Pi before monitor).

So, does omxplayer launched from command line have the same slow framerate issue? Or is it only with your python wrapper code?
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3997
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by Martin Angove » Wed Jan 09, 2013 1:38 pm
Mortimer wrote:Could this be something to do with the CPU/GPU RAM split?


Wouldn't have thought so - I have 64M for the GPU and have previously tried 128M with similar results.
Posts: 13
Joined: Wed Nov 23, 2011 6:43 pm
by Martin Angove » Wed Jan 09, 2013 1:59 pm
dom wrote:So, does omxplayer launched from command line have the same slow framerate issue? Or is it only with your python wrapper code?


Yes, of course, that was the next thing to try. It seems to be quite happy if I let it boot, ctrl-C my player and then play the files from the command line.

I don't know if here is the place to ask for help on code, but the essential part of my app is as follows (stripped the extraneous stuff - it's so short it should be easy enough to work out what's going on):

Code: Select all
# at initialisation
PLAYER = "/usr/bin/omxplayer"
PLAYERQUIT="q"
endtime = # see below

# --- lots of irrelevant code ---

# in the main loop

        if medium[TYPE] == "video":
            scale_and_show(configured[BACKGROUND], screen)

            launchcommand = PLAYER+" "+medium[FILENAME]
            player = pexpect.spawn(launchcommand)

            sleep(1)
 
            while ((time() < endtime) or endtime == 0) and player.isalive():

                sleep(1)
 
            if player.isalive(): player.send(PLAYERQUIT)
            # find the next file to play


The main thing to note is that the code spawns omxplayer as a separate process using the "pexpect" module. If I don't do this, omxplayer will "block" until finished and my code can't do anything else. One thing it is intended to do is to check with a central server for changed / updated files. The other thing is that the player is intended to be able to swap between collections of files at predetermined times of day. If "endtime" is passed, the code should abort the currently-playing file and scan the next directory.

I'm coming back to coding after a very long break, and this is my first attempt at Python. Any hints gladly received, but the thing that is still confusing me is that it works ok on anything *except* my Iiyama!

M.
Posts: 13
Joined: Wed Nov 23, 2011 6:43 pm
by dom » Wed Jan 09, 2013 4:44 pm
@Martin
Can you narrow it down to "holding image" or the sleepy polling? Suppose after launching omxplayer you just sleep(1000000)?
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3997
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge
by KenT » Wed Jan 09, 2013 6:40 pm
I can't see anything amiss with your code.

You could try jbaiters pyomxplayer which is a slightly different use of pexpect. I used it in TBOPlayer which a number of people have used without reporting problems.

I do notice that later versions of omxplayer stutter briefly at the start of a track and skip 600 does not seen to work, but this is on the command line as well.

https://github.com/jbaiter/pyomxplayer

https://github.com/KenT2/tboplayer
Pi Presents - A toolkit to produce multi-media interactive displays for museums, visitor centres, and more
Download from http://pipresents.wordpress.com
Posts: 576
Joined: Tue Jan 24, 2012 9:30 am
Location: Hertfordshire, UK
by Martin Angove » Tue Mar 26, 2013 10:58 am
I know it's been a long time, and quite possibly no-one is watching this topic any more, but I have now had a chance to try a few more things and wish to post details and a couple of corrections.

First, thanks to KenT2 for your suggestion, and I am definitely going to have a look at PiPresents when I get the chance - it does a lot of what I was trying to do, though I really do need the thing to work reliably on 256MB Pis, whatever images or video I throw at it.

Next a quick one to Dom's last post - no, setting sleep to huge numbers (rather than the 1 second I *was* using) doesn't make a difference.

Corrections. I must have misremembered getting the thing to work correctly on 1920x1080 HDMI televisions, because last week when I tried, it didn't.

Caveat - I'm not (yet) using the latest Raspbian image.

tvservice -m problems: I think I know what's going on here - if you force a particular mode, then tvservice will report only that mode. This is a bit annoying, but once you know it's an issue it can be worked around.

Updated information: I have managed to get my app to play videos both on the 1920x1080 HDMI television and on the Iiyama 1920x1200 monitor that was the original problem by a dreadful work-around that involves tricking the Pi into thinking it has connected to a DVI monitor.

Last week I realised that all the monitors that have worked successfully have been DVI-connected, and so far all the monitors / TVs that have failed have been HDMI-connected. The breakthrough came when I connected to the Iiyama by DVI rather than the HDMI I usually use and found that the app worked without any problems.

I have no clue at all why this works. tvservice -m reports exactly the same list when connected by DVI as when connected by HDMI. Forcing a specific DMT mode works when connected by DVI but just swapping to an HDMI connection puts things back to the way they were, despite the Pi successfully selecting the same mode (at least, I assume it does - the monitor reports the same timings).

In order to get the Pi working with a TV that only has HDMI I have had to insert something called a "DVI Detective" by Gefen in the cable. This device records the EDID of the monitor and then reports it to the connected device. The advantage is that you can then make the connection to a monitor through a dumb switch or extender and the source device doesn't realise that there's no monitor attached. I had one spare that was removed from use elsewhere in the museum.

I'm not quite sure what the DVI Detective is doing with regard to the Pi (no switch or extender involved), but it does seem to fool the Pi into believing it's connected by DVI rather than HDMI, and that's what counts.

My next step is to try the latest OS release. After that I will try PiPresents, which uses omxplayer in a similar manner to my software.

So, I'm working around the problem but still not very much closer to knowing what the underlying problem actually is!

Hwyl!

M.
Posts: 13
Joined: Wed Nov 23, 2011 6:43 pm