Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
I've received several complaints about the sudden large quantity of encodes appearing in some movies and a large number of encodes being embedded into submission threads. On the key principle that we should be annoying our viewers the least, I've decided to set down several principles with respect to the sudden prevalence of encodes, which I am posting here so as to ensure that everyone can be on the lookout for problems and so that our wide range of encoders can be aware of what not to do.
In publications, there should be at most one torrent/mirror at the native resolution of the emulator (sometimes called SD encoding), and at most one streaming link per site with as high quality a video stream as possible (generally involving our HD encoding techniques). Exceptions to this will be allowed in the case of camhacks/special HUDs/etc. upon request, whereupon there will be an additional encode of each of the above categories permitted.
Where there are subtle differences in encodes which do not otherwise affect visual quality (such as HQx vs. point encoding), if the author has a preference as to which encode should be used, that preference should be respected.
Videos should not be embedded in submission threads, with the exception of one video in the submission text itself. Links to videos are, of course, still permitted.
I have updated the appropriate wiki pages with the new guidelines. If you have any questions or concerns, please contact myself or adelikat.
EDIT: If you have problems with a specific submission or publication, please post in the discussion thread for that submission or publication.
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
I would prefer that whatever site provides the best visual quality and the least annoying viewing experience be linked to the exclusion of other streaming links, unless there is a strong demand (which I don't sense) for having multiple streaming sites available for any given movie.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
...I do make Flash compatible MP4s. Ironically, this decision is going to prevent me from making Flash compatible MP4s, because HQx encoding is now basically banned,
...I do make Flash compatible MP4s. Ironically, this decision is going to prevent me from making Flash compatible MP4s, because HQx encoding is now basically banned,
You can't make native resolution Flash comatible MP4s?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Brushy wrote:
Flygon wrote:
...I do make Flash compatible MP4s. Ironically, this decision is going to prevent me from making Flash compatible MP4s, because HQx encoding is now basically banned,
You can't make native resolution Flash comatible MP4s?
That requires extra processing time. With HQx MP4s, I had a good excuse to go without Deldup.
...I do make Flash compatible MP4s. Ironically, this decision is going to prevent me from making Flash compatible MP4s, because HQx encoding is now basically banned,
You can't make native resolution Flash comatible MP4s?
That requires extra processing time. With HQx MP4s, I had a good excuse to go without Deldup.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Brushy wrote:
Flygon wrote:
Brushy wrote:
Flygon wrote:
...I do make Flash compatible MP4s. Ironically, this decision is going to prevent me from making Flash compatible MP4s, because HQx encoding is now basically banned,
You can't make native resolution Flash comatible MP4s?
That requires extra processing time. With HQx MP4s, I had a good excuse to go without Deldup.
How much extra processing time?
Usually around as much as the Deldupped encode took (If not longer, for games with lots of duplicate frames). The problem is, is that I feel that it basically isn't worth it, from what I understand, people will just watch a given encode on YouTube anyway (Where, ironically, barring 60fps issues, the quality is higher than the SD encode when played at Original mode).
The rare exceptions will probably be when a game doesn't have room for dupe frames (Such as Metroid Prime Pinball).
Usually around as much as the Deldupped encode took (If not longer, for games with lots of duplicate frames). The problem is, is that I feel that it basically isn't worth it, from what I understand, people will just watch a given encode on YouTube anyway (Where, ironically, barring 60fps issues, the quality is higher than the SD encode when played at Original mode).
The rare exceptions will probably be when a game doesn't have room for dupe frames (Such as Metroid Prime Pinball).
Sorry to say, this is your personal opinion. Original mode, in my opinion, will never be higher quality than the original resolution downloadable encode. This is not only due to the missing frames, but the fact that the original mode encodes have been aspect ratio corrected by resize and are very blocky.
HQx encode incoming.
But criticaluser, I have a question for you.
Since now we can include a single YouTube stream in a publication, you'll have to choose one YouTube stream.
Both are in high definition.
Do you want Flygon's point-resized encode? It looks like these screenshots : 12
Or, do you want my HQx filtered encode? It looks like these screenshots : 12
I don't think that that should be up to the author. We should be consistent and link to the same type of encode in all the publications (of TASes where both types are available) after reaching a consensus about it. As for my opinion on the matter, I prefer point-resized encodes because they look more faithful to the original.
AzumaK wrote: I swear my 1 year old daughter's favorite TASVideo is your R4MI run :3
xxNKxx wrote: ok thanks handsome feos :D
Help improving TASVideos!
I don't think that that should be up to the author. We should be consistent and link to the same type of encode in all the publications (of TASes where both types are available) after reaching a consensus about it. As for my opinion on the matter, I prefer point-resized encodes because they look more faithful to the original.
sgrunt wrote:
Where there are subtle differences in encodes which do not otherwise affect visual quality (such as HQx vs. point encoding), if the author has a preference as to which encode should be used, that preference should be respected.
That's why I'm asking him this question. Of course, it wasn't absolutely necessary, but I like to leave him the choice.
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
Zeupar wrote:
I don't think that that should be up to the author.
My perception is that the average viewer doesn't particularly care what type of scaling is used, partly because they're not (always?) using the full resolution.
As yet, I haven't heard enough of an outcry to tell me otherwise.
I too have been a little confused about multiple encodes. If there are multiple encoding available prior to publication (which is odd when compared to how things were previously), how do I know which one of them became the official one when published? It's a bit hard to tell because inconsistent ways of calculating file size are used (powers of ten, not two). Then there are no hashes (SHA-1 etc.) provided, so it's impossible to tell if the downloaded file is okay (unless downloaded via Bittorrent). So here's my little request: provide hashes, so people can check integrity and separate different encodes easily. Hashes of all official encodes previously made should also be made available.
I also don't understand why more than one people start to encode the movies. Isn't that a waste of time and clock cycles? And why on earth does someone encoder provide Matroska and MP4 versions separately. That's waste of space. Matroska suffices in my opinion. I also think that archive.org links should be revealed only after publication. That way archive.org's bandwidth is potentially saved, because a few more people might download the encode via Bittorrent.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Because every encoder has a different opinion about how the subtitles and logo should be done. It may also have to do with the fact that people may prefer one method of encoding over the other.
For example, I prefer logos the style I've got mine in... obviously. I also prefer more flexible positions for subtitles that don't blast themselves into your face or obtrude moving player characters. Something that other encoders don't tend to take note of.
It's basically a matter of people preferring ones persons method of encoding over an others. In the end, the publisher has to choose what encode to use anyway. And I will admit that, when I was still publisher, I'd actually sometimes reencode movies because I disliked the fact that they were lossily encoded (I reencoded with some very tough lossless scripts), though, that childish behavior wore off by the end my carrier.
What would be very helpful is if people actually posted what sort of x264 scripts they used for specific encodes (Instead of having to download the MKV and open it up in Mediainfo). I've also taken note that certain encoders will lean towards looser scripts than other encoders (For example, in HD encoding, mmarks uses a very barebones script that doesn't actually bother to squeeze down the filesize, generally ending up 4-8 times the size of a similar lossless encode. I, however, used an SD encoding script on my HD encodes, which does seem a bit overkill, but it generally halves the overall MKV size of the encode compared to mmarks's encodes).
Basically, this is all because the encoders at TASVideos have huge egos and want things done their way, whatsoever. We've also taken to not using Archive.org anymore, unless it's confirmed for Publication. I've actually been considering getting my own personal file host to circumvent this, so that I can have a single reliable host that is usable for the published torrents, publications, and can also be used before the movie is actually published when the encode is posted in the thread. When combined with Archive.org, I view this as being a very robust way of increasing torrent speeds, due to the additional HTTP seeds. It also allows people to have multiple options for downloading the MKV files.
Just take note that my opinions do not represent the opinions of the site as a whole, and I'd like to keep it that way. I know full well that the administrative team will disagree strongly with some opinions that I have presented in this post.
I too have been a little confused about multiple encodes. If there are multiple encoding available prior to publication (which is odd when compared to how things were previously), how do I know which one of them became the official one when published? It's a bit hard to tell because inconsistent ways of calculating file size are used (powers of ten, not two). Then there are no hashes (SHA-1 etc.) provided, so it's impossible to tell if the downloaded file is okay (unless downloaded via Bittorrent). So here's my little request: provide hashes, so people can check integrity and separate different encodes easily. Hashes of all official encodes previously made should also be made available.
I also don't understand why more than one people start to encode the movies. Isn't that a waste of time and clock cycles? And why on earth does someone encoder provide Matroska and MP4 versions separately. That's waste of space. Matroska suffices in my opinion. I also think that archive.org links should be revealed only after publication. That way archive.org's bandwidth is potentially saved, because a few more people might download the encode via Bittorrent.
I make encodes even if there is one available, because I enjoy making encodes. While you could say it's a waste of CPU cycles, you could say that about anything else.
SHA-1 might be a good idea.
I provide both MP4 and MKV because people have different preferences on what they like. Just because you prefer MKV, does not mean other people do. In fact, it's actually a lot easier to convert from MP4 to MKV instead of the other way around.
Archive.org bandwidth will still be used from the torrent because we use webseeding.
What would be very helpful is if people actually posted what sort of x264 scripts they used for specific encodes (Instead of having to download the MKV and open it up in Mediainfo). I've also taken note that certain encoders will lean towards looser scripts than other encoders (For example, in HD encoding, mmarks uses a very barebones script that doesn't actually bother to squeeze down the filesize, generally ending up 4-8 times the size of a similar lossless encode. I, however, used an SD encoding script on my HD encodes, which does seem a bit overkill, but it generally halves the overall MKV size of the encode compared to mmarks's encodes).
By posting the scripts where? In the workbench thread? The workbench thread really isn't a place to claim encoding, explain what settings were used on your encode, etc. It's suppose to be about the TAS, not discussing about encoding methods and which is better or worse. On that note, there will probably be disagreements on which script is better/worse also. It be another argument. Lastly, just the line used to encode to H.264 does not show the whole picture. You would need to know the whole process to see what is wrong. Just like before, just cause x encode is smaller does not mean it is as good quality as y encode, even if it was encoded in lossless H.264. There could be filters added before encoded to H.264.
By the way, what does it matter on the size if it is being sent to YouTube anyway? Unless it hits the 20 GB file limit, who cares the file size as long as it is pretty much lossless or close to it. Everything will be reconverted anyway on YouTube.
I make encodes even if there is one available, because I enjoy making encodes. While you could say it's a waste of CPU cycles, you could say that about anything else.
SHA-1 might be a good idea.
I provide both MP4 and MKV because people have different preferences on what they like. Just because you prefer MKV, does not mean other people do. In fact, it's actually a lot easier to convert from MP4 to MKV instead of the other way around.
Archive.org bandwidth will still be used from the torrent because we use webseeding.
Please do whatever you wish with your CPU cycles. My point was that I don't see why more than one person should provide very similar encodes. If some those were encoded because of personal preference, fine. Otherwise it's useless.
I also didn't say that MP4 shouldn't be used at all. I say: use either Matroska or MP4, not both. It's not space efficient, and those who care can convert between the formats.
Anyway, the thing I want are hashes. Which ones should be used? My suggestion: SHA-256.
