2700G Decoder Problem with TCPMP

[gabextremev200]

I've been using TCPMP (.66e) with my x50v for a while now, and something's been nagging me. When I try to play any standard XviD/DivX AVI file, there's more noise, blocking, and innacurate color when I use the 2700G Decoder.

To see what I'm talking about, take a look at these samples I have for you.

Clip 1
Download Clip1.avi

Here is a screenshot from the clip as it should appear.
On the x50v, notice the increased blocking in the lower-left corner. Ugly, isn't it?

Clip 2
Download Clip2.avi

Here is a screenshot from the clip as it should appear.
On the x50v, look towards the sky. I'd say there's 30% more ugly block noise when decoded with the 2700G decoder.

Clip 3
Download Clip3.avi

Here is a screenshot from the clip as it should appear.
On the x50v, notice the blocks that form as the bug flies over the character's butt (right cheek) and the flickering garbage data on the left cheek.

Clip 4
Download Clip4.avi

Here is a screenshot from the clip (VGA, high-quality) as it should appear.
On the x50v, notice how all of the darker scenes are displayed as black with blocks, smears, and artifacts, with garbage data all around.

I tried hard-resetting, reinstalling TCPMP, using a different version, etc. but this problem persists. It happens with just about all XviD and DivX files.
Does this happen to anyone else? Or does my x50v have a problem?
Thanks in advance for any help you could give.

[d0pefish]

I'm pretty sure that the blocking is there even on my desktop pc - BUT - it's not as noticable because my desktop has a 32bit colour depth. I think that what you're seeing is that the blocking is more emphasized because of the way that the colours are shown on the Axim's 16bit screen.

Just as a test, look at your screenshots you posted here, but on the Axim, i.e. load up the thread in Pocket IE. You should notice that the blocking is shown slightly, even in the still pictures.

I'll try and explain it in a simpler way. (Someone correct me if I'm wrong, maybe I'm barking up the wrong tree! :))

You have videos that use colours from a palette of over 16 million. But your Axim has a screen that can only show colours from a palette of just over 65,000.

When your video is displayed on the Axim's screen, the EXACT unique colours aren't available, so it uses the nearest match. So, sections of colour that are similar to each other but not the same are more "obviously" different to one another.

I'm pretty sure that the blocking is always there and it's not something the Axim is introducing. I see what you're talking about. But because the colours are slightly different, the blocking looks more pronounced on the Axim's screen. I can see the blocking on my PC's screen if I turn the contrast up a bit.

There's nothing wrong with your i2700G chip. :) What you're seeing is just the nature of the Axim's screen.

I think what you need to do - if you are encoding these videos - is reduce the colour depth of the video to 16bit before the video is compressed, and maybe enable some kind of dithering on the compressor. If you do encode videos, I don't know which software/codec versions you're using, but if you can reply back I'll have a look into it for you if you like. :approve:

Maybe I'm completely wrong, but I'm pretty sure this is what's causing it. But I can pretty much say for definate you don't have faulty hardware!

Update:
I think I'm right after trying this. On TCPMP, change "Options > Video > Intel 2700G" (i.e. NOT "2700G Decoder") and then play the clip. The blocking is still there, right?

But then turn on "Dither" from the same menu and hit play. Blocking is far less noticable for me - at least on Clip3 with the bug.

[gabextremev200]

Thanks, but I should have mentioned that the blocking goes away when I decode with "Raw Framebuffer." Maybe Raw Framebuffer uses some sort of higher-quality color pallete downscaler?

Besides, this problem doesn't occur on my good old x3 basic... that is, when I set the speed to 50% and it can actually play the file, it looks just like the original (as far as my eyes can see ). This happens when dithering is disabled and everything! :hide: :hide:

Hm... last I checked, XviD didn't support 16-bit encoding. I think it only supported 24 and 32-bit.

[d0pefish]

No problem! :) BTW: I edited my post above! :approve:

Yeah, maybe the i2700G has a different way of reducing the palette. Maybe Picard could explain it better. I wonder why Dithering can't be enabled on the hardware decoder... maybe that could be something for a later TCPMP version.

I just checked Clip3 with the Raw Framebuffer mode. Yeah, it's far less visible, but still there especially if you tilt the screen and look closely - it's just a different, more subtle colour. I think i2700G + Dither looks a bit better.

If you use VirtualDub to encode, you can apply "filters" to videos before packing them with XViD or DivX. I'm sure there's one for reducing the colour depth nicely, maybe you could try that. If you tweak the colour depth when encoding, you should be able to have it look right and still get to keep the nice hardware accelerated rendering.

Actually, give me 10 mins and I'll see if I can repack Clip3 at 16bit without reducing the quality (and therefore introduce more artifacts ;) ) :approve:

[MSAgent]

Are you sure you enabled dithering on TCPMP?

[d0pefish]

That's what I mentioned above - Dithering does seem to solve it, but it looks like you lose the advantage of hardware-accelerated rendering (=less strain on CPU and therefore battery) as you have to choose the non-accelreated i2700G renderer. Dithering doesn't look selectable on the hardware i2700G renderer for some reason; at least on my version of TCPMP - 0.66 (not e).

Anyway, I had a quick look at VirtualDub. I couldn't see a 16bit colour filter as such, but an option called Colour Depth that sends a 16bit colour stream to the encoder. Unfortuantely, as you said, DivX at least only encodes at 24bit and 32bit. Grr.

So I saved it uncompressed as 16bit, and then loaded it back up into Vdub, changing it back to a 24bit stream. But of course, it's already been reduced. :approve: (are you lost yet? ;) ) So, saved that as a DivX, switched to i2700G Decoder (hardware), and it's looking pretty good!

For what it's worth, maybe it's a bit of a hassle, as there's an extra encoding step involved in changing the depth, at least with VirtualDub. Maybe there's another video encoding app that can do it properly?

Maybe it'd just be easier overall to just use non-accelerated i2700G with TCPMP doing the dithering, to save yourself from having to painstakingly re-encode all your videos...!

[x2h]

welcome to the club. you don't see those ugly blocks on the PC, do you? and you see those ugly blocks on your x50v.

the reason?

simple. all divx (or xvid) movies are encoded at 24 bit color depth.

but... (and it's a big but)

your x50v (and most other PPC) has a 16 bit color screen, while your PC monitor is capable of 24 bit or even 32 bit. when and where the color depth is beyond your x50v screen's capability, it shows up as blocks.

now, you have to swallow that because no PPC on the market offers 24 bit screen.:( we movie fans have to wait and wait and wait...

[gabextremev200]

Dithering + "Intel 2700G"
looks a lot better than 
No Dithering + "Intel 2700G Decoder."

But even that doesn't look as good as plain Raw Framebuffer...
Look at Clip1 in the bottom-left corner as an example. The blocking is still much more pronounced with the "i2700G" than with "Raw Framebuffer," where you only see a hint of blocking if you look closely.
Or even better, Clip3 at default color options. There are still blocks (albeit less pronounced than the 2700G decoder, or in different places). But with Raw Framebuffer, not a block remains! :)
Do the Intel 2700G and Raw Framebuffer look the same to you? If they do, then it's probably a device problem, right?

[gabextremev200]

Oh, I guess there were some posts I missed! (should have refreshed!) Well, hm... that's a good idea. Re-encoding... thanks, I'll try it out on these clips, lol.

you don't see those ugly blocks on the PC, do you? and you see those ugly blocks on your x50v.

the reason?

simple. all divx (or xvid) movies are encoded at 24 bit color depth.

I guess you have a point there, but when you decode with Raw Framebuffer, the video looks just like the original, even without dithering.
If only "Intel 2700G" looked as good as Raw Framebuffer.

When I use TCPMP's "Raw Framebuffer," the clips look so similar to the originals on the PC that I really can't tell the difference if you were to give me screenshots! Especially with dithering. But when the decoder has anything to do with "2700G," the colors are thrown out of whack and there is blocking, etc. If Raw Framebuffer and i2700G look the same to you, I think its a problem with my particular decoder.

The problems with just sticking to Raw Framebuffer are:
1. At least 3 times slower than "Intel 2700G"
2. Screen tearing problems
3. "Reduce LCD Tearing" option slows it down even more

[d0pefish]

To be honest with you, I don't know if it's just my eyes, but I can't see very much difference between the two modes. There is a very slight difference in the way the blocking looks, but it's definately there in both modes. With Clip1, I see blocking in both, and on my PC - so it's just the way the video has encoded, I'm pretty sure. I think you should just up the bitrate to tackle that problem. After

You've got a very fast moving scene here and a reasonably low-ish bitrate and resolution, so blocking will be even more noticeable on scenes like this. And especially since it's animation, as blocking is made more obvious because it stands out amongst the areas of solid colour and lines. I think bitrate is the next thing to play with as well as dithering and color depth. Aren't there also some DivX tweaks somewhere for fast motion and animation? Not sure.

I can understand it being annoying, but I'd relax before you worry about hardware problems! :) If there was something wrong with your chip, I'm sure there'd be MUCH worse problems happening. Rest assured, I'm confident there's nothing wrong at all with your hardware.

Also playing a part here is the incredibly crisp and sharp screen that these Axims have. So clear that even the smallest imperfections in a video are made noticable - that's probably why you don't notice them as much on a PC, expecially if you have a CRT display. :approve:

Oh, and just to add - seeing as I ended up posting after you - Raw framebuffer without dithering - to me - shows blocking in quite a few places. Add dithering and it looks fine. i2700G is pretty much the same. :approve:

Also, I brought up the whole 24bit bit video, 16 bit screen thing in my first reply...

[gabextremev200]

Yeah, I see that ;)
Well, decoding to 16bit and outputting 24bit gives me even wierder blocking problems, so I'll just stick to i2700G+dithering. I guess it's the best I can get anyway.
As for bitrate, yes, in the first encode, the bitrate was a bit crazy, and there is still blocking in the encode. The others are free of that problem I believe. I just thought Clip1's blocking looked more "pronounced" or something on my incredibly crisp and sharp screen! :approve:

Oh, one last thing you might wanna see: Stay on the first frame of Clip3 (keep dithering on) and just switch between Raw Framebuffer and Intel 2700G in normal-screen mode (not fullscreen). Tilt the screen a bit away from you so you can see the blocks more easily, then switch to Raw Framebuffer mode and do the same. I see no blocks with Raw Framebuffer on the guy's big, clean buttocks! With G, there are blocks on the shadow edge (right cheek), near the right seem of his butt, and one wierd block in the middle-top half of the right cheek.

Okay, maybe I'm going a little overboard looking at a cartoon's BUTT all day, but hey! progress... it's all in the name of progress! :yelrotflm

[x2h]

Oh, I guess there were some posts I missed! (should have refreshed!) Well, hm... that's a good idea. Re-encoding... thanks, I'll try it out on these clips, lol.



I guess you have a point there, but when you decode with Raw Framebuffer, the video looks just like the original, even without dithering.
If only "Intel 2700G" looked as good as Raw Framebuffer.

When I use TCPMP's "Raw Framebuffer," the clips look so similar to the originals on the PC that I really can't tell the difference if you were to give me screenshots! Especially with dithering. But when the decoder has anything to do with "2700G," the colors are thrown out of whack and there is blocking, etc. If Raw Framebuffer and i2700G look the same to you, I think its a problem with my particular decoder.

The problems with just sticking to Raw Framebuffer are:
1. At least 3 times slower than "Intel 2700G"
2. Screen tearing problems
3. "Reduce LCD Tearing" option slows it down even more

i have to agree with you that it does look better with Raw Framebuffer than with "2700G decoder", but no difference with "2700G". In other words, "2700g docoder" is much worse than "2700g" option. However, all of these options will show you blocks that you will not see on your PC monitor.

[x2h]

i usually use bilinear mode when encoding movies for PPC in virtualdub. i found that reduces blocks significantly, although it doesn't eliminate it. the only way to get rid of that, is to have a 24 bit color screen. I've heard there are some 18 bit or even 20 bit screens out there, and, with the power saving WM5 being introduced, maybe we are not too far away from seeing 24 bit screens (wishful thinking?).

[gabextremev200]

Hmm, yeah... You got a point there. WM5 may introduce 24bit screens...hm... Guess I just have to wait:).

Anyone here have an X3? On an X3, all 3 of these clips kick butt (no pun intended). But that's probably because of the lack of screen quality when compared to the X50-51v, eh? :p

Noooo not screenshots from filler episodes!!!!

No more filler!!!

^_^ I recomend watching Bleach after Naruto to cleanse your anime palette of filler :(

I think its just issues with being able to see the noise better with a brighter screen... Perhaps if we tweaked the brigness down a few notches and increased the contrast it might not show as much.