Any altivec experts? (H.264 codec)

@Tuxedo

I think this is because the latest mplayer has newer FFMPEG, feanor changes will help, but I do not like to merge new FFMPEG every day, as its time consuming effort and I have better things to do, when Feanor thinks it's ready this is when I'm going to do it.

@LiveForIt

ok,
hope that ffmpeg modified will help!

@LiveForIt
That sounds good :)

@all

Just FYI, I just got myself a used imac G5 from a fellow developer, so that means faster development and shorter compile times, I had to wait a long time between compiles and tests everytime my chagnes triggered a full rebuild. So, the poor powerbook can rest soon :)

@feanor

Have fun with your new G5 :)

@feanor

Do you have any interest in, or have you tried AmigaOS4?

@ddni

oh, I definitely have an interest in AmigaOS (I grew up with it!), but sadly, I have little experience programming in it (last time I coded in AmigaOS was in 1996), and the past 20 years I've been programming exclusively for Linux OSes, and am an OSS advocate :)

@LiveForIt

I noticed that I could not play 720p (mp4 saved by my phone, or MOV saved by my action camera) at full speed even with your latest version and comp_yuv, but still the CPU was not at 100%, more like 80-90%. Is that because of vblank sync? Also tried comp_yuv2 which seemed a tiny bit faster (used like 95% CPU), but less smooth.

I wonder if feanor's improvements are giong to be able to fix these 720 clips...

Is there anyway to switch off vblank timing for maximum speed and 100% CPU usage? Care more about speed than tearing here... It's mostly about previewing action clips rather than watching a movie.

@Deniil

Quote:
What mplayer can play or not depends on video and how its encoded, mplayer has many setting to resync frames, or to degrade quality or force FPS playback, in case the videos where encoded wrong, there may be glitches or bugs in FFMPEG, the one FFPMPEG was taken from SVN and is probably not a stable build.

Quote:
That’s the average CPU load, but what is the peek CPU load.
Quote:
Waiting for vblank is wasted CPU cycles that’s way comp_yuv2 try to avoid it, but to do that I have to thread video, but that might create an switching overhead, the gain was bigger before AmigaOS4 graphics system got DMA support.
Quote:
The biggest bottleneck is the video decoding, so it should help, on the other hand, videos might be encoded wrong and there not play well, or that partial video codec might not well supported. Even with all this optimizations some video codecs might too demanding.

I am therefor not going to guaranty that all videos are going to play well.

The latest fixes might help, or they might slow things down, feanor improvements should helps because he is optimizing for speed, not adding anything to it besides better Altivec support.
Quote:
Disabling VSync won't give you 100% cpu usage and if it did, your USB and workbench will just freeze up, I have tried to play with task priority to get more speed out of it, but there is not much you can do, before the system critical tasks are affected by this.

We are only using 50% of that CPU PA6T right now, because the OS does not support SMP yet.

There are video decoding chips out there that can aid video playback, and source code is open, it’s a lot of work adapt to AmigaOS, I might be interested in doing something like that but I will not do it with out founding.

Mplayer has a disable vsync switch but the video outputs ignore it.

@LiveForIt
[QUOTE]There are video decoding chips out there that can aid video playback, and source code is open, it’s a lot of work adapt to AmigaOS, I might be interested in doing something like that but I will not do it with out founding[/QUOTE]

We can create a bounty for it but better after the third quarter this year.
Let's do the work on Mplayer first finished with the optimizations from feanor

@all

Just finished setting up the g5, basically, install debian jessie on it, had some problems as nouveau doesn't want to work with acceleration on, so had to disable it. I'll setup a dev environment with ffmpeg on it and start tests. This has the bonus that it's much closer to the performance of the A1000 cpu rather than my old G4.

@feanor
Nice

:)

@LiveForIt

Quote:

I would find it strange if these were both broken. They use unrelated but both use a fairly high bitrate though, 10-12Mbit/s. They are my main source of HD material, but waaay to slow to watch, even with comp_yuv

Quote:

Peek? I use the docky that shows a rainbow-colored graph over time. All previous versions of MPlayer shows 100% CPU when the video isn't playing at full speed. Maybe this version waits for the DMA transfer while the old versions were busy using the CPU to copy data to screen.

Quote:

Switching overhead is very small. The problem is that it seems to skip a lot of frames and be less smooth than comp_yuv, even if the overall play speed seems a little higher.

Quote:

Noo. Any program could use 100% CPU without affecting WB or USB if its priority is 0 or lower. All previous versions of MPlayer did that when a video was too heavy.

Is MPlayer able to use two cores at the moment, if AmigaOS suddenly got SMP tomorrow?

@Deniil

Quote:

I've come across phone recorded mp4s being exceptionally slow before and not just on my Amiga OS 4 machine but on my linux laptop, they obvious pump up the compression to the maximum.

@feanor
Can you give us an update?
As i understand, most work is done and there are only small things to improve.
LiveforIt will only start to create a new MPlayer when you say"The work is done"
How long do you need for the last improvements?

@tommysammy

hi, the imac g5 is not ready yet, it makes too much noise and it makes it unbearable to use, I still want to finish the AC3/AAC audio dsp functions and finetune it a bit, but in the meantime I want to send the patches upstream, I'll start doing that this weekend and Liveforit can get the source from upstream instead if he prefers. Sorry for the delay, the past couple of weeks have been very busy, the fact that the imac g5's fans make so much noise didn't make it any better. As soon as I started compiling stuff the thing sounded like I had an jet plane on my desk (it's one of the original 17" imacs).

@Deniil

Quote:

CPU dock is not that precise, I have seen it showing 0% CPU usage, when I was playing with task priorities.

Quote:

The answer is out there,

http://askubuntu.com/questions/91774/is-mplayer-multi-threaded

As you can see, you need to configure mplayer to use more than one thread, as I understand it there are not many codecs that support it. However, the one we are having problems with does; h264 do support threading.

If you setup mplayer to use more threads, today you see more sub threads in ranger, obviously, it will not be faster when all threads are scheduled on the same CPU core.

@feanor Where are the new uploads? I can`t find them.
Please finish your work, so that the work for a new MPlayer can be started.

@feanor
Huhu are you still there?
Can you give me an update of your work?