scyrax wrote:
ps:Video with pure color(red,blue etc.. )seems to be blocky(artifacts)on psp.but the original avi which was 480x272 with nosound (used to generate pmp) seems no problem on pc,is there any simplification on the decoder?(sony`s offcial pmf format suffers the same problem,but it seems ok in umd video)
one of the 'unique' things about encoding video for the psp is that you are coding for a fixed resolution device, thus encodes are 'pixel perfect' to the psp's lcd. on a PC, invariably, when people make compressed videos they are more often than not played on screens that have resolutions far in excess of the original avi's. this allows the pc to do some scaling and post-processing that helps to avoid the stair effect you see as you are extrapolating pixels when increasing output resolution. (actually there's a lot more to it than that, but it is a factor).
I've been experimenting with encoding settings to help avoid stepping, as, as jonny points out, there is no post-processing on the psp. this means more time and care needs to be spent on the encoding side, to try to avoid some of these kind of artifacts. blocking is another issue, and temporal noise, amongst others.
without wanting to go too off-topic and talk about encoding too much, there are some things you can try - the 'chroma_opt' in mencoder (i'm using mencoder, but the options are in any xvid build) for xvid is designed to help reduce stepping by raising the accuracy of colour segments and neighbouring areas. additionally, a higher bitrate will also help.
additionally, selecting 'chroma_me' can help with colour movement by raising the motion estimation for colour (similar to raising me_quality but for colour)
perhaps try adding some simple post-processing near the end of the filter chain (pp=,fspp,spp,pp7 - i prefer the last one for simplicity, but the pp= option allows you to select your own filters for deblocking/deringing etc.).
of course all these options i mention will have an impact on encoding time. take a look at
http://ronald.vslcatena.nl/docs/xvidfaq.html for a great xvid options guide
@jonny
this brings me to another point i'd been pondering. if you make headway in to being able to optimise reading a display routines, do you thing that there would be enough spare cpu cycles to do any post-processing that in built into libavcodec? could the GPU do this? not being familiar with the GPU capabilities of the psp, are there any advantages to using upscaled PMP's that are resize-sharpened down (like UMD's) - i mean is that theoretically possible - and are there other things that the GPU can do that can offload certain aspects from the cpu? malloc's mods which allow resizing smaller vids, don't seem to impact cpu/decoding at all, as they seem to just process the screen buffer.
for example post-processing in ffdshow is something i've been doing for a long while to denoise/resizesharpen/addnoise above native resolution of my HDTV, then using the PC's overlay to resize back down. this produces a higher perceived quality than watchin raw low-res avi's - i'm sure you're familiar with the principle. you think that's something you'll be looking into at a later date? this would go a long way to create sharper vids, with deblocking, but maintain modest bitrates.
just curious :)
i'll kick off some more thought about this on doom9 when i can start posting.
