AMV Encoders - A/V Sync Test

This forum is for questions and discussion of all the aspects of handling your footage. If you have questions about capturing/ripping footage, AviSynth, or compression/encoding/converting, look here.

Re: AMV Encoders - A/V Sync Test

Postby BasharOfTheAges » Fri Aug 20, 2010 9:37 pm

I'll definitely try to make the demo @ AWA. :up:

I'm still stuck on contest DVDs for my contest and I would love a great digital solution... would actually love to have an HD projector even more.
Another Anime Convention AMV Contest Coordinator 2008-2014 & Head of the AAC Fan-works Theater - follow us on Twitter: https://twitter.com/#!/AACFanTheater
:sorcerer: :sorcerer: |RD: "Oh, Action!" (side-by-side) | |
User avatar
BasharOfTheAges
Just zis guy, you know?
 
Joined: 14 Sep 2004
Location: Merrimack, NH
Status: Extreeeeeeeeeme

Re: AMV Encoders - A/V Sync Test

Postby Mister Hatt » Sat Aug 21, 2010 5:09 am

This thread is overly long and too much of a pain to respond to everything. Quu, is there a chance you can get on IRC and we can chat about this properly?
Mister Hatt
 
Joined: 25 Dec 2007
Status: better than you

Re: AMV Encoders - A/V Sync Test

Postby Quu » Sat Aug 21, 2010 11:55 am

*edit*

I spoke to soon, it seams that mIRC lets me connect to two servers at once

the things you learn when you care
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Athena » Sun Aug 22, 2010 6:51 pm

Quu, please remember to include a random setting for video playlists.
Image
User avatar
Athena
I ♥ the 80's
 
Joined: 02 Mar 2001
Location: Japan
Status: Sad Girl on Mac

Re: AMV Encoders - A/V Sync Test

Postby Quu » Mon Aug 23, 2010 10:46 am

Kionon wrote:Quu, please remember to include a random setting for video playlists.

My target is convention use, so the playback modes I need to include is: Straight Playback, Random Playback, Play and Stop

BTW, as far as mplayer-uau goes, I am investigating it. I was able to download it at home... and it does intrigue me greatly, as it is a basic rendering engine, with the GUI being separate (and replaceable). There is not allot of documentation on what is different with the uau branch, and all I get talking to devs is that there was politics, and nobody talks about it.

So I have been using the mplayer main website for documentation. One major flaw against mplayer so far is the lack of hardware decoding... well, except for "vdpau: hardware acceleration for NVidia cards" which is a Linux API. VLC supports many more options for the hardware acceleration. It is possible that the documentation is out of sync, and mplayer supports more, or uau might itself support more... but I am investigating. (IE I am not dismissing what you said Mister Hatt, I take all feedback seriously)
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Quu » Mon Aug 23, 2010 2:51 pm

Mister Hatt wrote:This thread is overly long and too much of a pain to respond to everything. Quu, is there a chance you can get on IRC and we can chat about this properly?


On a side note, I actually prefer forum threads because they are a handy self documenting source of information. Not that I am unfamiliar with IRC (I wrote my first IRC application in '96 for dalnet... it was a dice bot for playing d&d and battletech on irc... and since it was a .exe, not a mIRC script, it was harder to hack), but I find that IRC is good for conversations, and quick answers, but the asynchronous nature of a forum lends itself to better information sharing. Others who have the same questions can come across forums as a start for their own answers.

That aside, I have more information about my testing regime
My playback target is
Code: Select all
%VLC% --sout=#transcode{vcodec=HFYU,acodec=s16l}:std{access=file,mux=ffmpeg{mux=avi},dst=%DEST%} %SAMPLE% vlc://quit

From talking to the VLC developers, and the code review I have done, this is representative of the decoded sample file as it is sent to the screen and the speakers. This will generate an AVI file that is HuffYUV 2.1.1 compatible video encoded and PCM uncompressed audio encoded.

Should I add any other player targets for the testing?

I am tempted to add mplayer-uau, since it is trivial to add it to the work flow, I can output to a YUV file, along with a PCM wav file, which is just as easy to compare as the AVI above. My only issue is that mplayer does not do hardware assisted decoding under windows and under linux on non nvidia cards. Can anybody who likes mplayer either point me to a good mplayer resource site, or defend the player?

also... I am thinking of making the testing be windows batch files. I can make a batch file generator, give it the tools to test, then it will generate the batch file... execute this batch file (piping the output to a log file) and to watch tv in the other room or something, leaving it to churn
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Athena » Mon Aug 23, 2010 9:33 pm

Well, we've been talking a lot on IRC, Quu, but here are my issues:

Even with the changes you suggest, using the 1.1.3 MacOSX build I get these issues on 720p and higher AMVs.

Dropped Frames OR Macroblocking (without one, I get the other). Changing to different types of Output doesn't help. I cannot post a screen cap, because it just happens too quickly intermittently to do so (or I would have provided one already to Cyrix). It is, however, definitely repeatable. I tried your buffer, and at first I thought it had worked, until I realised frames were being dropped.

I used several videos for these tests, but I think a good one to go off is Skittles 60@720p, because it is a popular video many people have. When I use it with the skip-filter all, A) picture is not as clean B) video slows behind music until you can finally recognise the sync is gone about a third of the way in.

Running the latest stable version of MPlayerOSXExtended (Rev13), these files, including Skittles, run cleanly, crisply, with no dropped frames and at 50% less CPU usage than VLC (40% vs 21%). This is no top of the line MacBook either. It is a MacBook White that is two years old. I have changed the ram and harddrive, but the processor and integrated video chipset are far from the best on the market. Another note, QT also runs it fine, as far as I can tell.

I can also do BluRay tests when I get home (at the office now), but I am sure the difference will only be more markedly clear, as I mentioned to you before.

I cannot speak to how this works on windows, but if you are seriously interested in crossplatform, then we need to ascertain why MPlayer provides an experience on MacOS X that VLC cannot match.
Image
User avatar
Athena
I ♥ the 80's
 
Joined: 02 Mar 2001
Location: Japan
Status: Sad Girl on Mac

Re: AMV Encoders - A/V Sync Test

Postby BasharOfTheAges » Mon Aug 23, 2010 9:35 pm

Kio - clearly, you're holding it wrong.
Another Anime Convention AMV Contest Coordinator 2008-2014 & Head of the AAC Fan-works Theater - follow us on Twitter: https://twitter.com/#!/AACFanTheater
:sorcerer: :sorcerer: |RD: "Oh, Action!" (side-by-side) | |
User avatar
BasharOfTheAges
Just zis guy, you know?
 
Joined: 14 Sep 2004
Location: Merrimack, NH
Status: Extreeeeeeeeeme

Re: AMV Encoders - A/V Sync Test

Postby Quu » Tue Aug 24, 2010 11:18 am

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.
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Quu » Tue Aug 24, 2010 11:27 am

Kionon wrote:I cannot speak to how this works on windows, but if you are seriously interested in crossplatform, then we need to ascertain why MPlayer provides an experience on MacOS X that VLC cannot match.



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.

my requirements for the player is
1) play all of the existing archive with out issues with out changing the archive (no re encodes)
2) be consistent in its playback performance and quality (if it plays a file once, it will do it the same a second time)
3) have no external dependencies nor hooks for external apps to over ride it (ie no DirectShow) by default
4) have a UI, or the ability to make a custom UI, that facilitates normal convention usage
5) playback 1080p H.264 video on an Acer Revo 3610 (my minimum hardware specs)
my wants
1) cross platform - Platform Priority Windows 7 > OSX > Linux
2) be open source (I like having the code to tinker if i want)
3) be as hardware flexible as possible (I used to use a hardware decoder, NS2K)
4) be as future proof as possible
5) allow for an HTTP interface, along with a direct GUI interface
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Athena » Tue Aug 24, 2010 5:24 pm

Quu wrote: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.

Quu wrote: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."
Image
User avatar
Athena
I ♥ the 80's
 
Joined: 02 Mar 2001
Location: Japan
Status: Sad Girl on Mac

Re: AMV Encoders - A/V Sync Test

Postby Mister Hatt » Wed Aug 25, 2010 4:02 am

Quu wrote: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
 
Joined: 25 Dec 2007
Status: better than you

Re: AMV Encoders - A/V Sync Test

Postby Mister Hatt » Wed Aug 25, 2010 4:07 am

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 ( ゚∀゚)アハハ八八ノヽノヽノヽノ \ / \/ \
Mister Hatt
 
Joined: 25 Dec 2007
Status: better than you

Re: AMV Encoders - A/V Sync Test

Postby Quu » Wed Aug 25, 2010 9:07 am

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.
Lead me not to temptation, for I have deadlines
User avatar
Quu
 
Joined: 26 Dec 2000
Location: Atlanta, GA

Re: AMV Encoders - A/V Sync Test

Postby Zarxrax » Wed Aug 25, 2010 10:43 am

Quu wrote: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.
User avatar
Zarxrax
 
Joined: 01 Apr 2001
Location: Concord, NC

PreviousNext

Return to Footage Help

Who is online

Users browsing this forum: No registered users and 1 guest