DCEmulation

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:

https://github.com/multimediamike/dreamroq

Details here:

http://multimedia.cx/eggs/announcing-dreamroq/
http://multimedia.cx/eggs/roq-on-dreamcast/

It has problems right now but I think it's promising.

Good news Mike!

Welcome to the forums.

I will look at your work, I have never worked with the RoQ format before, I am curious about the compression/quality of the codec.

Thanks again!

Good to see that you've gotten something releasable as a first cut. I'll have to take a look at the code at some point. Hopefully someone can find a good use for it!

Although looking at the source, I am a little confused.

From the ReadME:


From your Code:


pvr_txr_load_ex() is not using DMA. It think its one of the slowest methods since it also applies Twiddling to the textures.

And if the player is decoding a video that will be scaled using the PVR to fit the screen, the PVR_FILTER does make a noticeable difference. I would change the above code to this:



Note the function is still not using DMA, but it should be faster and look better than the previous code.

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).

Haha I tested the code and I did solve your problem Mike.

The speed limitations were not caused by the CD-Rom. They were caused by the twiddling function of pvr_txr_load_ex().

Make the above changes to your code, and it is now as fast as it should be.

If I get some time I will update your player with some enhanced functionality from some code I developed for XviD-DC.

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 !

_________________
Dynamite Dreams Dreamcast fans : http://www.facebook.com/dddreamcast

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:

If you're getting any sort of oddities with sq_cpy (but not with pvr_txr_load), I can only guess its due to the length being not divisible by 4 (although that doesn't make much sense either)...

Ok sorry I didn't know about pvr_txr_load
i thought about this post : http://dcemulation.org/phpBB/viewtopic.php?f=29&t=60229
i thought it wasn't the same as pvr_txr_load, but I was wrong
Thanks for the info BlueCrab

_________________
Dynamite Dreams Dreamcast fans : http://www.facebook.com/dddreamcast

Thanks for all the interest in this bit of code. A month ago, I would have thought I was the last person on the internet to care about Dreamcast homebrew development.

I hope this doesn't seem off topic.

Are there any distinct differences on Dreamcast between fopen() and fs_open() for streaming a ~large file?

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?

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.


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:

http://www.wired.com/wired/archive/3.08/shipping.html

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


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).


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.

Just updated the code for Dreamroq at Github:

* 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.

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.

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.



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.



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, 128kbps
Here is the sample clip I used, from a recent Family Guy episode http://www.megaupload.com/?d=JKY4ZSYQ

52.75fps = read avi packet -> decode video
47.23fps = read avi packet -> decode video -> transfer/draw decoded image
38.30fps = read avi packet -> decode video -> color conversion -> transfer/draw decoded image
30.64fps = read avi packet -> decode video/audio -> color conversion -> transfer/draw decoded image + stream audio

Did you try the '-qscale' option?

I'm a bit confused-- this last line implies that this is a solved problem.

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.