@thread

To prevent:
Would you support a company that decided to support Amiga? from going too far off-topic:

New thread for A/V postings. I put it in general so MorphOS, AROS, etc. will hopefully post any thoughts and/or comparisons. General A/V comments welcome as well.

#6

Last edited by number6 on 23-Jul-2012 at 09:18 PM.
Last edited by number6 on 23-Jul-2012 at 09:18 PM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

What is a/v?

@thread

Real world testing in irc.
Will report the results so you can compare with what has been said in the thread linked in post #1.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@wawa

Quote:

What is a/v?

No offence, just not a question I would expect from you,

A/V=audio/video, playback tests on the Amiga on all systems with different codecs/sizes.

Last edited by sundown on 23-Jul-2012 at 10:14 PM.

_________________
Hate tends to make you look stupid...

@thread

I truly understand that people who want faster h/w and don't want to do format conversions will have no interest. This is for those interested.

I have a Micro running OS4 and the Summer Reloaded version of MPlayer using Deniil715's GUI. Other than trying this on an SE, I don't see how you could go any slower.

In the past and due acknowledged h/w flaws in this series of computers, people with Micros would claim that even after overlay was implemented for the onboard Radeon 7000, video played slowly and out of sync with audio. (generalization)

Maximum resolutions reported were 640x480 and sometimes the occasional DVD resolution 720x480. Many people mentioned -that- was a stress point right there.
Others saw it as close but reported audio out of sync or "looks almost ok", which isn't much of a test.

In irc we started with a source and converted it to different formats and resolutions.

Timed with a stopwatch and using verbose feedback on framedrop:

720x480 encoded Mjpeg played back in real time with no audio loss. Audio ended with video playback.

So, we stepped it up a notch.

848x480 encoded Mjpeg played back in real time with no audio loss. Audio ended with video playback.

Remember this is on my weak machine. The intention is to test with Sam as well. Secondly, since DVPlayer plays these files, we'll look for noticeable differences with that program as well.

What will this prove?

(1)Codec DOES make a difference, not just horizontal and vertical resolution.

(2)It shows that one can make an A/V file that plays back on most all Amiga models and at a decent resolution. That might help people who want other Amigans to see their work on an Amiga at true speed and an acceptable resolution.

btw-I just saw 720p in what I would call "motion", which it could never dream of doing before.

If anyone would like access to the test files, we can provide that.
I think we're taking requests too Heh.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@thread

Our source was excellent as it provided challenges both for quality and file size. I'll summarize the results for my machine and post results for XE and X1000 later.

Repeating about my system:
Quote:

I have a Micro running OS4 and the Summer Reloaded version of MPlayer using Deniil715's GUI. Other than trying this on an SE, I don't see how you could go any slower.

720x480 encoded Mjpeg played back in real time with no audio loss. Audio ended with video playback.

848x480 encoded Mjpeg played back in real time with no audio loss. Audio ended with video playback.

720P encoded Mjpeg played back at 71% of realtime. Audio ended before video ended.

1080P encoded Mjpeg played back at 27% of realtime. Audio ended even earlier before video ended.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@thread

XE G4 Altivec results using AmigaOS4.1 update 4 with MUI-MPlayer:

No sense mentioning the resolutions other than HD, since even the Micro passed those tests.

720P encoded Mjpeg played back in real time with no audio loss. Audio ended with video playback.

1080P encoded Mjpeg played back at 1/2 speed. Audio ended before video ended.

Note:Summer reloaded version of MPlayer will not produce these results either with or without altivec. Avoid it on this model.

#6

Last edited by number6 on 24-Jul-2012 at 09:01 PM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

Quote:

Note:Summer reloaded version of MPlayer will not produce these results either with or without altivec. Avoid it on this model.

Well... I just noticed that I have installed MPlayer Summer Reloaded on my XE G4. I never used it. Maybe that is why.

I just replaced it with MUI-MPlayer. Somehow I missed the release back in November. Thanks to you I have it now.

I am about to print out the two ReadMe files because I hate to read them on the screen.

_________________
Moxee
AmigaOne X1000
AmigaOne XE G4
I'd agree with you, but then we'd both be wrong.

@number6

Mjpeg? Are you sure about that? How can that be faster than for example mpeg2?

Mjpeg are usually only created by cheap action cameras or early still cameras and I would say it's quit demading due to the high bitrate. All HD material is typically h.264 which is even more very demanding.

I have recoded some 720p(h.264) material into 852x480@6Mbps plain mpeg4 videos which play fine, but with a high CPU (85-90%) load on my XE/G4. Mpeg2 uses less CPU but needs more bits to produce the same quality.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

Quote:

Mjpeg? Are you sure about that?

Mplayer seems to think so.

Quote:

Selected video codec: [ffmjpeg] vfm: ffmpeg (FFmpeg MJPEG)

Quote:

I have recoded some 720p(h.264) material into 852x480@6Mbps plain mpeg4 videos which play fine

On what? XE with Altivec?

Remember what I'm using by comparison. ^

#6

Last edited by number6 on 25-Jul-2012 at 02:38 AM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

I think I'll try to dig up some results from my old dreamcast. Not a lot of horsepower in cycles (200mhz and a graphic processor), but used to watch videos all the time on CD. I'd say it had about the same quality as an old VHS tape though.

Plaz

@Plaz

Most likely there is HW MPEG decoder there some where in the Dreamcast.
Similarly 14Mhz AmigaCD32 could play video CDs when FMV module was connected.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Deniil715

"high bitrate" for mjpeg is typically on the order of tens of megabytes per second, nothing a modern harddrive can't cope with. Decoding it is trivial.

Whereas for mpeg2 there's all sorts of weird calculations that take time unless it can be offloaded to a graphics card.

But I still think it's rather silly trying to find a codec that uses less CPU when hardly anyone will be able to benefit from using it. People won't be downloading mjpeg HD movies from the internet. People MIGHT download mpeg2. And are very likely to download h.264.

What we need is decoding HARDWARE, not easier codecs.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@KimmoK & Plaz

Video CD is 352x288, 25Hz (alternatively 352x240, 29.97Hz in the US and Japan).

Compare that to 1280x720, 50Hz. 18 times more pixels per second. So while VCD could be decoded on a 200MHz Dreamcast it would take a 3.6GHz Dreamcast to do the same with a 720p BluRay.

It helps to do the math

1920*1080, 50p would bring us up to 41 times more pixels. Got any 8.2GHz Dreamcasts I can buy for my home cinema?

It's likely the Dreamcast didn't require the whole CPU just for VCD decoding, since it was only an mpeg1. h.264 uses a lot more CPU per pixel, and a modern CPU can typically cope with that in software at 1080p just fine. All the lower-end processors used in laptops need some help, though. Which typically comes from the GPU.

So roll on Hans and his new driver, we absolutely NEED him to make progress on the drivers

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

"It helps to do the math"

Trying to cope with single core to do everything is futile.
Yes, better GPU utilization will bring big help, as well as multicore support.

Other alternative would be old school use of some custom assymmetric processing to offload CPU. Like simple CPU card on fast bus to do conversion on the fly.
But.... even though it might be considered lame, use some stand alone blue ray player for video enjoyment. And true extreme HW geek would rip the player apart and build video player module/card for miggy from it....

Last edited by KimmoK on 25-Jul-2012 at 07:45 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK

I agree we need to get into multiprocessing. Mplayer supports it, I tested it on my laptop yesterday, benchmarking playback of a video file. With threads=2 top claims mplayer was using 180% CPU. Not sure which mechanism it uses for this, but hopefully it's portable.

I wanted to test va-api for my intel GMA4500HD chipset but no luck so far.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

and btw, not so long ago we had a discussion here about what would be the point of supporting multiprocessing. The fact that MPlayer can utilize 90% of the capacity of a dual-core system for decoding (not to mention encoding) a single movie should be good enough reason already.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@Deniil715

Quote:

with a high CPU (85-90%) load on my XE/G4

How does one know what the current CPU load is in an AmigaOne? Is there a tool that accurately shows this with OS4.1?

Scott

_________________
AmigaOne uA1-c 512M RAM - Only Amiga Makes It Possible!
Check my blog AmigaOne Computing

@scabit

There is a CPU meter in docky, commodities but I don’t know if precise.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@thread

AmigaOne X1000 results using AmigaOS4.1 update 4 with MUI-MPlayer:

Again no sense mentioning the resolutions other than HD, since even the Micro passed those tests.

720P encoded Mjpeg played back in real time with no audio loss. Audio ended with video playback.

Note:Summer reloaded version of MPlayer will not produce these results. Avoid it on this model as well.

Still looking at 1080P results based on multiple factors.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*