forums.ps2dev.org

[jonny]

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]

@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]

sorry - a little [OT] on encoding still

[Eingang]

[jonny]

[scyrax]

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]

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

[scyrax]

[hyedipin]

[kaveman]

[Raphael]

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]

@Raphael

interesting, thanks.

[scyrax]

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]

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]

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_test_60sec.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]

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#]

@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]

encoder used?
2 pass?
using a profile?

[toker#]

@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]

@ 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]

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#]

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]

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]

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]

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]

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]

[jonny]

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]

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]