Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I'm pretty sure this is what PSXjin actually does:
Two different options (compile time) float or fixed, and two different output paths (run time) 15 or 24 bit (because the PSX backbuffer can be 15 bit or 24 bit)
floating point:
R1 = 1.40200 * Cr
G1 = -.3437 * Cb -.7143 * Cr
B1 = 1.77200 * Cb
fixed point:
R1 = 1.4013671875 * Cr
G1 = -0.3427734375 * Cb -0.7138671875 * Cr
B1 = 1.771484375 * Cb
15 bit:
R = (clip(Y + R1 + 128))>>3
G = (clip(Y + G1 + 128))>>3
B = (clip(Y + B1 + 128))>>3
24 bit:
R = clip(Y + R1 + 128)
G = clip(Y + G1 + 128)
B = clip(Y + B1 + 128)
According to wikipedia, http://en.wikipedia.org/wiki/YUV this is neither rec601 nor rec709, but that in it self doesn't mean it's wrong. Disregard, that page is for limited range.
The only goal of course is to produce exactly what the real MDEC hardware does; standards be damned.
Edit:
FFmpeg's MDEC decoder is here:
http://ffmpeg.org/doxygen/trunk/mdec_8c-source.html
It doesn't handle yuv->rgb internally, instead passing the YUV directly out of the decoder for swscale to handle.
It marks PIX_FMT_YUVJ420P, which is labeling the YUV as compliant to the JFIF standard. Assuming all of that is correct, that would be full range rec601 ("PC.601" in avisynth lingo).
The JFIF standard http://www.jpeg.org/public/jfif.pdf is exactly what psxjin does, but somehow that's wrong...
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
FFIX has a number of situations where it seamlessly switches between a standard backdrop and a cutscene. This is such a situation; two adjacent frames, one backdrop, one cutscene, both pulled out of psxjin in lossless RGB and presented to you as lossless x264 RGB:
http://www.mediafire.com/?m55c8mujfthk1tw
The colors are not the same. I don't know much about psx emulation, but textures for the 3d engine can be stored in a variety of RGB formats, where as the FMVs are stored in some special mdec format that was decompressed in hardware, and are YUV based.
It's possible that the devs of FFIX got it wrong, but it seems likely that they got it right: I would expect that the colors in these two frames should match. But they don't. This leads me to suspect the psxjin mdec decoder?
For your viewing pleasure, also as PNGs:
Edit: Apparently not the first time this sort of thing has been examined? http://smf.mameworld.info/?p=12
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
There was some talk on IRC a few days ago about the game name being incorrect and something along the lines of Quattro Adventure: Treasure Island Dizzy "100%" being more appropriate, along the same lines as how other instances of multiple games in one cart are labeled. Any resolution to that? I'd like to make official encodes, but they need to be correctly subtitled and labeled.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Looks like it hasn't been mentioned in this thread, but a huge spacesaver (and quality increaser, for the "original" transcode) is to pointresize to 8x8 and let youtube handle the aspect correction at playtime. More details here:
http://tasvideos.org/forum/viewtopic.php?p=303545#303545
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I don't think this got noticed for 5 days because not a lot of discussion typically goes on in the PubMov forum.
Hopefully more people will see this, and anyone that knew the guy can come forward and give a bit of insight to the family and friends.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Taking another look here at creating an alternate encode with certain transitions/loads removed.
Is there a way to identify these transitions automatically with Lua? Alternatively, is there someone who would be willing to identify these transitions manually? (I'd give you a framenumbered video, and you'd go through it writing down all the transition start and end times.)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Hophoolio wrote:
If it simply skips it in a run, then it's bad emulation and the run most likely won't be accepted.
What, skipping unskippable startup screens means the run won't be published? Without commenting on whether that "should" be done, I'd just like to say that there's clearly sufficient evidence to show: that isn't done.
http://tasvideos.org/Movies-GBA.html
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Lex wrote:
If you must use h264, you should give x264 RGB data because it now does the color conversion properly. You should be using bt470bg color matrix for everything to accurately reproduce colors when converting from RGB to YUV and back to RGB. YouTube will do the conversion to RGB properly with a full-range YUV 4:2:0 video using bt470bg color matrix. The quality should be lossless so you don't get YouTube transcoding lossy to lossy.
Youtube can NOT handle full range YUV input properly.
The same test clip as was used in the JWplayer test, uploaded to youtube. In this case the levels are wrong no matter what the flash acceleration level is, so youtube broke the levels in their transcode process.
http://www.youtube.com/watch?v=S0Eh2fseKec
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Lex wrote:
Isn't the obvious solution to just use mkv instead? :P Just because the original is mp4 doesn't mean the fixed one has to be, I think.
Anyway, yeah, that seems to have fixed it here. I tested with LAV Splitter and MPC-HC's internal mp4 splitter. Nice job!
How to use mkv though? Timecodes are required for the video track, and I'm sure they could be made from an NHML file, but I don't have a tool to do so.
It looks like there was some sort of muxing issue. I get various forms of broken depending on what mp4 splitter I use. I think I've corrected the problem, but because this is unfamiliar territory I'd appreciate someone else checking on their player before I update the central record.
22MiB:
http://www.mediafire.com/?kv7itwbk0avrbkw
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
It would be nice if anyone fixes [1920] NES Battletoads "warps, 2 players" by feos & MESHUGGAH in 11:04.72. I have configured my MPC to play 444 encodes correctly, but when I try to watch THIS encode, it shuts down and can't play even audio. Using LAV video output (other 444 encodes play fine).
It was said that the problem was in MP4Box.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
boct1584 wrote:
Warp wrote:
boct1584 wrote:
Game Genie et al. are third-party items. The disc tray of a console is not.
Neither is a crooked cartridge or a scratched game disc. Where do we put a line on hardware abuse?
I sort of see what you're getting at, although I can't think of any situation where cartridge-tilting or a damaged ROM would be a benefit. The first is a moot point too, though, since cartridge tilting is impossible to emulate. Don't know if there's any reliable way to create a damaged ROM, although the existence of the ROM tag implies there is.
Not sure why you think cartridge-tilting can't be emulated. Figure out which lines on the cartridge connector fall out first, and how that will change rom read results, and then emulate that. Might be tricky to get exact, but saying impossible without testing? As far as usefulness, tilting at the appropriate time is quite useful in F-ZERO X, and I'm sure there are others.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Warepire wrote:
Please add the game product code (example: SLUS-12542) so it will be easier for those that want to play back the movie in an emulator to find the correct dump.
psxjin movies include this information in the file (although there's no way to see disks other than the first)
slus01251
slus01295
slus01296
slus01297
of course, this is not sufficient; in some cases there are multiple revisions of a single CD with the same slus code, and this is one of those cases. All I can say is that it doesn't immediately desync on 1.1 (but I haven't run it all the way through)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Very useful work.
Re 756M: So the problem is that the two encodes are switched in expected order on the movie page? (What determines that order anyway?)
Re list2: I don't really see this as any problem at all. I know color theory is very complex and I'm glossing over quite a few things, but consider the following approximate quantities:
2k: number of colors genesis can represent
33k: number of colors GBA can represent
260k: number of colors NDS can represent
2.6M: number of colors 8 bit limited range YUV can represent
4.0M: number of colors 8 bit full range YUV can represent
17M: max number of colors any of our current emulators could theoretically represent (8 bit RGB)
170M: max number of colors 10 bit limited range YUV can represent
260M: max number of colors 10 bit full range YUV can represent
There should be minimal error using 10 bit limited range to represent anything that was originally RGB24.
(nb: for YUV spaces, i'm restricting to colors that are inside the RGB space)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Upon further testing on IRC, it was verified that this particular Adobe bug changes with your system (like many of the other Adobe bugs): If you're running an nVidia card under windows 7 that supports hardware decoding, and you use hardware decoding, you get limited range every time. On the other hand, if you use software decoding, the difference between limited and full range is understood and respected by the flash player.
Even with that new information, I'd still recommend limited range for _512kb encodes. It doesn't really hurt anything, and the browser always (?) gets it right.
I assume you used BizHawk for the encode. That being said, the size doesn't look entirely right. It's a bit smaller compared with fceux. I hope this won't be the new official guidline of encoding nes games.
It's 256x240 with no AR correction. If you're asking about AR correction, it wastes time and is not important enough for temp (submission) encodes. Publication quality encodes get AR correction.
If you're asking about framesize, it should be noted that the 240->224 crop is not at all consistent with our standard handling of other systems (especially PSX). But that has nothing in particular to do with BizHawk; both BizHawk and FCEUX can be set to crop or not crop, and it's always possible to crop in post-processing if that's what you want to do.
Edit: Apparently not the first time this sort of thing has been examined? http://smf.mameworld.info/?p=12