Post subject: Discussion about compatibility standards for TAS encodes
Senior Moderator
Joined: 8/4/2005
Posts: 5770
Location: Away
A point has been raised that TASVideos has forfeited too much compatibility in search for better quality/size ratio. On the other hand, encoding efficiency has always been our strong point compared to pretty much every other online video distributor on the net. Thus, a new sweet spot must be found, bearing the current software and hardware capabilities in mind. Discuss.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
As we have discussed on IRC, the average joe has no idea what an MKV is, and I can tell you, I used to be an average joe and on that 2007 summer day, I was drawn in by AVI magic. However, since new encoding techniques break AVIs, I suggest (Well, not exactly I, multiple people suggested it in IRC) that we just stick to MP4s, a format playable much more players by default and easily recognized. I am aware it doesn't support as much as MKV, but it does support everything that we require in a standard encode anyway.
Senior Moderator
Joined: 8/4/2005
Posts: 5770
Location: Away
As I was one of those who suggested MP4 instead of MKV, let me provide the rationale. MP4 advantages (vs. MKV): - much better hardware compatibility, even if not complying to standard profiles. MP4 disadvantages (vs. MKV): - no Vorbis support (negligible, as HE-AAC does the job at least as well) proven false; - marginally higher overhead (absolutely negligible) suggested false due to using -engage-nosimpleblocks in our MKVs; - no limited soft subtitle support (the largest disadvantage, but can be worked around by providing an MKV instead of or as an addition); - limited chapter support.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Former player
Joined: 2/19/2007
Posts: 424
Location: UK
My experience is that mkvs are gaining rapidly in popularity. Furthermore, from the discussion on IRC, it seems that MP4 is inferior as a container, lacking support for features that have already been used in published encodes. So I think we should continue using mkv. If people need the video in mp4 format in order to play it on specialized hardware, then converting from mkv to mp4 is a quick operation that doesn't require reencoding: ffmpeg -i video.mkv -vcodec copy -acodec copy video.mp4 Why not use mp4, and let people who want mkvs convert instead? Because mkv's features are a superset of mp4's. As for the codec settings, I think being pretty aggressive is ok. If the resulting file follows the standard, then players should be expected to be able to play it. Non-conforming files shouldn't be allowed, though.
Joined: 11/11/2006
Posts: 1235
Location: United Kingdom
moozooh wrote:
As I was one of those who suggested MP4 instead of MKV, let me provide the rationale. MP4 advantages (vs. MKV): - much better hardware compatibility, even if not complying to standard profiles. MP4 disadvantages (vs. MKV): - no Vorbis support (negligible, as HE-AAC does the job at least as well); - marginally higher overhead (absolutely negligible); - no soft subtitle streams (can be worked around by providing an MKV instead of or as an addition).
Actually Vorbis is supported in MP4 according to a container comparison on wikipedia. But yeah. My feelings on the matter are:
  • Use mp4, unless mkv is needed for more advanced functionality.
  • Use options in x264 that have been tried and tested.
  • Aim for maximum compatibility.
<adelikat> I am annoyed at my irc statements ending up in forums & sigs
Senior Moderator
Joined: 8/4/2005
Posts: 5770
Location: Away
The problem with standards support is that not every player or decoding filter follow them letter-by-letter. It's the same situation as with modern browsers and new HTML/CSS functions. There are pretty much no identical results among the different rendering engines. Being aggressive while conforming to standards is good, but it doesn't help people who don't wish to change their software player of choice only to play our videos. We would be better off using a proprietary codec designed specifically for emulator output if people could go out of their way so easily. It is a compromise, yes. Besides, somebody who didn't find a way to play MKV absolutely won't bother with commandline tools for conversion.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Publisher
Joined: 4/23/2009
Posts: 1283
moozooh wrote:
As I was one of those who suggested MP4 instead of MKV, let me provide the rationale. MP4 advantages (vs. MKV): - much better hardware compatibility, even if not complying to standard profiles. MP4 disadvantages (vs. MKV): - no Vorbis support (negligible, as HE-AAC does the job at least as well); - marginally higher overhead (absolutely negligible); - no soft subtitle streams (the largest disadvantage, but can be worked around by providing an MKV instead of or as an addition).
The marginally higher overhead is actually not there becuase of the fact we are foreced to use the no-simpleblock option in MKV. Due to that option, MP4s are actually smaller. There is soft-sub support in MP4.
amaurea wrote:
My experience is that mkvs are gaining rapidly in popularity. Furthermore, from the discussion on IRC, it seems that MP4 is inferior as a container, lacking support for features that have already been used in published encodes. So I think we should continue using mkv. If people need the video in mp4 format in order to play it on specialized hardware, then converting from mkv to mp4 is a quick operation that doesn't require reencoding: ffmpeg -i video.mkv -vcodec copy -acodec copy video.mp4 Why not use mp4, and let people who want mkvs convert instead? Because mkv's features are a superset of mp4's. As for the codec settings, I think being pretty aggressive is ok. If the resulting file follows the standard, then players should be expected to be able to play it. Non-conforming files shouldn't be allowed, though.
Since MKV is a superset, your above command does NOT always work. There would be conversion needed.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
One should also consider the pragmatic point of view: It cannot be denied that MKV is more of a "hacker" container format (somewhat similarly to OGM), while MP4 is a more "officially standardized" container format, so it's natural that multimedia players will tend to gravitate towards supporting the latter instead of the former. Are there any modern multimedia players which would not support MP4 out-of-the box? Even youtube seems to accept MP4 files directly (which might be one advantage of MP4 to consider).
Publisher
Joined: 4/23/2009
Posts: 1283
Warp wrote:
Even youtube seems to accept MP4 files directly (which might be one advantage of MP4 to consider).
Actually, YouTube supports both MP4 and MKV, and they both would be trans coded to a "YouTube" version of the file.
Joined: 7/2/2007
Posts: 3960
Speaking of YouTube, now that most (all?) videos can be watched online, is this as much of an issue as it used to be?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 11/11/2006
Posts: 1235
Location: United Kingdom
Derakon wrote:
Speaking of YouTube, now that most (all?) videos can be watched online, is this as much of an issue as it used to be?
Yes. However, I believe that now that we have all our runs available for online-viewing, the sole usage of the downloadable media file should be for a high quality encode (though not necessarily lossless).
<adelikat> I am annoyed at my irc statements ending up in forums & sigs
Senior Moderator
Joined: 8/4/2005
Posts: 5770
Location: Away
Raiscan wrote:
now that we have all our runs available for online-viewing, the sole usage of the downloadable media file should be for a high quality encode (though not necessarily lossless).
I very much agree.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
I can think of three possible reasons why someone would want to download the video file rather than watch in from a video sharing site: 1) To watch it full-screen at the highest possible quality. 2) To create a compilation, commentary or other type of derived work. 3) To collect all the videos locally (eg. burn them on a data DVD to share with friends or whatever). In all these cases maximum quality/size ratio is, indeed, the main desired feature.
Senior Moderator
Joined: 8/4/2005
Posts: 5770
Location: Away
Warp wrote:
I can think of three possible reasons why someone would want to download the video file rather than watch in from a video sharing site: 1) To watch it full-screen at the highest possible quality. 2) To create a compilation, commentary or other type of derived work. 3) To collect all the videos locally (eg. burn them on a data DVD to share with friends or whatever). In all these cases maximum quality/size ratio is, indeed, the main desired feature.
As well as some quality leeway for watching on large LCD screens (case #1) and possible transcoding (case #2).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
sgrunt
He/Him
Emulator Coder, Former player
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
I've always found watching the video file to have superior visual quality; this method also avoids possible visual buffering delays and (for some of the media sites) the need to cycle between multiple videos for sufficiently long runs. As such, the quality/size ratio remains of paramount importance in my view.
Joined: 7/2/2007
Posts: 3960
I don't deny that I'd much rather watch a high-quality encoding than a streamed video. My main point was simply that the streams make it possible for people to watch videos almost regardless of their software, which means that it is less of an issue if the encodes are too high-tech for some peoples' video players.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Honestly? I'd just abolish the ratio, stick to MP4s, and keep the bitrate as high as possible while not being redundant (So, rather then Sonic 1 having a bitrate of 370 that I used and in turn, made some rather noticeable compression artifacts, publish it with a bitrate of 700 and be on the line of 'lossless' looking and still not have an excessively high bitrate). I think another thing to consider is the audio side of things. I would really much rather encode my audio with a higher bitrate (Instead of 32kbps for NES games, make it at least 64kbps), granted, it blows up the size quite a bit, but it does have an easily hearable difference. I think Aktan is setting the perfect standard for encodes, reasonably small (Usually inside a 6:1 ratio) while maintaining 'perfect' quality... not that his compatibility is ideal sometimes.
Joined: 11/11/2006
Posts: 1235
Location: United Kingdom
How about just going for a set crf? Does a certain crf have the same quality for every encode?
Flygon wrote:
I think Aktan is setting the perfect standard for encodes, reasonably small (Usually inside a 6:1 ratio) while maintaining 'perfect' quality... not that his compatibility is ideal sometimes.
So you're saying that the perfect standard is to have a less-than-ideal compatibility?
<adelikat> I am annoyed at my irc statements ending up in forums & sigs
Publisher
Joined: 4/23/2009
Posts: 1283
Raiscan wrote:
How about just going for a set crf? Does a certain crf have the same quality for every encode?
It sure does for the most part. All my encodes are crf 20. Correction: All my lossy encodes are crf 20.
Raiscan wrote:
So you're saying that the perfect standard is to have a less-than-ideal compatibility?
Just wondering, what features are incompatible? I'm guessing the ref=16, but on what players? Do you mean DXVA compatibility? There is a limit how compatible one should be. Do you want it iPod compatible (=p)?
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Raiscan wrote:
So you're saying that the perfect standard is to have a less-than-ideal compatibility?
Flygon wrote:
... not that his compatibility is ideal sometimes.
Senior Moderator
Joined: 8/4/2005
Posts: 5770
Location: Away
Aktan wrote:
There is a limit how compatible one should be, do you want it iPod compatible (=p)?
This is a good point. I guess if we aimed at compatibility first I would suggest using H.264 level 5.1 or possibly even lower. But since we aren't, I would define an encode as compatible if it works with recent versions of decoders and popular players: - ffdshow; - VLC; - MPlayer; - Quicktime with Perian. Additionally, we could also check the compatibility with other decoders, such as: - Quicktime without Perian; - CoreAVC 2.0 (including CoreAVC for Linux); - DiAVC; - DivX AVC decoder; - some video editing software that doesn't use DirectShow?
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Publisher
Joined: 4/23/2009
Posts: 1283
I must point out the downside to making it more compatible. Either quality suffers or file size suffers. I don't think quality is an option (at least in my opinion), so then file sizes may be slightly bigger. Is this okay?
Senior Moderator
Joined: 8/4/2005
Posts: 5770
Location: Away
How bigger are you expecting an average file to be in that case? I'd say less than 5–10%, which is very much acceptable.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Publisher
Joined: 4/23/2009
Posts: 1283
moozooh wrote:
How bigger are you expecting an average file to be in that case? I'd say less than 5–10%, which is very much acceptable.
I'm actually unsure at the moment since I kind of need to know how compatible we need to be in order to figure out what options I can't use or lower. Also the % (obviously) really depends on the content, so 1 encode might be 5% bigger, and the next might be 20% bigger (as an example).
Banned User, Former player
Joined: 3/10/2004
Posts: 7698
Location: Finland
Flygon wrote:
(So, rather then Sonic 1 having a bitrate of 370 that I used and in turn, made some rather noticeable compression artifacts, publish it with a bitrate of 700 and be on the line of 'lossless' looking and still not have an excessively high bitrate).
That suggestions makes a lot of sense now that we are offering the streamed versions of all new videos. In the past, before the video streaming, encoding was always a struggle between keeping the image quality as high as possible while minimizing file size, because the video file was the only way to watch the run for people who don't have (or don't want to hassle with) the proper emulator and roms. However, now that the size issue isn't such a huge problem anymore, the downloadable video files should aim more at the quality than the size (of course this should still be as optimal as possible, but quality tradeoffs can now be lessened, especially for runs which would require a higher bitrate).