AmiWest News

@eliyahu

You did, but that was hours ago...we forgot already

@Raziel

Score is a personal project, and this past year has been spent mostly on other stuff. Even though Score is listed at AMiStore, it is not yet ready for sale. Hopefully it will get more attention, but right now my real life has been interfering with my programming time.

As far as the Radiance package.. I think that's all graphics based stuff, so I'm not sure Score applies there, though I did finally get the music scrolling towards the Clef. ;)

@Trixie
The synth included with FinalEdition is called "Timi" and it is derived from the Timidity package. Unlike the normal TImidity, Timi is real-time, allowing you to play it "live", which is necessary for use with CAMD. Timi is based on GUS patches, and does NOT support soundfonts at this time. Timi comes complete and pre-configures with a GUS soundfont, as well as TimiLaunch, which can load and unload Timi automatically when it is needed, and with "MidiPorts", a prefs editor that configures TimiLaunch as welll as some CAMD default settings.

@eliyahu
Thanks for the mention! I'm really quite happy that camd and the USB midi driver are now part of the OS install, this makes it easier to support MIDI programs, and makes support for modern (usb) midi devices truly "plug and".. wait.. let's just say the support is automatic. ;)

@eliyahu

Quote:

Thanks. I just watched the first three presentations from Saturday (Steven, Trevor and Andy) on the live stream. After that it was so late I felt I had to go to bed. I'll watch the others when/if videos are uploaded.

@zzd10h

Quote:

Pay close attention to the "VO" result:



Note the time taken by VO dropping from 295s (50.4% CPU time) to 21.9s (6.1% CPU time). That's a significant drop in the CPU time taken up by displaying the video frames. That's also a lot of extra processing power that can now be used for decoding more demanding video.

The difference in the "VC" (decoding) result is a bit strange, as I would have expected those to be almost the same. Maybe a few other things changed between versions, or maybe you're missing a small part of the video

Hans

Thank you for the explanations, Hans.

"maybe you're missing a small part of the video"
I have read the whole video but maybe that it was not the same video. It has to be confirmed by Severin, it's why I posted all the MPlayer output.

@Hans

Quote:

The Mplayer benchmark is not perfect, mplayer does not divide time 100% correct between VC and VO.

VideoOutput: Page_flip() is part of the benchmark numbers for VC. Small changes can effect VC numbers.

You should try with with a difference "comp_yuv" might do better then "comp_yuv2" that tries to do the page flip Async, so that video decoding does need to wait for frame to be drawn and the vsync (vsync is not enabled under benchmarks) .

Note benchmarks might not always tell the truth.

Quote:

A lot has changed between the two versions, the version they use is really old in every way, while the old MPlayer uses less CPU for Video decoding, the quality of the video and the video/audio sync is a lot better in the newer version when you barely have CPU power to decode the video.

Quote:

No don't think that's the problem.

The version they use is from 2010, the version your using is from Juni/July 2014, 3-4 years in between the mplayer version from MPlayer HQ.

@Hans

Quote:

When it comes to playback of MPEG, the new Mplayer takes advantage of DRI, or Direct Rendering, basically mplayer can render directly into the output buffer, instead of having to render into a decode buffer, this skips a additional memory transferee between decode buffer to the output buffer.

H.264 does not take advantage of DRI.

Quote:

Picasso96 Overlay output in mplayer does not support DRI, so it can be really interesting to see how this two compare now. when playing back mpeg video.

Quote:

Here is some more info that was missing in the presentation.

Andy got the the new mplayer in just few days before the show, so he might have missed some information about the new MPlayer.

* comp_yuv and comp_yuv2 uses YUV420p bitmaps (NEW)

Enabled mplayer to take advantage of "Radeon HD" yuv420p support, this removed the need to convert yuv420p video to (32bit) ARGB bitmap format be-fore displaying it.

* comp_yuv and comp_yuv2 support DRI (NEW)

I spent some time reading and investigating Xv (X-Windows video) video output in mplayer, to take advantage of DRI.

* MPlayer can now playback DVD's on X1000 at good speed (NEW)

AmigaOS4 does not read ahead blocks, this caused major slowdown in mplayer, so hacked in read ahead buffering into mplayer, to speed it up.

* Mplayer can playback file larger then 2Gb (NEW)

AmigaOS4 SDK does not support typedef off_t as 64bit, changed mplayer to workaround the problem.

* Mplayer can playback DVD's copied to hard-drives. (NEW)

I have spent some time fixing path problems and getting this working, the support for native files and directories is intended for Linux mount points, but a bit of work it also works on AmigaOS4.1 directories.

@zzd10h

Look the same to me, I used this download link filesize is 928,670,954

@Hans

Wow amazing news on the Radeon driver! I can see a lot of work has gone into both the new composite video support and the new graphics card support. The X1000 DMA support is very nice to see and was likely quite challenging to get working.

The difference on the VO for mplayer is huge.

For video playback now that most other bottlenecks have been addressed, the last challenge is the decode. Any future plans for leveraging the on-board decode capability of the HD cards?

Congratulations again - these recent changes are a huge leap forward.

@rwo

I can only imagine the pain involved with refactoring all of that code. It is one of those necessary evils of an evolving system architecture.

Congratulations on this major update to the graphics subsystem. It will certainly pay dividends many times over in the future.

@gregthecanuck

Thanks. It was a lot of work, although the DMA stuff was made easier by Costel's earlier work on DMA with the PA6T's ethernet (plus some extra example code by Lyle). Costel gave me the details that I needed to get to work quickly.

Quote:
Using the graphics card's on-board decoder is certainly something that I'd love to do. However, the code that AMD released for video decoding needs Gallium3D. So, that's another reason why Gallium3D is important.

Hans

@Hans

Thanks for the info.

One more question... can you shed any light on the future plans for Warp 3D? I know there were plans for Radeon HD drivers - are they still coming? Are there plans to update Warp 3D/MiniGL with more features?

@trixie

By the way, what has happened to the two graphics guys

They are mentioned here...
http://www.a-eon.biz/PDF/News_Release_Candi.pdf

@gregthecanuck

Quote:

I have no idea about future plans for Warp3D. All I can say is that the Warp3D driver for Radeon HD 5xxx/6xxx cards is still coming. AFAIK, Trevor didn't give any estimated completion date, but did say that it is being worked on. He may have given more details, but I only saw fragments of the AmiWest video stream.**

Hans


** I wouldn't mind hearing a summary of the AmigaOS 4.1 on WinUAE presentation, as I only saw a few minutes at the start.

@Hans

Thanks for Warp3D feedback.

Looking forward to seeing the recordings of the AmiWest sessions - thanks to all who put those together.

@Severin
yes, it is the same.

@Severin

Could your do the benchmark with the favorite cross platform video please .

http://downloads.dvdloc8.com/trailers ... st/prometheus-trailer.zip

@LyleHaze

Thank you for the updates

...and also thank you for the reminder on ScummVM, can't wait to try Timi out

@Spectre660

Not good results as it's H.264...

> mplayer -benchmark -quiet -nosound -fs "Prometheus - Trailer.mp4"

VIDEO: [H264] 1920x816 24bpp 23.976 fps 6828.3 kbps (833.5 kbyte/s)

BENCHMARKs: VC: 83.063s VO: 4.790s A: 0.000s Sys: 3.421s = 91.274s
BENCHMARK%: VC: 91.0043% VO: 5.2478% A: 0.0000% Sys: 3.7478% = 100.0000%
Internal COMP YUV FPS 18

As Liveforit says "H.264 does not take advantage of DRI."

@Severin

Thanks.
I think that it is always good to post benchmarks as it allows you to see improvements over time.