PMP Mod v2.02 & PMP Mod AVC v1.02

jonny · Post by **jonny** » Tue Feb 07, 2006 9:33 pm

upscaled video is not a good idea (the bitrate needs will increase, at this point simply raising the bitrate is a better method :)
there is a good list of optimizations planned (one will probably use the gu)
but you now, i go on slowly and with small steps :)

(with the current speed, it's too early to try postprocessing code)

scyrax · Post by **scyrax** » Tue Feb 07, 2006 9:42 pm

@kaveman

I have a single frame from Madagascar trailer without PS(which captured from mpc`s saveimage option ) to show these artifacts~~ ,watch the red edge!
http://xs.to/xs.php?h=xs67&d=06062&f=blocky.png
I`ve just tried that :'chroma_opt' or simply increasing bitrates were no help to eliminate this artifacts~~
and this artifacts can only be totally eliminated by using overlay video mode!(Vmr9 was obviously worse than overlay,but still better than the origin)
It`s a good idea to implement postprocessing at the encoding phase:)
thx for your link,that`s really helpful.

btw:THx to jonny`s effort,If there were another 3fps faster in next release,It might play 30fps well @1000Kbps most condition.:)

kaveman · Post by **kaveman** » Tue Feb 07, 2006 11:26 pm

sorry - a little [OT] on encoding still

I`ve just tried that :'chroma_opt' or simply increasing bitrates were no help to eliminate this artifacts~~
and this artifacts can only be totally eliminated by using overlay video mode!(Vmr9 was obviously worse than overlay,but still better than the origin)

red/blue-stepping is a problem that is endemic in a lot of video compression systems - as I understand, apparently due to colourspace conversion. take a look at some discussion here http://forum.doom9.org/showthread.php?t ... a+stepping

most encoding/filtering/processing is done in YV12, but i'm not sure what the output format of the psp is, to try encoding directly in the output format - this would avoid colourspace conversion, but will also likely significantly affect encoding speed negatively (assuming it's even possible) - i'd imagine PMPMod expects PMPs in YV12?

processing during encoding (preprocessing to be more precise!) will help clean up an image (for example ringing from sharpening, denoise, deblocking) and these will help clean the source frames, and free up some bits to help encode more true detail, but the reality is the last event of the filter chain will always be the 'encode' phase. when encoding with preprocessing, what you're trying to do is to make as clean a source as possible before encoding, but you'll never be able to entirely reduce encoding artifacts. it's a lossy process.

the chroma_opt filter does help a bit, but high-contrast edges with red/blue are still likely to suffer from stepping. TRUE post-processing (i.e. during decoding) would help fix this to a degree, but that's not possible with PMPMod right now.

It`s a good idea to implement postprocessing at the encoding phase:)

it depends on the source, but essentially, yes, to varying degrees. DVD's and the like require less preprocessing during encoding than say tv capture encodes - mainly due to the high bitrate and high resolutions of the DVD to start with. for DVD you might just want a simple sharpen filter, for example. A tv cap will already have a fair amount of artifacting, and transcoding these without processing filters will just make matters worse, especially if sharpening the video - without deblocking, you'll also sharpen block edges, and increase the complexity of each frame, reducing overall quality as the compressor will encode superfluous 'noise detail'. this is less of a problem if quantizer based encoding is used as bits are allocated as needed, but the filesizes will grow. the image won't be entirely clean either. when trying to be modest with bitrate/filesize this is more problematic.

btw. discussions such as this are better placed in this forum - http://forum.doom9.org/showthread.php?t=106714 - i only registered yesterday so have to wait a few days before posting.

Eingang · Post by **Eingang** » Tue Feb 07, 2006 11:40 pm

k0nan wrote:
Eingang wrote:Jonny, please do not forget that we have still that sound issue with that beep and noise in background... would be really nice to get good audio quality !
I used to encounter what you describe or something similar (a slight but constant ring noise in the background) when converting from an AC3 audio source. If you encode DVDs or other AC3 sources with mencoder, are you using the 'volume normalization' option? This cleared up all of my issues with AC3 sources and I've had perfect audio ever since.

The point is, this noise is created by muxing and has nothing to do with the source quality. Convertion from ac3 to mp3 works flawlessly and mp3 sound quality is absolutely nice, no need for normalisation if downmixed correctly. You can listen to the mp3 with PSP media player, clear and nice. Then you mux this mp3 file, play the pmp and suddenly you have this noise.

Normalisation is some kind of treating the symptoms but not the cause.

jonny · Post by **jonny** » Wed Feb 08, 2006 12:38 am

i'd imagine PMPMod expects PMPs in YV12?

inside mpeg4 asp, the video is always in yv12
(the ideal is working always and only in this colorspace / on the encoding side)

scyrax · Post by **scyrax** » Wed Feb 08, 2006 1:26 am

after "googled" the color step problem I think I`ve got the idea~~

xvid using YV12 formats,which means Chroma were store in half resolution than luma.
To display on a Progressive RGB device(CRT,LCD etc...) needs YV12-->RGB convertion.
on PC,the convertion were done by videocards when using overlay modes which interpolate the Chroma info up to 2X resolution to avoid these color steps.but if you use other mode(like VMR9)in software program mode,for the sake of speed it just using point sampling from Chroma info so that looks exactly jaggy as PSP presents.

It can be infer that PSP doesen`t have a dedicated hardware design for Chroma interpolation(because Sony`s offical PMF format got the same problem).when 480x272 video source played(like PMF using h.264 or PMP using xvid)it`s Chroma resolution was actually 240x136. so it looks jaggy on red/blue edges,and UMD video dosen`t suffers from this because it has a resolution of 720x480 whose Chroma resolution was 360x240 much larger than 240x136.

to sum up,There are only two ways to avoid these color steps:
1.interpolate the Chroma info in software modes.
2.using lager resoultion video format.

both needs more processing power... so it dosen`t seem could be solved in the near future....

jonny · Post by **jonny** » Wed Feb 08, 2006 1:37 am

your analysis is useful and bring a good point (!!!).

1.interpolate the Chroma info in software modes.

i'll do this in the future, but with the gu (this is implicitly covered by an optimization i've planned - move the csc to the gu)
not in the next version, but probably in the next-next :)

scyrax · Post by **scyrax** » Wed Feb 08, 2006 1:42 am

jonny wrote:your analysis is useful and bring a good point (!!!).

1.interpolate the Chroma info in software modes.
i'll do this in the future, but with the gu (this is implicitly covered by an optimization i've planned - move the csc to the gu)
not in the next version, but probably in the next-next :)

Wow,can`t wait to see ur next-next release:)

hyedipin · Post by **hyedipin** » Wed Feb 08, 2006 3:34 am

jonny wrote:@hyedipin:

please, as specified in the first message:

sorry,

i apparently skipped just one single page, where hell broke loose. Sorry, once again, and thank you for PMP Mod.

kaveman · Post by **kaveman** » Wed Feb 08, 2006 4:39 am

jonny wrote:
i'd imagine PMPMod expects PMPs in YV12?
inside mpeg4 asp, the video is always in yv12
(the ideal is working always and only in this colorspace / on the encoding side)

yes - i've always understood about working in YV12 as this seems to be the fastest raw colourspace for filter processing (for example when postprocessing using ffdshow, a simple denoise or minor level adjust before running resize etc to force YV12 and increase speed, and disabling the other colour workspaces). given the limitations of this format, however, apart from speed, are there any other benefits...? i'll do some more investigating on doom9

scyrax wrote:xvid using YV12 formats,which means Chroma were store in half resolution than luma.
To display on a Progressive RGB device(CRT,LCD etc...) needs YV12-->RGB convertion.
on PC,the convertion were done by videocards when using overlay modes which interpolate the Chroma info up to 2X resolution to avoid these color steps.but if you use other mode(like VMR9)in software program mode,for the sake of speed it just using point sampling from Chroma info so that looks exactly jaggy as PSP presents.

It can be infer that PSP doesen`t have a dedicated hardware design for Chroma interpolation(because Sony`s offical PMF format got the same problem).when 480x272 video source played(like PMF using h.264 or PMP using xvid)it`s Chroma resolution was actually 240x136. so it looks jaggy on red/blue edges,and UMD video dosen`t suffers from this because it has a resolution of 720x480 whose Chroma resolution was 360x240 much larger than 240x136.

actually - my understanding - i may be totally wrong here - was that the colour information was stored at 12-bit resolution (hence YV12) rather than 24-bit, which is where the 'half resolution' issue arises, not physical resolution size, but otherwise your chroma-interpolation analysis/solution is spot on. and that jonny is working on this for a future gpu optimisation makes me wanna give him a big hug. but i'm too manly for that 8)

UMDs are stored at 720x480 (probably for some kind of future-proofing or downscaling advantage), but they are probably in 24bit which retains the colour resolution, and the downscaling gives them their sharpness.

kaveman

ps: ah what the hell, have a hug jonny!

Raphael · Post by **Raphael** » Wed Feb 08, 2006 5:45 am

as to your first question:
yv12 also compresses better than rgb.

As for an explanation of the yv12 format:
yv12 has a 12bit per pixel effective bitrate, because the chroma information is downsampled, so one pair of chroma components (u + v) are saved for every two (4:2:2) or every four (4:1:1 or 4:2:0) luma components (y). As yv12 is a 4:2:0 format, theres 4*8bit y + 2*8bit u&v = 48bit per 4 pixels = 12bit per pixel.
So the real loss of information is the color information, which is only given for each 2x2 pixel block (what is apllicable because the human eye recognizes luminance better than colors) and therefore creating blockiness. The solution is interpolating the downsampled u and v planes, which will be done in the future like jonny said. Then every component will have its own plane, which will then just be blended together to make the final image, and therefore the GUs bilinear filter function can be used to upscale the u and v planes and reduce the blockiness.

kaveman · Post by **kaveman** » Wed Feb 08, 2006 6:42 am

@Raphael

interesting, thanks.

scyrax · Post by **scyrax** » Thu Feb 09, 2006 11:02 pm

I had a questions jonny.
The interleaved AVframe would definitely be faster for using mechanical HardDisk,but I doubt if there were any help for using electronic Memory Stick??

jonny · Post by **jonny** » Thu Feb 09, 2006 11:44 pm

interleaving increase the speed a bit in every case
i'm also going with async reading (everyone will see a speed increase, but in a different amount this time - depending on his memstick/hdd)

gutty47 · Post by **gutty47** » Fri Feb 10, 2006 6:10 pm

I'm surprised this hasn't been brought up before because I've been battling this problem since PMP Mod was released.

Basically the problem I have is that on longer clips 1-3 seconds of video at the end is just not shown. I don't know if this problem affects just me or if its a wide ranging problem, but I created a test clip that for me demonstrates the exact problem.

http://rapidshare.de/files/12931083/pmp ... c.rar.html

The rar file contains:
The avisynth script that I used to make the test file.
An AVI file which has XviD video encoded through VirtualDub using XviD 1.1 with a Q setting of 4. FPS = 25.
A blank 1 second 96kb/s CBR MP3 file.
The log file from muxing the video and audio together and the resulting PMP file.

The pmp should have ~1500 frames of video. The AVI plays fine on the computer, but in PMP Mod only frames 0-1477 are shown before it quits back to the menu. Which leaves ~1 second of video just missing. This problem was exhibited on all versions of PMP Mod I could find.

I have an original JAP 1.50 PSP and I'm using a Sony 2GB memory stick (it only gets ~375fps on that test you released earlier).

Just as I post this I finished encoding the test clip using DivX 6.11 and it seems to quit at frame 1476, one frame earlier than XviD.

I hope someone else could try the clip and post what results they get.

Cheers. :D

jonny · Post by **jonny** » Sat Feb 11, 2006 2:00 am

yep i don't flush buffers when the video finish :)
the missing part should be no more than 1 second (with a 24-25 fps clip).
i'll correct this in the next version, thank you!

toker# · Post by **toker#** » Sat Feb 11, 2006 3:00 am

@jonny

PSP JAP 1.50
2GB Sony High Speed Duo Pro

I am still getting audio stutter at 25fps 1000kbps Xvid 480x272.
Should I drop the fps to 23fps or the bitrate?
Is there a limit in terms of data throughput that PMP 1.02 can handle?

jonny · Post by **jonny** » Sat Feb 11, 2006 3:08 am

encoder used?
2 pass?
using a profile?

toker# · Post by **toker#** » Sat Feb 11, 2006 3:32 am

@Jonny

I have used very encoder under the sun!!

Mencoder
ffmpeg
virtualdub + xvid 1.03
virtualdub + xvid 1.1
virtualdub + xvid 1.2

Currently, virtualdub + xvid 1.2 (For Dual core support)
My normal source is DVD but sometime i use HDTV sources.
Video: Xvid 1000kbps 25fps 480x272 -2 pass (no extra filters)
Audio: MP3 128kbps

PMP Mod 1.02 is much better than the previously version in terms of audio stutter. I just trying to work out whats the max throughput PMP mod can handle and base my encoding on that. It is probaby not that straight forward as 1000kbps plays fine most of the time and audio stutter only happens a few times during a movie. Generally when the scene is heavy with lots of movement. Maybe i,m heading in the wrong direction.

My aim is to get a good quality encoding with no audio issues. I cant except many thing less than 1000kbps on Xvid cos the quality loss is huge in my opinon.

I will encode some clips on 23fps 1000kbps Xvid and see what happens.

604000 · Post by **604000** » Sat Feb 11, 2006 4:48 am

@ toker#

We were talking about it. Look at page 35 in the middle of the post. kaveman made a good explanation.

Until then I stopped testing diferent configurations for the encoding. Now I encode all my files @750 kbps and all of them look great. I don't think that less than 1000kbps could be a bad quality file. If this problem is related with the buffer of the psp, maybe using a lower bitrate it'd work better and I think that a bitrate of 760 for the video and 128 for the audio is a good middle point with good quality of video withouth a too heavy file.

jonny · Post by **jonny** » Sat Feb 11, 2006 5:13 am

I've told this many times, using VirtualDub+DivXorXviD+2pass+Profile is the only way to be sure there is some limitation on bitrate spikes.

For example GiBBz reported good results with XviD using the DXN HT PAL profile (i've told this also in the previous page).

I'm interested on impressions, results using profiles, if someone want to contribute.
But this type of discussion must continue @doom.org

toker# · Post by **toker#** » Sat Feb 11, 2006 10:48 am

Ok, i have resolve the audio stuuter problem that I have been getting on lot of my encoding.

VirtualDub 1.6.11 + Xvd 1.2
Video: Xvid 1000kbps @ 23fps 480x272 : 2 pass (24bit and not 12bit)
Audio: MP3 128kbps

This have produced very good video and plays fine on PMP Mod 1.02.

Droping 2fps and using 24bit has worked wonders for me.

w.kosma · Post by **w.kosma** » Sun Feb 12, 2006 12:18 pm

hello,

sorry if this question is not related, but what`s the easiest way
to loop movie in pmp? (which variable to look for)
i remember i did in some pre 1.0 version, but right now everything
looks much different,

thanks for good work,

wojciech

jonny · Post by **jonny** » Sun Feb 12, 2006 8:36 pm

in:

pmp_play.c > pmp_play_start

add this:

if (current_video_frame == p->decoder.reader.header.vid.number_of_frames) current_video_frame = 0;

after:

current_video_frame = pmp_next_video_frame(p, current_video_frame);

w.kosma · Post by **w.kosma** » Sun Feb 12, 2006 9:37 pm

thanks!

i did the job,

if i can one more quick question:

it the previous versions (pre 1.0) i assigned LTRIGGER and RTRIGGER
to automaticaly load next/prev file from the folder, so you don`t have
to go back to menu ,

can you please give me a quick how to on this?
sorry for bothering but it will be big help

thanks again,
wojciech

jonny · Post by **jonny** » Sun Feb 12, 2006 10:00 pm

this is not quick :)

you should stop playing the current clip on LTRIGGER or RTRIGGER (you can track keys in pmp_input_thread) and flag there is a LTRIGGER/RTRIGGER request with a variable.
in pmpmod.c you should check for this variable and start playing the prev/next clip automatically

therock003 · Post by **therock003** » Mon Feb 13, 2006 12:42 am

jonny wrote:I've told this many times, using VirtualDub+DivXorXviD+2pass+Profile is the only way to be sure there is some limitation on bitrate spikes.

For example GiBBz reported good results with XviD using the DXN HT PAL profile (i've told this also in the previous page).

I'm interested on impressions, results using profiles, if someone want to contribute.
But this type of discussion must continue @doom.org

What do you mean?This way's better than using a soft like winmenc,pmp simple converter etc?

As for ghosting what's the solution?Even with 1.02 i still notice the red fringing when scenes change.I mostly use hdtv sources.

jonny · Post by **jonny** » Mon Feb 13, 2006 1:37 am

what i've written is clear enough (maybe it's not 100% true, if MEncoder have a way to control video buffer verifier)
search in this thread, search @doom9.org, search with google.
(this is the typical answer lazy users will get from now :)

therock003 · Post by **therock003** » Mon Feb 13, 2006 3:04 am

I don't have any problem with searching,it's just that i don't know what to search for.

I'm refering to the ghosting/fringing problem,and since you're the creator of the programm i thought you could possibly have the solution for it.

jonny · Post by **jonny** » Mon Feb 13, 2006 3:12 am

I'm refering to the ghosting/fringing problem

that is also already discussed and i've nothing to add about this argument