I see some of you have been following my blog postings about developing decent video playback for the Sega Dreamcast. I have just released a new, KOS-license-compatible playback library for the DC using the old RoQ video format. Code here:

You could also cache the pvr_poly_hdr_t header you get from pvr_poly_compile to avoid recreating it every frame. You could pretty much just keep two of them around, one for each frame, saving yourself a little bit (although the twiddling thing that PH3NOM mentioned will probably save a lot more than that).

Yes, I tested too with the above changes and with sq_copy functions it is now faster than the video length ! Just have a display distorsion with sq_cpy but I guess it would be easy to find the loop problem.

Yes, I tested too with the above changes and with sq_copy functions it is now faster than the video length ! Just have a display distorsion with sq_cpy but I guess it would be easy to find the loop problem.

Great job !

There's really little to no reason to use sq_cpy over pvr_txr_load... After all, here's the entirety of pvr_txr_load:

fs_open() and its friends are the lowest-level "public" file access functions in KOS. They're the most direct way of dealing with files, and they avoid any sort of buffering that might be done at a higher level (I don't know that newlib does any real buffering though).

In theory, they might be ever so slightly faster (fopen/fread/etc eventually call down to fs_open/fs_read/etc). In practice, there's probably no difference that anyone would notice.

Using a 512x256 clip, ffmpeg ends up encoding the video @4.5Mbps, which is too fast to be streamed from the /cd/

Attempting to control the bitrate has no effect.

And, even @ 4.5Mbps, the encode is far from lossless.

The compression is not very high, and looks very noticeable.

Not to mention this codec requires an intermediary encoding process, and the final encoder is SLOW. I guess that is OK since this library is likely meant to be hard-coded into a game for FMV or something.

I am starting to think that RoQ may have more limitations...

Mike, if I send you my XviD library, would you have time to look at optimizing the colorspace conversion?

Using a 512x256 clip, ffmpeg ends up encoding the video @4.5Mbps, which is too fast to be streamed from the /cd/

Attempting to control the bitrate has no effect.

You're right that FFmpeg's bitrate parameter has no effect. However, try -qscale. I've played with it. That can shrink the video a bit.

PH3NOM wrote:

Not to mention this codec requires an intermediary encoding process, and the final encoder is SLOW. I guess that is OK since this library is likely meant to be hard-coded into a game for FMV or something.

Yeah, that's the trade-off with vector quantizers like RoQ-- forever to encode, fast to decode. Check out the designer's dev journal, published over 15 years ago:

He speaks of the super-fast and expensive Pentium boxes they purchased for encoding RoQ video.

PH3NOM wrote:

I am starting to think that RoQ may have more limitations...

Try encoding video using the SVQ1 codec in FFmpeg ('ffmpeg -i input.vid -vcodec svq1 output.mov') and see if that can get to acceptable quality within the data rate limitations (and you can test the video in Apple's QuickTime Player). I think SVQ1 is another good candidate for this console.

Then again, I've been analyzing the output of FFmpeg's Switchblade 3 encoder. It's making some odd (apparently suboptimal) decisions. Maybe it can still be improved upon (with SB4, for example).

PH3NOM wrote:

Mike, if I send you my XviD library, would you have time to look at optimizing the colorspace conversion?

A few questions:* Is 512x256 your target resolution? Patbier says he is having success with RoQ on DC @ 320x240.* Are you sure XviD is actually able to handle decoding 512x256 at whatever framerate on your DC, before the colorspace conversion? That seems like a lot.* I only have one idea for optimizing the YUV converter, and that's provided that XviD does not do it already.

* I expect the decoding to be correct; I was able to squash the lingering artifact bug.* Thanks to all the suggestions for making the DC sample player faster. I incorporated some of them.* Added some other optimizations to the core library.

He speaks of the super-fast and expensive Pentium boxes they purchased for encoding RoQ video.

I did read that journal, quite interesting. Made me remember my childhood, life in the mid '90's.When you consider VHS was the leading format of the time, RoQ compression is not bad, at all.But we are no longer in the '90's lol.

Multimedia Mike wrote:

Try encoding video using the SVQ1 codec in FFmpeg ('ffmpeg -i input.vid -vcodec svq1 output.mov') and see if that can get to acceptable quality within the data rate limitations (and you can test the video in Apple's QuickTime Player). I think SVQ1 is another good candidate for this console.

Then again, I've been analyzing the output of FFmpeg's Switchblade 3 encoder. It's making some odd (apparently suboptimal) decisions. Maybe it can still be improved upon (with SB4, for example).

I tried to use SB4, but it is crashing on my PC. I cant get past the first encode process...

Also, forget QuickTime, I use VLC for general purposes. It supports RoQ BTW.

Attempting some ffmpeg encodes with SVQ1, i do believe it is a better codec to work with, simply due to greater flexibility.I didn't achieve the desired quality at the target bitrate, but at the very least the target bitrate was attainable. And I am confident that better results could be achieved with better encoder settings.

If you can write/port a SVQ1 decoder for DC, you should. It would be useful for comparison to decide which codec is best, on this platform.

Multimedia Mike wrote:

A few questions:* Is 512x256 your target resolution? Patbier says he is having success with RoQ on DC @ 320x240.* Are you sure XviD is actually able to handle decoding 512x256 at whatever framerate on your DC, before the colorspace conversion? That seems like a lot.* I only have one idea for optimizing the YUV converter, and that's provided that XviD does not do it already.

For libXviD, yes, 512x256 is my target resolution. Something like RoQ should be 512x512.A few days ago I tested some code to make benchmarks at various stages using my current SH4 optimized build of libxvidcore-1.3.0-rc1.The sample AVI was encoded as DivX@512x256p, 23.976fps, 1Mbps, MP3@48kHz, 2ch, 128kbpsHere is the sample clip I used, from a recent Family Guy episode http://www.megaupload.com/?d=JKY4ZSYQ

For libXviD, yes, 512x256 is my target resolution. Something like RoQ should be 512x512.A few days ago I tested some code to make benchmarks at various stages using my current SH4 optimized build of libxvidcore-1.3.0-rc1.The sample AVI was encoded as DivX@512x256p, 23.976fps, 1Mbps, MP3@48kHz, 2ch, 128kbpsHere is the sample clip I used, from a recent Family Guy episode http://www.megaupload.com/?d=JKY4ZSYQ

Is there some way to control the bitrate on ffmpeg when encoding as roq? I've tried virtually every option and nothing changes. It's permanently at q = 0.0.

Did you try the '-qscale' option?

Yes. The -qscale option works for the svq1 codec, but not the roqvideo codec. Oh, it also only outputs 30 FPS. I can't change that either. I think the ffmpeg encoder is just hardcoded for these things.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum