My expectations VS the reality.


directive0

Very Active Member
Joined
Apr 8, 2015
Messages
840
Location
Toronto, Canada
Okay so all of you working on the Pyra either with ED or as testers with the OMAP boards I would appreciate it if you could help me hit/miss this list of expectations for the Pyra so I can avoid being unrealistic. I'm wondering if these things are ALREADY possible, WILL BE possible, or are NOT LIKELY to be possible either because of hardware limitations or software isn't written to support the functionality.

  • I will be able to load up VLC and play a bunch of HD and 4k videos onto my TV over HDMI
  • I will be able to plug an external HD into it and format it with gparted from apt-get.
  • I will be able to download the Arduino IDE and edit/compile/upload code without modification.
  • I'll be able to use the GPS in the 4g module to view my position on a map that I have already downloaded
  • I will be able to access the advertised onboard sensors (magneto, barometric, gas and humidity) in Python and graph them
  • I will be able to run Pandora apps on the Pyra
  • I will be able to use, without any modification, any application available through apt-get
  • I will be able to use a bluetooth headset with minimal configuration in every application simultaneously (sound playing in browser and sound playing in vlc are both audible through headset at same time)
  • I will be able to skip songs, adjust volume etc with bluetooth controls (on headset, on speaker).
  • I will be able to disable the keyboard backlight as well as all onboard LEDs if desired.
  • I will be able to adjust CPU speeds and settings like the Pandora.

These are all I can think of for now. Thanks.

Sorry if this is covered in a thread already, search and cursory reading did not reveal analogs to my questions and the existing threads got swampy so I'm starting this one. Please delete if its a problem.
 
  • I will be able to load up VLC and play a bunch of HD and 4k videos onto my TV over HDMI
HDMI output caps off around the 2K, plus currently there is no hardware decoding, so until there is it's up to brute CPU decoding. If the video isn't horrible encoded, most of the 1080p videos I've tried work alright. but it consumes a bit of CPU usage.
  • I will be able to plug an external HD into it and format it with gparted from apt-get.
Seems reasonable.
  • I will be able to download the Arduino IDE and edit/compile/upload code without modification.
Most likely
  • I'll be able to use the GPS in the 4g module to view my position on a map that I have already downloaded
Should be able to.
  • I will be able to access the advertised onboard sensors (magneto, barometric, gas and humidity) in Python and graph them
Yeah shouldn't be an issue.
  • I will be able to run Pandora apps on the Pyra
That would require a lot of work actually. It's easier just to port over the software to the Pyra.
  • I will be able to use, without any modification, any application available through apt-get
Well not every application is on apt-get, most likely anything Pyra customized will come in a slaeshjag's DBP package. currently a spiritual successor to PND, but easier to deal with IMO
.
  • I will be able to use a bluetooth headset with minimal configuration in every application simultaneously (sound playing in browser and sound playing in vlc are both audible through headset at same time)
A more modern bluetooth software is in the later version of debian, hopefully just work.
  • I will be able to skip songs, adjust volume etc with bluetooth controls (on headset, on speaker).
I can't get that to work even on my laptop in Linux, it may be easier now... who knows.

  • I will be able to disable the keyboard backlight as well as all onboard LEDs if desired.
Yeah there are buttons for that.
  • I will be able to adjust CPU speeds and settings like the Pandora.
Currently there is only three speeds to choose from, I'm assuming this will change once the Prototypes are out to the gurus
 
Re: Running PNDs on Pyra:



Forgive my ignorance, but is there a lot more to do if you had a copy of the latest SZ in a folder and chrooted to that?

Well that is most likely how you get started, but one thing I can can think of real quickly that may be an issue is much of how the systems that handle the framebuffer overylays and such on OMAP5 has changed drastically from how it works on the OMAP3. My guess something like Notaz's SDL will need to be modified. Although there is still a bit of challenges facing just regular software on the OMAP5, currently there isn't any easy method of scaling a game running at say 320x240 up to full screen. I have code examples for scaling images, just nothing easy for fullscreen games and such. I'm not an expert, just what I know from clumsily fiddling with the devboard.
 
Another question, not expecting an answer until someone with the hardware actually tries it out since I know it should be possible: Receive notifications (preferably vibration) of messages and calls with a US 4G Pyra on a major carrier without doing something sneaky.

I don't plan on switching over to the big companies, just want to see if they will actually work with us. It also might reassure a few people, or move a few more units. A T-Mobile store employee told me it would be fine after I described it, but it wouldn't be the first time someone gave a customer bad info.

Edited to remove indentation.
 
There's no chance for 4k decoding on the Pyra.
For anything practical, 4k also means h265 encoding. Currently you need a pretty modern GPU (at least Nvidia Maxwell 2, AMD Polaris or Intel Skylake/Kaby Lake*) to even decode h265 on x86 in hardware.
I've been told, some top-end AMD Visheras with 8 cores can brute-force that in software, but I'm sceptical whether that's true. My Intel i7-2700k fails miserably at decoding even the lowest-bitrate h265-4k jellyfish sample videos [1], despite being overclocked to 4.3 GHz. I estimate that I'd need at least 2.5 times the computing power to do it. Hyperthreading isn't helping at all, so an AMD with true 8 cores should be better off. A dual core arm SoC from 2013 is surely not up to this task.

*) Skylake only decodes the "Main" profile, Kaby Lake and the Nvidia/AMD chip also decode "Main10".
[1] http://jell.yfish.us/
 
There's no chance for 4k decoding on the Pyra.
For anything practical, 4k also means h265 encoding. Currently you need a pretty modern GPU (at least Nvidia Maxwell 2, AMD Polaris or Intel Skylake/Kaby Lake*) to even decode h265 on x86 in hardware.
I've been told, some top-end AMD Visheras with 8 cores can brute-force that in software, but I'm sceptical whether that's true. My Intel i7-2700k fails miserably at decoding even the lowest-bitrate h265-4k jellyfish sample videos [1], despite being overclocked to 4.3 GHz. I estimate that I'd need at least 2.5 times the computing power to do it. Hyperthreading isn't helping at all, so an AMD with true 8 cores should be better off. A dual core arm SoC from 2013 is surely not up to this task.

*) Skylake only decodes the "Main" profile, Kaby Lake and the Nvidia/AMD chip also decode "Main10".
[1] http://jell.yfish.us/
What about converting the video to an uncompressed format and playing that?
 
What about converting the video to an uncompressed format and playing that?
Still not enough, and you'll run into I/O problems.

I just decoded the 120mbps 4k jellyfish video to raw (which results in a 11GB file btw.) and tried to play it on my HTPC, which is an old laptop with a T7600 Core2Duo and an SSD connected to the SATA1 port.
The I/O to the SSD tops out at around 110MB/s which is by far not enough to get the video data in real time. I have to reduce the playback speed to roughly 30%, then the required I/O goes down to about 90MB/s and the video plays smoothly in slow motion. The CPU usage is at about 60% on both cores during playback and if I had to make a wild guess I'd think the T7600 is about 1.5 times faster than the OMAP5432.
So even if you were able to make use of the full theroretical potential of the Pyra's USB 3 or SATA 2 port (each 300MB/s), which might just be enough to transfer the data in real time, you'd still be lacking the CPU power to process it.

Besides:
Transcoding 4k videos for the Pyra and keeping them in 4k makes no sense anyway. As TrashyMG pointed out, you have no way to output a 4k signal. So if you have to transcode in the first place you might just as well reduce the resolution.
The Pyra should be able to output 1080p in h264 if we get proper hardware accelleration. Until then you can transcode your videos to 1080p raw which the Pyra should be able to play in software if the data comes via USB 3, SATA or maybe a really fast SD card (depending on how much the SD slots are able to deliver).
 
Cool!

I know that 4k is a tall order, and so I wanted to be extreme with my expectation so you guys could help bring me back down to earth. I appreciate all the realism and candor!
 
The Pyra should be able to output 1080p in h264 if we get proper hardware accelleration.
Actually the 1080p videos I have been playing with are h264 encoded. To accomplish this I bump up the amount of threads used to decode h264 videos in SMPlayer. However there are some horrible encoded 1080p videos that the CPU just can't keep up with, but those are actually pretty rare in my collection of videos.
 
Actually the 1080p videos I have been playing with are h264 encoded. To accomplish this I bump up the amount of threads used to decode h264 videos in SMPlayer. However there are some horrible encoded 1080p videos that the CPU just can't keep up with, but actually pretty rare in my collection of videos.
Just when you posted this I wanted to write, that the Pyra should be able to decode real-time h264 1080p in software, as long as the framerate isn't too high. My T7600 decodes the 30fps Big Buck Bunny video [1] at about 60% usage on both cores and doesn't miss playing the 60fps smoothly by much. I guess it might just be able to play 50fps.

So if my guess of my HTPC being about 1.5 times faster than the Pyra is right, then 30fps should work on the Pyra as well, albeit with a very high usage.
Can you please try to play the 30fps BBB video with these mpv options and watch out for frame drops? (edit: especially the scene when approaching the rabbit hole right after the opening title is very taxing):
Code:
 --vd-lavc-fast --vd-lavc-skiploopfilter=all --vo=xv
(There's also --vd-lavc-threads=2, but that should be set automatically.)


[1] http://bbb3d.renderfarming.net/download.html
 
Last edited by a moderator:
Can you please try to play the 30fps BBB video with these mpv options and watch out for frame drops? (edit: especially the scene when approaching the rabbit hole right after the opening title is very taxing):
yeah, I'll give it a go when I get home from work in 5 hours or so.
 
The bandwidth and frequency requirements for WQXGA 60Hz and 4k 30Hz are almost identical, 4K 24Hz even requires a significantly lower pixel clock. I don't see why the display controller shouldn't be able to do this, the only restriction I can think of would be the max render buffer size supported by the SGX, but the only other GPUs I know of that can't fit 4K into their render buffers are already over 10 years old, 16384x16384 has been a common limit for over 7 years already.

The OMAP5 EVM reference guide does not contain any information other than HDMI 1.4 being supported, the IGEPv5 Hardware Reference Manual states that the OMAP5 only supports 1080p 60Hz max, the bit of information you are referring to is actually contradictory to begin with (2560x1600 == WQXGA, 1920x1200 == WUXGA) and I found TI community topics that cover both as well as referring to the fact that those limits are only referring to a standard frequency of 60Hz. There seems to be a lot of false information going around, including errors in TI's own documentation.
 
Last edited:
There seems to be a lot of false information going around, including errors in TI's own documentation.
Shocking...


Well, I could try it on my roommates 4K TV...
[doublepost=1484781790,1484770810][/doublepost]@sulu , It's not complaining about dropped frames, but mpv just looks like it's a little chunkier than what I've played with mplayer/smplayer.

It's really smooth on mplayer by upping the thread amount to 4 and I've tried the same or more on mpv and it's not as fast.

Code:
mplayer -lavdopts skiploopfilter=all:threads=4  bbb_sunflower_1080p_30fps_normal.mp4
 
currently there is no hardware decoding
I currently have no reason to doubt it will work though, especially since the ipumm repository was discovered. It just requires some work be put in to make it actually work.

currently there isn't any easy method of scaling a game running at say 320x240 up to full screen
That's actually completely trivial using drm.
 
Back
Top