Page 3 of 3 12 3
Reply
Thread Tools
OppositeOfIgnorance is offline OppositeOfIgnorance
2008-01-22 , 19:54
Posts: 129 | Thanked: 9 times | Joined on Jan 2008
#21
Originally Posted by GeneralAntilles View Post
Maybe for a stupid PMP, but being able to browse most websites without having to scroll horizontally is what really makes the NITs. If it were actually ******ed, why do you think all the new competition is using 800x480 or better?



Yes, as I said, the OMAP2420 SoC does have a PowerVR (and a hardware video decoder), but since we're not using the built-in LCD controller, there are some hardware issues involved beyond just not having drivers. I believe Nokia has chosen not to release/port drivers because of the poor performance we will get out of 3d acceleration with a 3rd-party LCD controller. I don't particularly agree with this decision (any acceleration is better than none), but I can certainly imagine why they'd choose to go this route.
sorry i forgot to say- thats wut i meant (hi-res is dumb for Video only)
 
fanoush is offline fanoush
2008-01-22 , 21:13
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#22
Originally Posted by Cyker View Post
With Videos, the Zod2 also does a *much* better job than the N800 if you're using TCPMP and watching MPEG4 (i.e. MP4 (Not H.264!), DivX and XviD vids), because of the ATI hardware chip. For other stuff it struggles a bit, and also the 2GB SD limits the amount of stuff you can watch anyway.
Got Zod2 too. Even if it is great device I hardly use it now when I have N800 and 770. When playing video I can't stand the 2 pixel white border around the screen. And the 200MHz CPU is slow for some emulation stuff. But it beats tablets in gaming control department :-) Today I'm using it mostly just to play Duke3D.

And BTW 4GB SD (non-SDHC) cards work too with Zodiac. You only need hacked fat32 driver.
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.
 
Serge is offline Serge
2008-01-22 , 21:46
Posts: 503 | Thanked: 267 times | Joined on Jul 2006 @ Helsinki
#23
Originally Posted by fanoush View Post
EDIT: maybe mplayer does decode frame in advance to some off-screen memory but then it still must wait for display update to finish so it can do the final copy to video memory (possibly with conversion to specific videochip framebuffer format) without overwriting previous (still not fully transferred) frame. Maybe Serge will correct me if he cares to explain it one more time :-)
Yes, you are completely right here. MPlayer decodes frames in planar YV12 format to system memory, then when it is time to display the decoded frame, it moves frame data from system memory to framebuffer (*) converting it to YUV420 or YUV422 format in the process (format names according to Epson documentation) and initiates asynchronous DMA transfer of frame data from the framebuffer to LCD controller memory. We don't need to wait for the completion of this transfer, and start decoding the next frame immediately. Anyway, after the next frame is decoded, we can't write next frame data to the framebuffer unless we are sure that the previous transfer to the LCD controller memory is complete at this point. We get a stall here if the graphics bus is not fast enough to complete the transfer in time (and this stall gets higher if tearsync is enabled as we additionally need to wait for the next screen refresh cycle).

The process of copying from system memory to framebuffer with color format conversion is a small gap, where graphics bus is not used (and graphics bus bandwidth is a scarce resource). Fortunately copying is quite fast and does not take too much time, but improvements in this area can help to avoid some framedrops for high resolution movies playback with tearsync enabled (and tearsync is always enabled for video). We could use something like 'page flipping' if we had enough framebuffer memory.

(*) actually framebuffer physically is a region of the system memory too (unless it is that SRAM which is allocated for Xv overlay, which is not used by mplayer anyway).
 

The Following User Says Thank You to Serge For This Useful Post:
Cyker is offline Cyker
2008-01-22 , 23:42
Posts: 42 | Thanked: 5 times | Joined on Jan 2008
#24
Originally Posted by fanoush View Post
Got Zod2 too. Even if it is great device I hardly use it now when I have N800 and 770. When playing video I can't stand the 2 pixel white border around the screen. And the 200MHz CPU is slow for some emulation stuff. But it beats tablets in gaming control department :-) Today I'm using it mostly just to play Duke3D.

And BTW 4GB SD (non-SDHC) cards work too with Zodiac. You only need hacked fat32 driver.
Yeah, me too admittedly; The battery's practically gone

I did try the hacked fat32 driver but it didn't work for me... do you have a copy of the one you got to work still?
I'd like to try it

I got one set to work in my TH55, but that disables the MP3-playback DSP and anything that depends on it, so had to remove it
That driver didn't work in the Zod alas... just made it crash a lot
 
fanoush is offline fanoush
2008-01-23 , 09:07
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#25
Originally Posted by Cyker View Post
I did try the hacked fat32 driver but it didn't work for me... do you have a copy of the one you got to work still?
I'd like to try it
Try this one http://www.tapland.com/forums/viewtopic.php?t=6455
I got mine from elsewhere so PM me if this doesn't work. Also if card is unreadable it may be better to format the card in PC with usb reader first, I'm not sure Zodiac can format it. But once formatted it works fine.
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.
 

The Following User Says Thank You to fanoush For This Useful Post:
fanoush is offline fanoush
2008-01-23 , 09:24
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#26
Originally Posted by Serge View Post
The process of copying from system memory to framebuffer with color format conversion is a small gap, where graphics bus is not used (and graphics bus bandwidth is a scarce resource). Fortunately copying is quite fast and does not take too much time, but improvements in this area can help to avoid some framedrops for high resolution movies playback with tearsync enabled (and tearsync is always enabled for video). We could use something like 'page flipping' if we had enough framebuffer memory.
I guess you tried to start copying earlier to narrow the gap? It just needs to write to framebuffer data which is already transferred and do not outrun the DMA in progress. Maybe some timestamp when DMA transfer started could help with timing this? But this would need modified kernel anyway (unless the timestamp can be figured out somehow) so we could also preallocate second framebuffer in such kernel too (but this eats memory). Is the timing worth the effort?
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.
 
qole's Avatar
qole is offline qole
2008-01-23 , 17:42
Moderator | Posts: 7,109 | Thanked: 8,820 times | Joined on Oct 2007 @ Vancouver, BC, Canada
#27
I have my biggest video playback problems when some background process (like the N800 connecting to a nearby open wireless network while the bus is stopped at a red light) tries to draw an info box on the screen in the middle of my 1970s Doctor Who episode. By the way, did you know that in a 1976 episode, Doctor Who hooks his brain up to a giant computer and then chases a villain through a computer-simulated reality... called the Matrix? Hmmm, sounds like prior art, to me.
 
Cyker is offline Cyker
2008-01-23 , 23:06
Posts: 42 | Thanked: 5 times | Joined on Jan 2008
#28
Originally Posted by fanoush View Post
Try this one http://www.tapland.com/forums/viewtopic.php?t=6455
I got mine from elsewhere so PM me if this doesn't work. Also if card is unreadable it may be better to format the card in PC with usb reader first, I'm not sure Zodiac can format it. But once formatted it works fine.
Ahh thanks! I'll try it

Although if it works, I think I will have trouble finding a 4GB SD card these days... unless someone's hacked the Treo SDHC driver for Zodiac 2 as well....
 
Serge is offline Serge
2008-01-24 , 07:37
Posts: 503 | Thanked: 267 times | Joined on Jul 2006 @ Helsinki
#29
Originally Posted by fanoush View Post
I guess you tried to start copying earlier to narrow the gap? It just needs to write to framebuffer data which is already transferred and do not outrun the DMA in progress. Maybe some timestamp when DMA transfer started could help with timing this?
Yes, I thought about it, but that's a bit unportable as the timings depend on memory and graphics bus performance difference (and I don't know how this performance may change depending on various factors, for example frequency scaling). And it does not solve the problem completely. Having two pages in the framebuffer seems like a better option. I considered splitting current framebuffer into two parts, doing software downscaling to fit video frames into each part, and do screen updates with hardware upscaling each of the parts to fullscreen. All of this supposedly could be done with a new framebuffer screen update ioctl (which allows to specify destination x and y coordinates), but it did not work as I expected when I tried it earlier (was its implementation buggy?). I can try to experiment with this trick again on OS2008 firmware.

But this would need modified kernel anyway (unless the timestamp can be figured out somehow) so we could also preallocate second framebuffer in such kernel too (but this eats memory). Is the timing worth the effort?
Kernel modifications are rather hard to deliver to end users. We still even can't use YUV420 color format reliably in mplayer on 770 (for ~2% faster video playback) as there is no way to know beforehand if it will work properly (fixed kernel) or deadlock (original kernel). Also such a small speedup may be not enough to provide motivation for the users to install new kernel.
Last edited by Serge; 2008-01-24 at 07:39.
 

The Following 2 Users Say Thank You to Serge For This Useful Post:
Reply
Page 3 of 3 12 3

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 23:28.

Contact Us - Home - Archive - Top