For publications we currently offer two main types of downloadable encodes:
MP4 Compatibility uses YUV color encoding, limited levels and 4:2:0 chroma.
MKV Modern HQ uses YUV color encoding, full levels and 4:4:4 chroma.
With all the changes made to encoders and players alike over the recent years, Modern HQ just doesn't feel very "modern" any more. x264 has supported RGB for a long time, so my question is: why are we using 4:4:4 as our HQ option when we could be offering RGB? It would further separate the two encode types and we could still keep all the other (non-colorspace) settings identical and so the file size should theoretically be similar. The only difference is we'd be removing a needless RGB>YUV conversion from the process.
To be safe, I did a number of tests to see how x264 worked when handling lossless content in RGB. The resulting files (when decoded to RGB24) were identical to the same encodes produced with the Lagarith codec in RGB. Interestingly, I used
this run as my test and the resulting video stream (with no audio data) was 30.4mb. Combining that with FLAC audio leads to a final file size of 64.5mb (although this had no logo or subtitles), which gave me a second thought: Lossless RGB.
I'd love to see a third (optional, see below) encode option on publications for Lossless RGB. If I were not making encodes myself,
it's the one I'd download. Internet connections are getting faster and hard drive capacities larger. Digital retailers are selling music in lossless (and sometimes 24-bit) formats. Everything seems to be evolving in a very quality-driven manner and so I think we should too. Excluding detail changes (such as branch name) or errors, having Lossless RGB should prevent the need for any future encode updates and give people the best downloadable watching experience possible.
Regarding it being optional: I'd love to see this introduced as a standard for every publication on the site- but it's a huge task. Not every game is going to be able to get a lossless encode right away (3D games for instance, would be harder), and not everyone is going to be able to upload large files (Metroid was small, but longer encodes and more complex games could easily get large very fast). From an encoding perspective, it's another thing that's going to take time, although the good news is that the first pass (frame decimation) data generated for the Modern HQ can be re-used for the lossless encode to save time. Having said that, it would be nice to see some publications slowly pop up with "Lossless MKV" or some similar term as a third download option. Even if they're few in number to begin with, it would have to start somewhere.
I feel like at the very least we should have an RGB encode, whether it's new adjustment to the Modern HQ encode or a new lossless option.
Randomly seeking through the non-dedupped script showed no issues. Seeking to the first non-logo frame of the dedupped script showed the garbage frame at first, but after seeking elsewhere in the clip (and then seeking back), the frame was gone. I tried reopening the script and the problem was still resolved. I rebooted the PC and opened the script again and as expected, the problem was back (to which seeking again solved the issue).
The solution seems to have been to uninstall ffdshow (which is out of date anyway) and instead install LAV filters.* I'd need someone with a clean system to try encounter the error and solve it this way to be sure this is the correct solution, though on the test PC the script produces the expected output in any test situation I've tried, including the above situations where the output was previously broken.
My main concern here is that the correct decoding of h264 in AVI looks to vary depending on installed codecs or system. Whilst this is true for most formats, there's usually some form of error message or some obvious sign that something's wrong; this isn't the case here. If you were to preview the footage in Virtualdub via AVS, the dump would look fine. If the problem did occur, seeking past it for a few frames and going back would fix it. If there were doubts and the script was reloaded to check, it would be fixed on reload. This could be problematic as it has the potential to go unnoticed in some situations.
* I initially installed LAV filters without removing ffdshow (as that is the codec setup on my main PC), but this didn't solve the issue and so the safest bet is to remove ffdshow altogether.
Note: There were a number of edits originally appended to the end to this post, which lead to the point being worded in a confusing and unnecessary way. All of the edits all have therefore been re-worded and added in to the original post.