Posted: 8/22/2009 8:52 PM
(Edited: 8/23/2009 12:16 AM)
Post subject: Recent encodings and VLC
Quote
Derakon
Joined: 7/2/2007
Posts: 3960
The most recent version of VLC I can use is 0.9.10; more recent versions only work on MacOS 10.5 on up. With 0.9.10, some movies like the latest Rockman 2 look pretty crappy any time there's a major screen transition -- for example, the first five-ten seconds of a level tend to look like garbage, and the Skull Fortress shots are basically stills (no animated tracks of Megaman's path through the level show up). I know if I could use a more recent version of VLC it'd look better, but that would require installing a new OS on my computer, and from my use of 10.5 I haven't seen any compelling reason to upgrade other than that I'd be able to use a newer version of VLC. I assume that the new MKVs that are being generated here have a better quality-size ratio than the old versions that older versions of VLC are able to digest. Does anyone know exactly how good these savings are? Or is there some other benefit that I'm missing that outweighs the value of supporting people with outdated players? Incidentally, I looked at the MPlayer site, and their recommended installation method is to download the source from SVN and compile it yourself. Their OSX binary is listed as "outdated". These two facts just don't give me any confidence that I'd enjoy using the program. Edit: fixed a typo.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Posted: 8/22/2009 9:00 PM
Post subject: Re: Recent encodings and VLC
Quote
ShinyDoofy
Former player
Joined: 12/5/2007
Posts: 716
Derakon wrote:
I assume that the new MKVs that are being generated here have a better quality-size ratio than the old versions that older versions of VLC are able to digest. Does anyone know exactly how good these savings are? Or is there some other benefit that I'm missing that outweighs the value of supporting people with outdated players?
The main difference would be that my recent encodes drop duplicate frames and use bframes at the same time; which wasn't possible for me prior to using new encoding measures. You might find some recent builds of mplayer over here.
Posted: 8/22/2009 9:49 PM
Quote
Derakon
Joined: 7/2/2007
Posts: 3960
Can you translate that into layman, please? :) I'll give those builds a shot.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Posted: 8/23/2009 12:12 AM
Quote
Desty
Joined: 12/3/2008
Posts: 15
Location: Dublin
I've had some encodes cause major problems on VLC and mplayer, although most are okay. When neither of them work properly (e.g. the MGS WIP encodes), Realplayer (bizarrely enough) seems to work well.
Posted: 8/23/2009 12:26 AM
Quote
ShinyDoofy
Former player
Joined: 12/5/2007
Posts: 716
Derakon wrote:
Can you translate that into layman, please? :)
I do my encodes with mencoder, the encoder program of mplayer. To improve the quality of a movie, there are two ways of doing so: 1) Drop duplicate frames. By this, mencoder takes at every frame and compares it to the one before. If they are exactly the same (i.e. not one pixel changed), the second one is dropped. Those frames aren't given to the x264 encoder. Because the latter still encodes at the set bitrate (say 200kbps) and parts of the frames are just left out, the video bitrate drops a bit (10% dupe frames -> 10% lower bitrate = 180kbps). This is done because dropping frames saves more space than the codec saving the info that there's no difference in two (or more) consecutive frames. 2) Use so-called bframes: without getting too technical, they also save bitrate (that can then be used on other that need a higher one) and give a good picture. Combining these two wasn't possible to me because mencoder screwed up if you used them both at the same time. Using some AVISynth scripts I managed to get it running. As far as I can tell, it's still all standard compliant (thanks to mkv!), but Johannes may have some more input on that issue.
Posted: 8/25/2009 5:52 AM
Quote
Dacicus
Editor, Player (67)
Joined: 6/22/2005
Posts: 1042
ShinyDoofy wrote:
1) Drop duplicate frames. By this, mencoder takes at every frame and compares it to the one before. If they are exactly the same (i.e. not one pixel changed), the second one is dropped.
How does this affect the final length of the encoded movie? Does it end up being shorter because it has fewer frames? If so, isn't it less accurate to do this than to leave in those duplicate frames that were actually present in the TAS?
Current Projects: TAS: Wizards & Warriors III.
Posted: 8/25/2009 6:00 AM
Quote
Derakon
Joined: 7/2/2007
Posts: 3960
Presumably, whenever you remove a duplicated frame, you extend the length of time that the previous frame is displayed. In other words, you take a movie that looks like "AAAABBBCDEFFGGGHHH" and turn it into "A---B--CDEF-G--H--".
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Posted: 8/25/2009 12:43 PM
Quote
LagDotCom
Joined: 3/7/2006
Posts: 720
Location: UK
Derakon is right. Basically it just instructs the decoder to do nothing for that particular frame, i.e. 'leave it how it is'.
Voted NO for NO reason
Posted: 8/25/2009 2:23 PM
Quote
Raiscan
Joined: 11/11/2006
Posts: 1235
Location: United Kingdom
Can someone remind me why we favour small filesize over compatibility these days? I thought the point of the movie files was to allow as many people to watch the movies as possible.
<adelikat> I am annoyed at my irc statements ending up in forums & sigs
Posted: 8/25/2009 9:28 PM
Quote
Derakon
Joined: 7/2/2007
Posts: 3960
Okay, I gave the precompiled binaries a shot, and they immediately failed with this error:
dyld: Library not loaded: /usr/X11/lib/libfontconfig.1.dylib
  Referenced from: /Users/chriswei/apps/MPlayer OSX.app/Contents/Resources/External_Binaries/mplayer.app/Contents/MacOS/mplayer
  Reason: image not found
2009-08-25 14:20:26.039 MPlayer OSX[17879] Abnormal playback error. mplayer returned error code: 5
I fixed that by symlinking /usr/X11R6 to /usr/X11, but then it complained about the version of libfreetype I had (wanted version 10.0.0 but I'm apparently providing version 6.3.0). I'm not about to deal with dynamically-linked library version mismatches. This kind of stuff shouldn't be necessary to watch a video file. I'm rapidly coming to the conclusion that the cost/benefit analysis for these files is getting problematic. As long as there's an app you can download that plays the file and that just works, I don't have a problem. But it looks like there isn't such a solution for anyone running MacOS X 10.4 or earlier. Much respect to our encoders, but could you please consider keeping to formats that are easier for our viewers to watch? For example, the Madou Monogatari TAS plays back flawlessly in my outdated VLC.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Posted: 8/27/2009 8:38 AM
Quote
EEssentia
Joined: 4/13/2009
Posts: 431
Raiscan wrote:
Can someone remind me why we favour small filesize over compatibility these days? I thought the point of the movie files was to allow as many people to watch the movies as possible.
But it is. All people have to do is download a proper player. Not making use of the latest and greatest is a crime :D
Posted: 8/27/2009 9:30 AM
Quote
Raiscan
Joined: 11/11/2006
Posts: 1235
Location: United Kingdom
EEssentia wrote:
Raiscan wrote:
Can someone remind me why we favour small filesize over compatibility these days? I thought the point of the movie files was to allow as many people to watch the movies as possible.
But it is. All people have to do is download a proper player. Not making use of the latest and greatest is a crime :D
Name 3 players that people can use that are easy to install all 3 major OS'es (Win,Lin,Mac). So far I've seen people having problems with both mplayer and VLC, and all of these optimisations are killing uploading to Viddler and that other one I forget what it's called.
<adelikat> I am annoyed at my irc statements ending up in forums & sigs
Posted: 8/27/2009 9:43 AM
Quote
EEssentia
Joined: 4/13/2009
Posts: 431
For Windows that I use, Zoom Player. Allows you to play virtually any file directly after install (it's dshow based). Linux and Mac, I have no idea. I have used neither.
Posted: 8/27/2009 9:45 AM
Quote
andymac
Experienced player (618)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
That's something I don't get. Optimisations are killing uploading to viddler? for one that doesn't make any sense. If you are reffering to the cpu hogging properties of that website that is. viddler reencodes the videos before they end up on the site, so the cpu usage would not be related to it's original encoding. Another thing, why would b-frames make uploading to youtube a problem? Barring the fact that it's obviously not compatable, If I were uploading something to youtube, I would get the original input file and do an encode at 10,000 kbps of standard h.264 and MP3 audio with the container being avi and upload that to youtube. Two passes are not needed if you are dealing with those kind of bitrates. So basically, why is it so important that the movie file encoded by TASVideos is the one uploaded to video hosting websites. Isn't it possible to upload a different file for the purposes of compatability? I thought that would be the obvious solution.
Measure once. Cut twice.
Posted: 8/27/2009 9:59 AM
Quote
GuidMorrow
Joined: 4/30/2008
Posts: 89
Location: Northeast Kansas USA, GMT -06:00
I did see a few garbage frames even with the new version of VLC player in Windows. This MKV container format just isn't working right! You just can't cut corners and expect things to work as they should.
Posted: 8/27/2009 10:26 AM
Quote
EEssentia
Joined: 4/13/2009
Posts: 431
What publication might that be? I see nothing wrong in all encodes I've watched.
Posted: 8/27/2009 4:41 PM
Quote
Derakon
Joined: 7/2/2007
Posts: 3960
GuidMorrow wrote:
I did see a few garbage frames even with the new version of VLC player in Windows. This MKV container format just isn't working right! You just can't cut corners and expect things to work as they should.
You're making a nasty assumption here, that our encoders are cutting corners. From all I've seen, they aren't; they're trying very hard to get the best quality/size ratio they possibly can. Now, there's a question of if they're too much on the bleeding edge of movie player technology, but that's entirely different from the amount of effort they're making. You're also laying blame on the container format that rightfully belongs on the video stream inside the container. Assuming you could get the same video/sound streams into an AVI container, it'd also break. (At least, from my knowledge of how these things work, which is admittedly limited)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Posted: 8/27/2009 4:48 PM
Quote
EEssentia
Joined: 4/13/2009
Posts: 431
Another point that I've though of is: no matter what format you use, there will always be people who complain or can't get it to work. That's whether it's avi or mkv. Admittedly, you have come here to complain, but I'm pretty sure that there are lots of people, both on the avi and mkv side, who had problems but didn't come here to complain. Another thought is this: Because mkv natively supports all this stuff, no hacks are required, and that should--theoretically anyway--mean less work for developers on trying to implement nasty hacks, which no one likes. Simply implement the format properly and--boom!--everything works, instead of having to implement hacks. Everyone is happy.
Posted: 8/27/2009 5:29 PM
Quote
OmnipotentEntity
He/Him
Player (36)
Joined: 9/11/2004
Posts: 2624
I haven't had any issues with mplayer under linux on the latest encodings.
Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.
Posted: 8/29/2009 12:45 PM
Quote
Aktan
Publisher
Joined: 4/23/2009
Posts: 1283
Using the latest VLC version 1.0.1 in Windows, the lastest posted Rockman 2 encode still has problems. Interesting enough, I also tried VLC on another encode I had with dup drops but no h.264 b-frames, and that seem to work fine. I guess a workaround is to not encode with b-frames? I'd assume the savings from dup drop would be higher than b-frames. Personally, I've have had no problems with any encode on this site, but I'm using MPC+ffdshow
Posted: 8/29/2009 1:51 PM
Quote
ShinyDoofy
Former player
Joined: 12/5/2007
Posts: 716
I'm using VLC 1.1.0-git Yellow Bastard from a few weeks ago. No problem there for me on Linux.