Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
500kbit or lower would be workable most likely.
One thing I saw mentioned on doom9 would be to do something like this:
Encode on slow-firstpass mode, with a desired CRF (say, 20 or so), and save the output file.
If the output file from the first pass is bigger than your limit, do the second pass (you have the stats file) in bitrate limit mode.
This is slow for videos that go over the limit, but it can be completely unattended and it allows for graphically simple videos to save space while limiting the extent that poisonous videos can waste space.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Lex wrote:
The levels are right.
Black in the lagarith clip: RGB (2,2,2)
Black in the h264 clip after converting back to RGB24: RGB (18,18,18)
Edit: Didn't inspect the colormatrix, so no opinion either way on that.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Lil_Gecko wrote:
I have never used memory.register and I know this doesn't answer your question but why not simply use
while true do
memory.writeshort (0x00097ba0, 68);
emu.frameadvance();
end;
?
That sets the value once per frame to what I want. If that value gets changed and then read out at a different point during the frame, then it can still be wrong. What you posted is enough for many purposes though.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Santiago wrote:
So x264 itself is opening the avs file?
Yeah thats how everybody does it, no?
No, but I don't think that's a problem here (and it is a perfectly legitimate way to do it.)
I loaded both your test files up, examined them closely. I also made an avisynth script that loaded the lagarith one and converted it through YV12 with various chroma resampling methods, so I would know exactly what the 4:2:0 artifacts would look like in this situation. I saw no evidence of any chroma subsampling having been done at any point in the h264 clip.
Note the lack of any red bleed on the plumber's cap in the h264 encode:
http://img851.imageshack.us/img851/1239/showme.png
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Santiago wrote:
With x264 10-bit.exe I use a .bat.
So x264 itself is opening the avs file?
Hmm... could you maybe provide a short example clip? Both encoded to some RGB lossless (say, camstudio or lagarith) and encoded through x264?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Santiago wrote:
natt wrote:
Then x264 outputted 4:4:4 (and if it was a 10 bit encode, 10 bit). What are you checking with? MediaInfo is always a good place to start. MadVR's extra info display (CTRL+J) can tell you some useful statistics about a video as well.
I'm checking it with my eyes and seeing obvious YV12 garbage, I do not care what mediainfo or anything says it is.
That's useful information, but it's not the same as what you said before. A problem in the workflow can cause data to pass through 4:2:0 through an inappropriate conversion, even if it ends up as 4:4:4.
How are you passing the avs script to x264?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Santiago wrote:
Ilari wrote:
Does the Avisynth script contain those ConvertToYV24/ConvertToYV12 lines?
No.
Ilari wrote:
And the option is '--output-csp i444'.
Yes I know that and I did add it.
Then x264 outputted 4:4:4 (and if it was a 10 bit encode, 10 bit). What are you checking with? MediaInfo is always a good place to start. MadVR's extra info display (CTRL+J) can tell you some useful statistics about a video as well.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
creaothceann wrote:
What would be interesting is a "fake" codec that converts everything to 32-bit (or 16-bit, if the end result is the same) and passes it over to ZMBV.
Tried it, two ways:
1) Actually change zmbv to support 24 bit directly
Failed because of some weird compilation issue, some sort of C++ crash, never figured it out. The code was right (the core work was done by Bisqwit a while back), it was just a problem with my compiling environment?
2) Construct a "proxy codec" that sits inbetween AVIFIL32 and the ZMBV implementation and converts 24->32 (which can be completely lossless).
Worked, but output files were ungodly huge, never figured out why.
I'm not the best coder around =/
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Ilari wrote:
IIRC, there was a bug in AVIsynth that caused FFV1 to be decoded as YV12 unless you overrode this (some AVIsource option I don't remember offhand).
Now that you say that, I know what it is. The problem is that VFW gives no direct way of knowing what the "compressed" colorspace is, other than what the decompressor supports as output. (IE there's no way to support multiple colorspaces as decompression output while marking one as "preferred"). Because of the way it's constructed, the ffdshow vfw FFV1 decompressor supports YV12 output unless you change one of those 15 billion settings it has. And AviSynth checks for YUV output possibilities from the decompressor first (this is actually a good idea for certain other codecs, but not helpful here).
The preferred way to fix this would be:
AviSource ("foo.avi", pixel_type="RGB24")
# if that doesn't work
AviSource ("foo.avi", pixel_type="RGB32")
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I've been tasked with this encode, and I'm a bit confused about the ending. I got the run to sync and what I see in my emulator matches http://www.youtube.com/watch?v=Wgv2BWJ8oP0 but after the movie ends you're just dropped back at the map screen. Is there no "the end" with credits for this submission? That would match http://tasvideos.org/1479M.html but I just want to be sure before I encode.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
Funny thing that some codecs may provide output of different size that become the same after regular x264 encoding. Happened for me with CamStudio and MLC.
That's completely expected, no? All of these codecs are exactly lossless, so that what they give avisynth will be exactly the same in every case. How they store it internally (which is their own problem) though, is what determines their filesizes.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Emulator output is (usually) 8 bit per channel RGB. 10 bit encodes are 10 bit per channel (1024 shades). In this case the colorspace is also different; it's YUV. Why 10 bit YUV compresses better than 8 bit YUV in x264 is complex and I don't understand it. The big difference you're probably seeing is the lack of chroma subsampling, which is also used in our 10 bit encodes.
There are a variety of ways to manage your video workflow. What I would recommend is to capture lossless RGB from the emulator, import lossless RGB to avisynth, and do the entire avisynth process in lossless RGB. Then send RGB (using avs2pipemod or similar) to x264 (10 bit build) and have it convert to YUV 4:4:4 10 bit internally.
This post has some RGB lossless codecs in it:
http://tasvideos.org/forum/viewtopic.php?t=12390
As far as your particular FFV1 question, I'm not familiar with it. I can only say that these sorts of problems (colorspace issues with import) are why planning out your workflow is difficult.
At the moment, x264 RGB lossless is not recommended. The only way to get it as output from most emulators under windows at a moment is to use a custom codec tool I made, and you don't want to worry about that (it's rather horrid). There's also no convenient way I know of to import it into avisynth. (Both FFMS2 and ffdshow-tryouts give a colorspace problem).
These are the intermediate codecs I use:
Camstudio - kind of slow, VFW codec is 32 bit only. Supported directly by libav* if that's important to you.
Lagarith - much faster than Camstudio, rather large files. Null frames gives compression increase in deduppable games (eg: gens prince of persia), but chokes up ffmpeg command line (works fine in vfw+avs).
MLC - slow as balls, smaller than either Camstudio or Lagarith. Gives exceptions in Vdub when trying to repeatedly reload a script, pain in the ass. Codec of choice for getting longer Gens dumps under 2GB (as Gens always screws up the 2GB split).
ZMBV - no 24 bit input option, only 32 or 16, so mostly only for psxjin. Can be slow or fast depending; small.
Uncompressed - I actually did this once for the fun. Can be slower than Lagarith because of i/o bound (especially if you try to rapidly seek the avs script in vdub). Monstrously huge files.
LCL zlib - available from commandline ffmpeg, and can be loaded with FFMS2. Speed&performance somewhere around lagarith. Doesn't work with standard tools.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
http://www.mediafire.com/?3ta3ctwa5x1ey1j
This is the original movie with the suggested alternate memory card in slot one. It does sync (lucky!) with 1.0 disks against the 2.02 "svn0" build. It's not appropriate for publication though, as the insertion of other memory cards was a hex hackjob, and might not even load on future versions of psxjin.
And in any case, this memory card has no provenance either. It just suggests that making a verification run is worth the effort, because a verification run *might* create a memory card that would sync with the movie.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
theenglishman wrote:
Someone was asking earlier for a cleaner memory card. Well here's one that includes only VR data and one extra savefile with unlockables on it, and I have confirmed that it syncs with the movie.
http://www.4shared.com/file/KDYd7ic-/Mcd001.html
I have checked with the PSXjin source code, and as I suspected, when you run a movie for playback that has embedded memory cards (as this one does), the "regular" memory cards are completely ignored, and only the ones in the movie are used. Per our previous discussion on IRC, this means you haven't actually verified that the movie syncs with any other memory cards.
Can anyone give me checksums of the MGS CDs?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I see. Well, the lossless can certainly be nice; h264 GBR lossless can be rather moderate filesizes while looking pretty good. But I don't get the 2x (excepting actual higher-res recording on systems like N64).
Give me any lossless original source, and a 2x encode you've made of it, and I bet you I can beat the image quality at the same filesize with a 1x encode.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
There is a point there. I think that if you want good quality for reasonable filesizes, you should get the downloadable hi10. If you want ultimate convenience, watch the 512 or youtube at moderate resolutions. If you want an encode that takes more bandwidth to download, more processing power to display, yet is guaranteed to be second rate because of the 30fps limit, you watch youtube "original".
That being said, I still do originals. Why not? It's just processing time, doesn't really take effort. The people who actually do the TASes put in way more effort than me. I'm encoding an original right now -- do you see me sweating?
Edit: Before you ask "why doesn't X have an original, you encoded it", I don't do originals when youtube won't let me. Can't do the impossible, after all.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
EEssentia wrote:
But how long has it been since MeGUI was updated last?
The last commit to the official SVN is two days ago. The last binary build available for download was posted 10 days ago. (Is there some reason you couldn't find this out yourself?)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Here's a possible fix for my problem:
http://forum.doom9.org/showthread.php?p=1559483#post1559483
I don't have time right now to send it through its paces though. And of course it shouldn't be used in a lossless scenario until it's been MD5 verified and whatnots.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Guide is old, syntax has changed.
That being said, even with the fixed syntax, I don't think that's right.
I just did a local test with JWPlayer, using a fullrange test video I have. The video in question is YUV 8 bit 4:2:0, with fullrange flag set. The JW player setup did NOT respect the fullrange flag. Anyone else have any input on this?
I always do _512kb as limited range...
edit: my test video. load it in something like madvr or lavf rgb output, then load it into jw player
http://www.mediafire.com/?58chlf8qf194f9g (12KB)
