AMV Encoders - A/V Sync Test

[Kionon]

This is what I understand about mplayer, and some questions.

I am not qualified to answer these questions. If if I went out researching the information, you would find it yourself just as quickly, and understand more of it.

I do know that MPlayerOSXExtended does indeed allow you to control other screens how you want, but have not tested it in any detail.

As a note... cross platform does not mean it has to work on a mac mini... just that is has to work on a mac, maybe a more powerful one. The hardware reqs don't have to be identical across platforms. Would i like it to work on a mini... sure.

Mac Minis have served as media centers for years. The original Minis (I own one, or rather, I just sold it, and need to ship it), couldn't do much, but they weren't designed to do much. With the newer Intel Minis, this just isn't any longer the case. My mac mini from two years ago is significantly more powerful than your target system. The brand new Mac Minis are even being discussed by Texas Media Systems for a video editing package to sell into prosumers in Austin (I even said I'd buy one if they did it).

If conventions do have Macs, and I grant you it might be a smaller con using as much personal equipment as possible, they are more likely to be using Mac Minis or MacBooks with similar hardware profiles (my MacBook White and my Mac Mini Intel have identical hardware profiles, just one is a laptop. This was an intentional purchase, so I have exactly the same performance on both machines, and can switch projects between home and work with no issue, and given that the cost was relatively easy to handle for the improvement in performance from my previous system), than they would be to have maxed out MacBook Pros or Mac Pros. Then there are iMacs, but again, unless it is personal equipment, I don't see serious iMac usage. And in the event that someone does use a higher end desktop Mac, if you have already used the Mac Mini/MacBook White as your Mac target specs, then of course, things will play correctly on Macs of higher specs.

I know your priority is Windows 7, but I would be a poor advocate for the OS X editing community if I didn't push for this. After all, even if no convention would ever use a Mac for a VAT type solution, we are still in need of the ability to test our videos to make sure they will play correctly using that software "if we want to see what it will look like at the convention."

[Mister Hatt]

This is what I understand about mplayer, and some questions

There is two major "versions" of mplayer (there are two OSX forks... but meh), mplayer, and mplayer-uau. MPlayer comes from the SVN while -uau comes from the GIT. the -uau respository was formed when there was a political fight between some of the mplayer devs, and uau is a fork with out being a fork. Why?

Why is uau considered better? what patches does it have that the SVN does not? is the opposite true, does SVN have stuff the git version does not? Not a vauge "it has more patches"... but WHY is it better, why should I use uau over the svn version... give details.

How difficult is it to build mplayer from SVN or from GIT. looking at things, the git version requires either a second git for the build tools, or using Kov's fork of the fork that combines the two? As they don't make version releases, I will have to probably make builds of it if I decide to use it.

how self contained is mplayer? From what I can tell, very... it is a single executable, not counting the GUI. How much control do I have over the playback details, can I specify a specific sound device to output to, if I am on a computer with 3 sound devices? how easy is it to control the video playback, can I have it take over monitor #2 and make sure to be on top and not display any mouse or anything? ie totally control that monitor?

Does it support hardware acceleration under windows and or mac? I know under linux it supports it with nvidia chips only. I want to be able to play 1080p H.264 video on an Acer Aspire Revo 3610 (Atom 330 and ION graphics card). The revo is my "lowest target"... ie I want players to be able to be on a revo or better.

OK, to start with, MPlayer main is NOT SVN only. You can get source tarballs AS WELL AS GIT FOR IT. As I understand it, the majority of mplayer devs don't like the way uau writes things, so a lot of his features were left out and ignored. There is a separate repository for uau's own stuff built on top of regular mplayer. The single biggest advantages I can think of are pause behavior and even moreso, uau's matroska demuxer. It is on par with Haali's and at times is even better. Standard mplayer does NOT support matroska chapters/editions in full, only a small subset of the chapter system. Other differences are the improved mkv splitter is default rather than lavf, code cleanup, and better VDPAU for GPU decoding on nvidia cards.

MPlayer works by for the most part linking other libraries, but it has got it's own stuff, especially for demuxing. Examples of libraries it links to are libavformat, libavcodec, and libass; the three main libs that VLC requires for playing back subtitled video, although a good mplayer build is significantly newer on those codebases than VLC. Because of it's reliance on libav*, mplayer links to ffmpeg or ffmpeg-mt depending on your setup. ffmpeg-mt is maintained by astrange. It lets you have multithreaded decoding and whatnot. The other main lib used mostly for soft-subtitle formats like SSA V4+ is libass, maintained by zgreg. Stock mplayer DOES use these libraries but not always the most up to date versions. Unfortunately, compiling all of these is find on a linux system with split packages but lacking a single binary makes it kind of a pain on windows.

A few months ago, uau, astrange, zgreg, and elenril got together and setup the mplayer-build git repository. It's a GIT repo with a bunch of buildscripts to make it easy to make single large packages for debian and whatever other distributions without having to have a heap of dependancies for the major libraries. It's quite easy to use, just git clone, ./init && ./enable-mt, then either make or dpkg-buildpackage. It has scripts to update individual repositories too, and to update the scripts themselves just run a git pull. This is still not ideal for windows. Kovensky has a split of this repo for some patches that make it run more friendly in windows though. With that repo, you can make single fat binaries without dynamic linking that can be used on a windows system without a hitch. It is easier to build from these repositories than it is to build from SVN. Note that Kov's repo is not a fork, rather a branch which just patches the main build repo to be friendlier in windows. Similarly, uau's repo is built on top of the main SVN trunk and isn't a fork as such.

As far as control over outputs, that can be done on the options you pass to mplayer on CLI/slave, or otherwise you can set them in the mplayer.conf and codecs.conf. Every single mplayer option can be controlled from the CLI interface. For example, sound output is handled by the ao flag. The main sound output driver in windows is dsound, which has a device option. You would need to know which device number is which but the syntax is, you would just do mplayer derp.aac -ao dshound:device=x where x is the number for your device. You can see what devices you have by using the -v option when playing something. As for video output, your options are directx and direct3d. DirectX seems to have an acceleration thing but I think that is for rendering rather than decoding. As far as how it takes over a monitor, that's a job for your window manager to handle and isn't really mplayer's problem. Just set your WM to force mplayer onto that monitor at all times I guess.

As I understand it, there IS work being done on GPU decoding in windows and osx but VAAPI isn't really ready yet. The only matured GPU decoder is VDPAU which requires an 8400GS or newer and Linux, along with a recent nvidia driver. To be honest though, a well tweaked and multithreaded mplayer build can handle almost anything. There is a dirty little secret of GPU decoding that nobody tells you. If a PC is new enough to have a card capable of it, then the CPU is also capable. It just depends on your software. GPU decoding for example on my c2d is fine on AVC at high resolutions; I don't know where the misconception that higher res is harder to decode comes from but a misconception it is. The thing that makes it hard to decode is algorithm complexity and more importantly, bitrate distribution. There are times when the CPU/RAM just can't handle the amount of data being thrown at it, in which case the encoder should be checking their vbv settings. Most decoding problems would be solved even at higher resolution on crappier hardware if conventions just enforced stricter rules. Force your entrants to use high@4.1 or something and there should be no problem, although I suggest that profile/level arbitrarily without actually looking to see what the limits are seeing as I don't recall them off the top of my head.

Finally, to make sure everything plays well, simply have a well written codecs.conf file. If you have optimum settings for the types of content you expect to play, then you will have no problems playing them. It's just a matter of knowing what vc/ac/demuxer works best. Poke me if you have any more questions I guess.

[Mister Hatt]

I totally left this out but that laptop is a horrible way to play things back because it has an ION. I think I told you on IRC but the ION uses a VP3 and I think maybe a VP4 chip now. Both these chips suck at decoding video. You need an older VP2 chip if you expect to have decent GPU decoding. If you say you NEED GPU decoding, then you're doing it wrong. Use ffmpeg-mt in mplayer, or just lazymodo and DivX7 with CCCP. If it still doesn't work, your encoder is an idiot or you need framedropping, possibly both. You have to realise that although you would LIKE it to play on a shoddy laptop like that, the ION was never designed to be capable of decoding 1080p at a relevant bitrate and the ATOM certainly wasn't. Don't make hardware do things it wasn't supposed to and then complain when it doesn't work. Also Acer suck and you're dumb for buying their shit ( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼

[Quu]

Mister Hatt, that is not a laptop, it is a small compact desktop... perfect for taking to conventions when traveling light is required. I have two of them actually. One is running XBMC in my living room, running Ubuntu plugged into my TV. It is able to decode all of the 1080p videos I throw at it just fine, this obviously uses VDPAU with Linux. The second is my reference box which is running Windows, and with VLC, which uses DxVA2, I am able to playback 1080p H.264 content with no issues.

It is true that VDPAU is superior to VA API, in fact, for NVidia drivers, VDPAU is simply the backend for the exposed VA API. It does not mean that VA API does not work. It does not mean VxDA2 does not work. You act like if things are not perfect, then it is rubbish... I live in a world of compromises, and I pick and choose which ones to make. And, you also have gotten the ION wrong, the ION video card line was designed from the outset to assist in video decoding, as it is targeted to the low end computers which would not have the CPU power to handle it.

Can you provide references and proof that VP2 is superior to VP3 and VP4. I have been talking to developers who have been coding VA API, VDPAU, and DxVA2, and they recommend an VP4 decoder. For ATI, they are a little more wonky, as they only have UVD 2.2 decoders, but they think a UVD2 is fine for most H.264 decoding. Also, in my own research, i have found that the VP4 api provides more tools and hooks for the developer to use vs. VP2, and the hardware tends to be more powerful, and more capable.

Here are some facts based on using Big Buck Bunny 1080p H.264 as the test file (give me another test file if you don't like it)
1) Revo 3610 with XBMC (linux) plays it fine
2) Revo 3610 with VLC DxVA2 (win7) plays it fine (fails if I use software decoding)
3) Revo 3610 with mplayer (win7) chokes and fails, give me CPU warning
4) Dev Computer (i7-920, GTX 285, vista) with mplayer plays it fine
5) Dev Computer with VLC plays it fine (uses more CPU than mplayer if not suing GPU)

I also have a 720p music video in the archive (H.264, high amount of movement) and got the same results... though the revo and mplayer "almost" was able to play it, it only failed occasionally

This tells me that the software player in mplayer is better than the software player in VLC, but VLC combined with the ION graphics card is able to do play the video. To play this video on the Revo 3610 I "NEED" GPU decoding. This is a fact, this is not in debate. The fact that VLC utilizes this acceleration is also a fact.

I have a hardware target, the Acer Revo 3610... this is not open to debate. I have a solution that has worked in all of my testing, VLC. If you want to help me, then either provide relevant examples that break this solution, or help me replace VLC with mplayer, and still support the same test cases that VLC provided.

And please stop with the insults. It is hard to take you seriously when half the time you are inflammatory or just down right trollish.

[Zarxrax]

I live in a world of compromises, and I pick and choose which ones to make.

As such, I also think its a little outrageous to expect a little system like you are talking about to handle the playback of 1080p amvs at conventions. It would be fine for SD resolution videos, maybe even 720p, as long as they are using less bitrate than the 1080p version.
I would recommend that if you are seriously going to be running conventions off of that box, then you downscale all the videos prior to playing them. (hey its not that bad, we've been dealing with 480p only up until now)
Also have you taken into consideration 60fps videos? Some editors are editing at 60fps (though its rare), and I'm sure their bitrate requirements at 1080p would kill that system.

[mirkosp]

Also have you taken into consideration 60fps videos? Some editors are editing at 60fps (though its rare), and I'm sure their bitrate requirements at 1080p would kill that system.

If he does require level 4.1, then 1080p60 is not possible, as that would be level 4.2 at least.
720p60 is perfectly fine at level 4.1 though.

[Zarxrax]

By the way, here's a good way to make a solid test clip.
- Take one of Nostromo's 720p 60fps videos
- Upscale to 1080p
- Sharpen
- Add grain

And there you have it. This will be a killer clip, a good test of the limits of your hardware.

[Quu]

By the way, here's a good way to make a solid test clip.
- Take one of Nostromo's 720p 60fps videos
- Upscale to 1080p
- Sharpen
- Add grain

And there you have it. This will be a killer clip, a good test of the limits of your hardware.

that actually is a very good idea... I need to get a hold of Nostromo to ask permission.

and the reason I have been using that little box, is that so far it has passed all of my testing with VLC (and XBMC with linux) with 1080p... i don't have any 1080p60 videos.

but, you are right... I might want to focus on 720p for right now. Most projectors at conventions won't be 1080p... they actually tend to be XGA projectors doing 1024x768 at the most... which is kind of sad.

[mirkosp]

By the way, here's a good way to make a solid test clip.
- Take one of Nostromo's 720p 60fps videos
- Upscale to 1080p
- Sharpen
- Add grain

And there you have it. This will be a killer clip, a good test of the limits of your hardware.

Code: Select all

FFVideoSource("Nostromo_-_Running_Man_720p@60_H.264.mp4")
spline36resize(1920,1080)
strength=2
mergeluma(converttorgb32.GeneralConvolution(0, "   0   -1   0   -1    5  -1    0   -1   0 ", 1, true).converttoyv12.fft3dfilter(bw=6, bh=6, ow=3, oh=3, plane=0, bt=1, sigma=strength).fft3dfilter(bw=216, bh=216, ow=108, oh=108, plane=0, bt=1, sigma=strength/8, sigma2=strength/4, sigma3=strength/2, sigma4=strength))
awarpsharp2(depth=8)
dehalo_alpha(brightstr=0.8,darkstr=0.2)
addgrainc(hcorr=0.2,vcorr=0.2,var=4.5)

Hey, it will be sharp and grainy for sure.

[Quu]

I sent a PM to Nostromo asking permission to use one of the clips.

I am going to focus, right now, on encoders... i have two synthetic videos, and hopefully at least one non synthetic (maybe more... anybody have example videos that think would be a good test for encoders, sync, and playback?) that i can use

I am going to test MPEG-2 Video MP@HL and MPEG-4 AVC H.264 High/4.2 and MPEG-4 AVC High10/4.2 (I see that x264 supports the 10 bit high profile). I am going to test with flac audio, mpeg-2/3 audio, and aac audio... max settings for each one. Finally I am going to use MPEG-2 PS/TS, MPEG-4 Part 15 (.mp4), and Matroska decoding

As far as known issues...
A/V Sync - some encoders don't agree with decoders for a/v sync, same with muxers vs demuxers
A/V Drift - some encoders add audio drift as the the file is player, so I will test late in the file for this (5 minutes+)
seeking - We do not use seek at conventions, so I will not be testing for proper seeking
chapters/editions - this is not a concern for amv playback at conventions, will not be tested
blocking - if the decoders is able to properly decode the video, will look for differences in the expected and decoded video

I would like to also test audio quality and video quality, but i don't have an objective way to do that... psnr or asnr can be gamed