**The Touch Pro Video Playback Bible**

[dishe]

Originally Posted by darkjedi007

Maybe I missed something in the post, but are QTV drivers included in the phone? Or do I have to install it manually?

I have noticed that Coreplayer plays video files better than TCPMP, less dropped frames/smoother and such. I also know that a lot of people have experienced blue flickering with Coreplayer. Does that mean that the QTV overlay is already being used?

No no- Qtv isn't a display driver that you install manually. Its support built into the hardware, waiting to be used. Problem is that most third party applications don't know how to use it, so they just call the standard DirectDraw set instead. If you recall, on the Mogul/Kaiser/Touch, at first people had to disable DirectDraw use to get proper video since the drivers weren't supported well by the OS/hardware. This is the opposite- the capability is there, but the apps don't use it.

Coreplayer 1.x started using Qtv overlay by default instead of DirectDraw. 1.1 only worked on GSM chips, though. The blue flicker only exists when using the overlay method to output video to an external display.
However even the older Coreplayer did a better job at decoding than TCPMP, using some more efficient code that helped drop less frames. The difference appeared on benchmarks, but wasn't dramatic until Qtv support came out.

Originally Posted by TreyBeno

I have noticed that the mp4 format does give better quality in WMP. I watch a few podcasts that are in the mp4 format and Im getting clear tv quality playback with no frame drops. There is no flickering in fast action sequences too. I run a stock sprint TP and can see some merit in the OP.

I should probably mention that these aren't just random theories I had. This is based on information from Core Labs as well as countless threads on XDA. I noticed that a lot of the discussion never made it over here, which led to my post.

Originally Posted by Evil Kaneval

Thanks a lot for this information. I look forward to trying the QTV drivers when or if they become available in this thread.

Your welcome. But, as I mentioned before, these aren't *that* kind of driver. You don't install a .dll or something to make this work. The video playing application needs to send information to the hardware decoder which is just sitting and waiting for this stuff.

I already tried the H264 codecs and watched Wall-E in TCPMP through Saturn Liberty and was completely underwhelmed. This is just my opinion though as this is certainly not a competition. The more information, the better.

Agreed. I'm not sure why Technology1 chose to take it as a personal challenge, but I'm not talking about streaming video quality here. Streaming quality, while definitely getting better these days, is still no match for encoded local content. What I'd LOVE to see is QTV eventually ported over to TCPMP.

[moovius]

Originally Posted by dishe

Agreed. I'm not sure why Technology1 chose to take it as a personal challenge, but I'm not talking about streaming video quality here. Streaming quality, while definitely getting better these days, is still no match for encoded local content. What I'd LOVE to see is QTV eventually ported over to TCPMP.

Who cares about streaming movies anyways unless you have a electrical socket or cigarette lighter you can plug your phone into.

Data Signal + VGA Screen = Quick way to drain a TP battery.

I'd much rather run my movies off the microSD card and not worry about losing evdo signal or having to bring extra batteries along with me... well... you'll need extra batteries anyways, let's be real.

[Darkjedi]

I hope Coreplayer fully supports QTV soon then

[Matt]

Thank you, this thread was very useful. I have a video (avi) that I was playing with WMP that was horrible.

I will ask, of TCPMP, which version is the best in your opinion? One of the old RC's or one of the prepacked with features that is always posted around here? I don't have the need to watch videos enough to warrant Coreplayer's huge pricetag.

[dr g]

This info HAS made it over here, but this is a good summary post nonetheless.

[Technology1]

Originally Posted by moovius

Who cares about streaming movies anyways unless you have a electrical socket or cigarette lighter you can plug your phone into.

Data Signal + VGA Screen = Quick way to drain a TP battery.

I'd much rather run my movies off the microSD card and not worry about losing evdo signal or having to bring extra batteries along with me... well... you'll need extra batteries anyways, let's be real.

Different strokes for different people, what you dislike another person may love, be open mined, but I feel you, yeah...

[Technology1]

Originally Posted by dishe

No no- Qtv isn't a display driver that you install manually. Its support built into the hardware, waiting to be used. Problem is that most third party applications don't know how to use it, so they just call the standard DirectDraw set instead. If you recall, on the Mogul/Kaiser/Touch, at first people had to disable DirectDraw use to get proper video since the drivers weren't supported well by the OS/hardware. This is the opposite- the capability is there, but the apps don't use it.

Coreplayer 1.x started using Qtv overlay by default instead of DirectDraw. 1.1 only worked on GSM chips, though. The blue flicker only exists when using the overlay method to output video to an external display.
However even the older Coreplayer did a better job at decoding than TCPMP, using some more efficient code that helped drop less frames. The difference appeared on benchmarks, but wasn't dramatic until Qtv support came out.



I should probably mention that these aren't just random theories I had. This is based on information from Core Labs as well as countless threads on XDA. I noticed that a lot of the discussion never made it over here, which led to my post.



Your welcome. But, as I mentioned before, these aren't *that* kind of driver. You don't install a .dll or something to make this work. The video playing application needs to send information to the hardware decoder which is just sitting and waiting for this stuff.



Agreed. I'm not sure why Technology1 chose to take it as a personal challenge, but I'm not talking about streaming video quality here. Streaming quality, while definitely getting better these days, is still no match for encoded local content. What I'd LOVE to see is QTV eventually ported over to TCPMP.

Nothing is taken personal, but don't defame and demean another way of doing things, just because you don't perfer that method, that's all I'm saying... Stay tune for new breaking yet to be video technology for the TP coming your way very soon...

[dishe]

Originally Posted by Technology1

Nothing is taken personal, but don't defame and demean another way of doing things, just because you don't perfer that method, that's all I'm saying... Stay tune for new breaking yet to be video technology for the TP coming your way very soon...

::scratches head::

defame and demean? Another way of doing things? What on earth are you talking about?!
All you did was describe a way to use TCPMP to stream a higher-than-average-quality collection of videos found online.

Excuse me if I'm not impressed- That's got nothing to do with accelerating the video performance to levels DirectDraw isn't capable of. I don't care what the source of the video is (H.264, DivX, Mp4, etc), Qtv is REAL hardware acceleration with effects like pixel smoothing (appears to even have real-time anti-aliasing), with no visible screen refresh/flicker or dropped frames, even at full frame, full sized, full motion video. DirectDraw can't do that, and since TCPMP doesn't support Qtv (yet), and ONLY supports at best the DirectDraw method, I don't see what your argument even is.
You don't "perfer" (good job spell checking, buddy) that method- I wonder if we're even dealing with the same topic!

Originally Posted by dr g

This info HAS made it over here, but this is a good summary post nonetheless.

Actually, there is a surprising lack of threads that even MENTION qtv around here. And the few of us who've figured it out think that it causes those blue flickers on video out. And even fewer are aware that WMP and Album are Qtv accelerated (I actually wasn't able to find that one here at all).
Either way, I'm glad people are learning about it now.

[dr g]

Originally Posted by dishe

Actually, there is a surprising lack of threads that even MENTION qtv around here. And the few of us who've figured it out think that it causes those blue flickers on video out. And even fewer are aware that WMP and Album are Qtv accelerated (I actually wasn't able to find that one here at all).
Either way, I'm glad people are learning about it now.

We have known about about incomplete Qtv support since almost day 1. We have known about WMP acceleration since at least mid-December. Album might be new info here but frankly, I don't think anyone would use it for that purpose.

Problems with Qtv mode and blue flicker have been worked out almost since the cable came out ...

[lexluthor]

Nice post.

I've been doing a lot of testing on this over the last few days.

I have a DVD that I've been encoding to 640x480, Video at 700kbps, Audio at 160kbps.

If I encode the video as xvid, it plays at about 20fps in coreplayer. It's dropping a few frames, but it's not too bad. Other xvids that I've played that are more widescreen, like 640x345 play without dropping frames.

If I encode the video as h.264, coreplayer plays it at less than 5fps and it's unwatchable.

If I play that h.264 video in WMP, it plays well. I don't know if there's a way to get the fps or see dropped frames in WMP, but it looks fine to me.

At the same bitrate, I'd say h.264 looks a bit better than xvid.

I like Coreplayer much better than WMP, so I think I'll just encode my own stuff to xvid, but if you obtain videos elsewhere, I think the rule would be to play xvid (and probably divx) in coreplayer and h.264 in wmp or htc album.