SRec 2.x on github

@salass00

Ah ..

Quote:

Yep i'm using p96_pip .. consider that pratically all Sam440 users have a Radeon 9250, not to count the old AmigaOnes :-/

Quote:

Ah understand ..
Do you think you can found a non-RGB solution for our old system ?

@samo79

Quote:

Intelligent users, of which I'm sure you are one, will understand that efficeint encoding far outways the short term inconvnience of the fact that current players seem to be a bit deffiecient WRT this codec.

Really ingenious ones might write a simple ARexx script to autmatically call ffmpeg to avoid the "pain" of worrying about conversion.

If that doesn't work for you nag LiveForIt to build anew mplayer with the mssing codec included....

@salass00
I tested v2.5 with Sashimi and here are the results:
------------------------------------------------------------------
recording 1200x960 at 30 FPS
altivec unit detected
new screen: 0x61ef7d28
dimensions: 1280x1024x16 pixfmt: 10
Frames recorded: 390
Frames skipped: 78
Total: 468
Avg time spent in encoder per frame: 33315 microseconds

recording 1200x960 at 30 FPS
new screen: 0x61ef7d28
dimensions: 1280x1024x16 pixfmt: 10
Frames recorded: 402
Frames skipped: 59
Total: 461
Avg time spent in encoder per frame: 30884 microseconds
-------------------------------------------------------------------
As you can see, the average time per frame is actually greater for altivec than without altivec. It appears that altivec isn't providing any benefit in SRec other than possibly leaving more CPU time for other tasks.

My testing consisted of starting the recording and moving the SRec window around for about 15 seconds before stopping the recording. The videos displayed with MUI_MPlayer had normal color and no corruption. However, MUI_MPlayer took 45 seconds to display a 15 second 1200x969 30 FPS video. Apparently MUI_MPlayer can't keep up with a video that large at 30 frames per second.

I did notice one minor glitch while recording. I was going to time the recording using a system clock running in digital mode. The clock stopped updating the time after about 8 seconds. I ended up using my watch to time the video recording.

I don't understand why others are getting "pink" videos because mine appear normal (correct colors) to me.

@xenic

You would be better testing at a frame rate where the CPU wasn't maxed out so that no frames were skipped IMHO. Otherwise the activity you perfrom will make a huge and difficult to repeat effect on the video encoded as it gives way to the CPU needs of moving windows etc.


And ideally with a more repeatable sequence of events, perhaps an ARexx script that opens and closes windows in a set timed sequence and perform each test of a clean boot.

[edit]

Having said that even an 'not maxed out CPU' you get afew frames dropped when dargging a window arround.

And my test does confirm that AltVec seems slower....


11.NGFSBoot:> appdir:sashimi
Sashimi installed ([Ctrl]+C or "Break 11" to remove)
recording 1920x1080 at 10 FPS
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
Frames recorded: 159
Frames skipped: 20
Total: 179
Avg time spent in encoder per frame: 48946 microseconds

recording 1920x1080 at 10 FPS
altivec unit detected
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
Frames recorded: 171
Frames skipped: 29
Total: 200
Avg time spent in encoder per frame: 59659 microseconds


Altivec is the second test

My first though is , "Is the logic of the alivec switch the right way round?" ie is it actually on when it selected to be off?

@broadblues
Quote:
I had the same suspicion initially but it seems unlikely that the program would check for an altivec unit (altivec unit detected) if it's not using altivec.

@broadblues

If the "altivec unit detected" message is printed then altivec code is being used:

https://github.com/salass00/srec/blob/master/src/zmbv.c#L81

It would be helpful if you could test against a version with prefetch disabled like this one:

https://dl.dropboxusercontent.com/u/26 ... ec-2.5r197-no_prefetch.7z

From what I've read prefetch is only useful if you do a lot of calculations rather than mostly just reading and writing in a tight loop like in the SRec ZMBV encoder. Also it might not make as much of a difference with newer altivec cores as with early G4 ones.

@salass00

No prefetch version


recording 1920x1080 at 10 FPS
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
Frames recorded: 106
Frames skipped: 13
Total: 119
Avg time spent in encoder per frame: 52189 microseconds


recording 1920x1080 at 10 FPS
altivec unit detected
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
Frames recorded: 96
Frames skipped: 9
Total: 105
Avg time spent in encoder per frame: 52338 microseconds

Much closer timewise but not much benefit.

@broadblues

Could you try this version too?

https://dl.dropboxusercontent.com/u/26599983/srec-2.5r198-test1.7z

I've "strategically" replaced some of the vec_ld()s with vec_ldl(). Not sure if it will help or not.

Another change that might help is unrolling the loops but if the memory speed is the main bottle neck then that probably won't help either.

@broadblues

Something must be horribly broken, or optimization most be missing in the codec, maybe the active optimization only optimizes the playback, not the encoding part.

Throwing switches around can also result in a generic C code being picked instead of assembler optimized code.

@salass00


recording 1920x1080 at 10 FPS
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
Frames recorded: 126
Frames skipped: 7
Total: 133
Avg time spent in encoder per frame: 38230 microseconds

recording 1920x1080 at 10 FPS
altivec unit detected
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
Frames recorded: 152
Frames skipped: 7
Total: 159
Avg time spent in encoder per frame: 36281 microseconds

recording 1920x1080 at 10 FPS
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
Frames recorded: 163
Frames skipped: 23
Total: 186
Avg time spent in encoder per frame: 55538 microseconds

recording 1920x1080 at 10 FPS
altivec unit detected
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
Frames recorded: 119
Frames skipped: 17
Total: 136
Avg time spent in encoder per frame: 60992 microseconds


Two sets of tests the first with smaller workbench windows moibng arround the second with a filer window open and being dragged.

In the first altivec is faster n the second slower, though I tried to mimic each set of movements as close as I could.

I think this clearly shows that a more automtated test is needed.

Somewhere I have script for sketchblock that runs a demo if that still works since I made so meny updates I might run that and record the results... see if that gives a more predictable result.

@samo79

Quote:

I would rather not.

The three other codecs (if you discount CDXL) that SRec 1.36 supported were MJPG, XviD and RGB.

Let's look at them one by one:

RGB codec:
- Not as fast as one might think as frames need to be converted to a common RGB format (I chose BGR24).
- No delta compression between frames so video files get very large very quickly.

MJPG codec:
- Frames need to be converted to RGB24 for jpeg.library and then probably jpeg.library converts them to YUV before even doing any encoding. It is very slow.
- Very bad quality as it is a lossy codec and I chose the encoder setting that was most optimised for speed and even then it wasn't fast.
- No delta compression so it produces large frames even if there is little to no change in the graphics.

XviD codec:
- Frames have to be converted to YUV before encoding or xvidcore has to do it for you.
- It's a lossy codec and again in SRec 1.x I chose the setting which was supposed to give the best speed.

XviD codec might be worth considering but only if the RGB to YUV conversion could be done using the GPU. The others are just a waste of time.

It might also be possible to accelerate the ZMBV codec even further by using the COMPOSITE_Src_Xor_Dest operation in CompositeTags(). Depends if it's implemented by any of the h/w drivers or not.

@salass00

Using the version from post #148

1280x720 @10fps

altivec unit detected
Frames recorded: 101
Frames skipped: 0
Total: 101
Avg time spent in encoder per frame: 12847 microseconds

No Altivec
Frames recorded: 100
Frames skipped: 0
Total: 100
Avg time spent in encoder per frame: 11894 microseconds

@salass00

Quote:

I just had a look at a page about Porter/Duff compositing, which is what CompositeTags() implements, and it looks like it's not at all what I'm after which is just raw xor:ing the pixel data together.

Running the SB gradient text demo script


recording 1920x1080 at 10 FPS
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
new screen: 0x5abae090
dimensions: 1920x1080x24 pixfmt: 6
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
Frames recorded: 877
Frames skipped: 36
Total: 913
Avg time spent in encoder per frame: 35230 microseconds


recording 1920x1080 at 10 FPS
altivec unit detected
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
new screen: 0x5abae090
dimensions: 1920x1080x24 pixfmt: 6
new screen: 0x5d820388
dimensions: 1920x1080x24 pixfmt: 6
Frames recorded: 912
Frames skipped: 41
Total: 953
Avg time spent in encoder per frame: 38095 microseconds

manual start and stop so still not 1005 autmated but the bulk of the time the screens recorded would have been the same.

@broadblues

just for the hell of it here is the tested recording....

https://www.youtube.com/watch?v=fSPYxyXw5Kw&feature=youtu.be

The main difference between the non-altivec code and the altivec code is that the former handles four bytes at a time (that's two pixels for 16-bit and one pixel for 32-bit) while the latter handles 16 bytes at a time (eight pixels for 16-bit, four pixels for 32-bit).

The only reasons I can think of why altivec would be slower:

A) Altivec code will read and write some extra bytes at the end of the data if the byte length is not a multiple of 16.

Usually pixel widths are at least a multiple of eight so I don't see this making much difference.

B) Because the scheduler only saves and restores altivec registers if they are used there is some extra overhead when you begin using altivec.

Usually it should be more than compensated by the altivec code being more efficient though.

@broadblues

Nice video BTW and thanks for doing these benchmarks. It's very much appreciated .

I wonder if increasing the priority of the recording process would help with making the results more accurate and repeatable?

I've thought of adding a priority setting to the GUI but this could also be pretty dangerous as with a higher priority the possibility of locking up the OS by using a too high recording resolution/FPS would also increase.

@salass00
Quote:
You'll be able to do this once I get bitmap-as-texture implemented in Warp3D Nova.

Southern Islands cards have a Video Coding Engine (VCE). Ideally we'd use that for screen recording. However, that would require an updated RadeonHD.chip driver and an external library encoding library. We should get there eventually, but probably later rather than sooner.


Quote:
It's supported by both the Radeon & RadeonHD drivers. However, you've already discovered that it doesn't do what you need.

Hans

@Hans

As I wrote that I thought about possibility of using Warp3D Nova but then I remembered that using bitmaps as textures is not possible yet. Is this something that is hard to implement?

I've just submitted a couple of patches for xvidcore-1.3.4. One which makes it possible to build the shared object with ppc-amigaos target again(?) and another which is a replacement for the sched_yield() implementation I wrote before.

As the XviD encoder uses YV12 internally it should be possible to cut the amount of data needs to be transferred from VRAM to RAM in half.

@salass00
Quote:
It's not hard, but there are other items on the to-do list as well.

Hans