Posts for natt

1 2
42 43 44
Posted: 2/2/2012 4:21 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
ZMBV v0.1: 43.5MiB video size settings: well, there's one slider, but it wouldn't remember its position dump speed: N/A (only accepts RGB16 or RGB32 as input, and VBA only outputs RGB24 directly) encode speed: (virtual dub): ~1600fps decode speed: (FFmpeg md5 output, avisynth source): 2098fps That's impressive.
Posted: 2/2/2012 3:50 AM
Post subject: lossless RGB codec comparison
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
In case anyone is interested; I dumped http://tasvideos.org/966M 3 times with 3 different lossless codecs. In all cases I then verified that the files matched exactly (using ffmpeg's MD5 output). I didn't explicitly measure dumping time; I didn't think of it until it was too late. So you only get approximate numbers for that. For comparison, I also included x264 in RGB. You can't do this through VFW right now though, so I can't make any direct speed comparison. Lagarith 1.3.27: 332MiB video size settings: RGB mode, null frames on, threading on Dump speed: ~300-400% GBA speed average Decode speed (FFmpeg md5 output, avisynth avisource): 1865fps Camstudio 1.4: 196MiB video size settings: Slow (9), Gzip Dump speed: ~120% GBA speed average Decode speed (FFmpeg md5 output, avisynth avisource): 1868fps MLC 1.1: 51.0MiB video size settings: slowest, threaded Dump speed: ~100% GBA speed average Decode speed (FFmpeg md5 output, avisynth avisource): 500fps x264 r2146: 58.6MiB video size settings: --preset veryslow --qp 0 Dump speed: N/A (can't do in emulator directly) Encode speed (command line): 537fps Decode speed (FFmpeg md5 output, avisynth FFMS): 1031fps Notes: All tests done on a 2500k @4.0ghz
Posted: 2/2/2012 1:04 AM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Probably going out of sync? http://tasvideos.org/DesyncHelp.html
Posted: 2/1/2012 11:45 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
ThatGugaWhoPlay wrote:
When I used the .mp4 format with 44.1khz, YouTube desynced it. I don't know why but it just started to do it (stupid YT). Anyway, after looking why is this happening, some guy say that putting the Khz to 48 will fix it. It works!
I would expect no less from our glorious lord and master, Youtube. That being said, there might be other possible solutions as well: Try a different muxer. Mp4Box comes well reccomended. Try a different container. A lot of people have success uploading to Youtube in mkv. Try a different audio codec. It "shouldn't" matter, but you never know with Youtube. Flac? Vorbis? I personally have uploaded youtube at various framerates (30fps for most stuff, 29.9something for Turbo Grafix 16) all with avc+flac in mkv, and haven't had any audio desyncs, for what it's worth.
Posted: 2/1/2012 10:50 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
ThatGugaWhoPlay wrote:
Well, is just a tutorial. People will know that the movie should played from the very first frame. The emulator was going slow due to the Screen Recorder. Thanks for the config of Lagarith. And as far as I know, 29,97 against 30 is clearly no difference. 30 FPS is just an approximation.
The text tutorials already on this site make all of these things exactly explicit though, including issues like "how to record starting at the first frame". How is your guide more useful when it leaves these things out? As far as the framerate goes, VBA dumps are at EXACTLY 60 fps. In order to put it on youtube, it must be less than or equal to 30 fps (otherwise youtube does another framerate conversion). You can get exactly 30fps by dropping every other frame frame or doing any of a variety of special blends that preserve motion. Any drop to 30000/1001 fps is going to have an occasional stutter in it. Not terribly noticeable; but then again, you didn't gain anything by choosing ~29.97 over 30 either. Why are you resampling the audio to 48khz? Since it's originally 44.1khz, the only thing resampling it does is add another lossy conversion.
Posted: 1/31/2012 11:30 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
nanogyth wrote:
--me umh --subme 10
Why these instead of placebos defaults of tesa, 11?
The parameters I used are for the most part my normal encoding parameters. The reason why my normal encoding parameters use --me umh --subme 10 comes from a few different input sources, including Grunt's command line reccomendation, some people on the tasvideos irc, and doom9/doom10. I verified their claims myself for two runs (so six encodes): comparing commands that are identical otherwise (--preset placebo, etc) and differ only in --me umh --subme 10 vs --me tesa --subme 11, the results are visually indistinguishable (to me), same filesize (<1% difference), but the straight placebo encode takes 2x-3x as long to run. That's a pretty bad tradeoff, and supports the claim that --me umh is pretty damn good and results in very few errant motion vectors.
Posted: 1/31/2012 8:23 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Avisynth 2.5x can't handle YV24 processing internally. Is there a 64 bit Avisynth 2.6? If not, you have to change something or other. Here are a few possibilities: 1. Have x264 convert to YUV internally Pro: Don't need any new software. Con: Conversion will be rec601 (not that it matters, since youtube always gets SOMETHING wrong with colors) 2. Use 32 bit x264 with 32 bit Avisynth 2.6 Pro: Don't need to change scripts Con: Encoding will be slower 3. Run the avisynth script with something else (like avs2pipemod), then pipe it to x264. Pro: Can use 32 bit avisynth with 64 bit x264 Con: Commandlines get more complicated, and there's some pipe-related overhead. I personally use #3&#1. I would recommend trying #2 for starters; it's probably the simplest to get going? The encoding guides should be updated to correct for these hiccups...
Posted: 1/31/2012 8:14 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
What version of avisynth are you using. Edit: As far as range goes, that commandline looks outdated. x264 range handling was changed recently. For youtube encode, you should have no range-related parameters in your commandline.
Posted: 1/31/2012 8:02 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Colorspace conversion. Whether you want to have exactly them depends on your workflow; are you having x264 load the avs script directly? What is your encoding commandline and what error messages are you getting?
Posted: 1/31/2012 7:54 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I personally use camstudio for lossless RGB dumps, but honestly, FFV1 should work fine. Not sure exactly what the problem is, I don't use ffdshow =/ Another option is to use FFMS to import to avisynth. It handles stuff directly without involving your codec stack, and it *should* support FFV1
Posted: 1/31/2012 7:43 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
welp, it sure is FFV1. i'm not sure what exactly can decode FFV1, but i know in order to use it with AviSource (), you need a VFW decoder. According to google ffdshow can decode FFV1. I know ffdshow has a whole settings pane where individual decoders can be turned off and on? Might try checking there.
Posted: 1/31/2012 7:31 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
mediainfo is a good tool to have around for this situation. Could we have a mediainfo output from the avi you're trying to import?
Posted: 1/31/2012 7:20 PM
Post subject: x264: rgb 8bit vs yuv444 10 bit
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Compare x264 encoding with 8 bit per channel RGB to 10 bit per channel YUV 4:4:4. For lossless (--qp 0), RGB generally makes smaller files from sources that were originally RGB. For lossy, RGB doesn't stand up to YUV. A short example test: encoding commands (here x264_10 is a 10 bit executable) 
x264  --bitrate 500 --pass 1 --preset placebo --rc-lookahead 120 --keyint 400 --me umh --subme 10 --merange 32 --output-csp rgb -o foo.mp4 testin.avi
x264  --bitrate 500 --pass 2 --preset placebo --rc-lookahead 120 --keyint 400 --me umh --subme 10 --merange 32 --output-csp rgb -o newtest_rgb.mp4 testin.avi


x264_10  --bitrate 500 --pass 1 --preset placebo --rc-lookahead 120 --keyint 400 --me umh --subme 10 --merange 32 --output-csp i444 --range pc -o foo2.mp4 testin.avi
x264_10  --bitrate 500 --pass 2 --preset placebo --rc-lookahead 120 --keyint 400 --me umh --subme 10 --merange 32 --output-csp i444 --range pc -o newtest_10bit444.mp4 testin.avi
The original source is two minutes of GBA footage. The output files are here: http://www.mediafire.com/?vbjvitb1j4io22r You can see by watching the two directly, that RGB doesn't even come close to YUV in image quality at the same bitrate. Note: If the colors&ranges in the two videos look different, it's your player's fault. Both encodes are properly set as full range. If anyone has any comments or criticisms on this test, I would love to hear it.
Posted: 1/29/2012 7:57 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Toothache, have you made any progress on this? If not; as long as you know what information you want displayed (ie, you have the memory addresses or whatever), I could look into making a special encode for you.
Posted: 1/29/2012 3:58 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
creaothceann wrote:
An NTSC filter (for games played on TVs) would also be nice, but I don't know of any Avisynth filters that do that.
It (should) be possible now to use those filters in realtime, just like you can use them in realtime on the emulators themselves. The 10bit444 encode with pixels preserved would then be the preferred one for everyone, because particular people could just use whatever filters they wanted to. I don't know if that's been implemented anywhere though?
Posted: 1/26/2012 2:50 AM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
la mammal, can you play the following .mp4 file? http://www.mediafire.com/?at7ibl4fiqv254n
Posted: 1/24/2012 9:51 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
ThatGugaWhoPlay wrote:
So... I just encode in 1080p?
that's not what i said
natt wrote:
so that gives 1920x1280 for the GBA.
Posted: 1/24/2012 5:43 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
http://tasvideos.org/1589M.html , right? When a game has square pixels (as is the case in GBA), the "Youtube HD" encode is supposed to be at any resolution which is an even integer multiple of the original while being >= 1920x1080 in total. There's no reason not to choose the smallest one, so that gives 1920x1280 for the GBA (8x in each direction). A nearest neighbor resize can then be used (called PointResize in avisynth) to upscale without any problems or loss of anything. Your original video is at 2048x1152 and looks to have been scaled with some sort of bilinear or similar method. While you did get the aspect ratio right (by pillarboxing), your video is scaled up 7.2x in each direction which defeats the idea of the HD encoding. This page http://tasvideos.org/EncodingGuide/HighDefinition.html gives a good overview of the process.
Posted: 1/23/2012 4:33 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I believe most TASers use keyboard for TASing systems like the SNES. You need access to all of your inputs as well as other special keys at once. Cumbersome really doesn't factor into it; after all, you're doing things one frame at a time, it's not going to be fun; all you need is accurate. PS1 controller has R2/L2 right? You could use a joy2key type thing to use one of them for frame advance...
Posted: 1/20/2012 9:31 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
This topic was discussed in more detail yesterday on IRC chat, so I'm going to sum that up for anyone who should happen to read this but wasn't there. Flash seems to behave differently depending on a number of factors. Different video card (in the case where hardware accelerations are used), different "resolution" selection on the youtube video (can change the format and decoder flash uses internally), even hitting the fullscreen button (can switch to a different accelerated output path) can cause the color interpretation to change. Not to mention mobile devices, or the new "HTML5 webM" technology that's on the way. I can only say the following things for sure: 1) Don't send "PC level" YUV data to youtube. Always use "TV level" (16-235). 2) Sending RGB data to youtube doesn't hurt, but it doesn't help either; even if the data is transformed once RGB->YUV internally by youtube's transcoder in a predictable way, the different flash players can still handle the resulting YUV differently. Beyond that, I can't say whether 601 or 709 is appropriate for HD uploads, since different youtube players will handle it differently; there is no right answer.
Posted: 1/20/2012 12:20 AM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Aktan wrote:
Great info, thanks natt! So apaprently I should have tested 720p/1080p also to see that it is Rec.601. Edit: Question: The source is in what matrix?
y4m is a simple format which stores raw yuv data. the "original test source" in this case IS yuv data, with no matrix or interpretation given. the three different encodes and uploads correspond to different sets of VUI data, but the original stream is exactly the same. Edit: Ilari brought up another issue in IRC: what if different flash players play it differently? My test was done on Windows 7 64bit with firefox 32bit and flash player 32bit 11.1.102.55. I got out my laptop, which ruins ubuntu 11.04 32bit with firefox 32bit and flash player 32bit 11.1.102.55, and it played the video DIFFERENTLY. It looks like one thing at 240p and a different thing at 360p, 480p, 720p, 1080p, and original.
Posted: 1/19/2012 10:55 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
More tests of youtube upload! I'm working on gba encodes, which get "HD" processing at 1920x1280. My goal is to give an appropriate matrix for them, so the test uploads are at 1920x1280. Step 1: The test pattern. Redirect output to pattern.y4m; this takes about 1GB of HDD space. http://pastebin.com/YDjjXPST Step 2: encode (8 bit x264) 
x264                                                                    --qp 0 -o lossless_undef.h264 pattern.y4m
x264 --colorprim smpte170m --transfer smpte170m --colormatrix smpte170m --qp 0 -o lossless_bt601.h264 pattern.y4m
x264 --colorprim bt709     --transfer bt709     --colormatrix bt709     --qp 0 -o lossless_bt709.h264 pattern.y4m
Step 3: Verify that x264 has not touched the colors AT ALL and all three samples are identical except for VUI 
ffmpeg -i pattern.y4m         -f rawvideo md5:
ffmpeg -i lossless_undef.h264 -f rawvideo md5:
ffmpeg -i lossless_bt601.h264 -f rawvideo md5:
ffmpeg -i lossless_bt709.h264 -f rawvideo md5:
I got md5=4d0b4a461f189366e7c4152b8257b70c for all four cases Step 4: mux. h264 in mkv is the same way i've been muxing for yt upload 
mkvmerge -o undef.mkv --default-duration 0:30fps lossless_undef.h264
mkvmerge -o bt601.mkv --default-duration 0:30fps lossless_bt601.h264
mkvmerge -o bt709.mkv --default-duration 0:30fps lossless_bt709.h264
Step 5: upload. http://www.youtube.com/watch?v=I0A4wNhAAUg http://www.youtube.com/watch?v=Ksn55lGtpx0 http://www.youtube.com/watch?v=HRWgLlKnrcQ Step 6: Avisynth script to compare to. 
# requires ffms2.dll

FFVideoSource (source="undef.mkv", cache=false)

#convert to RGB internally; hopefully player leaves it unmolested
clip601 = ConvertToRGB24 (matrix="rec601").Subtitle ("601",
\ y=640, align=5, first_frame=0, last_frame=299, size=96.0, text_color=$20FFFFFF, halo_color=$20000000)

clip709 = ConvertToRGB24 (matrix="rec709").Subtitle ("709",
\ y=640, align=5, first_frame=0, last_frame=299, size=96.0, text_color=$20FFFFFF, halo_color=$20000000)

clip601 + clip709
Step 7: Watch the avisynth script in your favorite video player and the youtube videos in a youtube window. Conclusion: All 3 uploaded videos are understood by youtube as rec601 at resolutions 240p, 360p, 480p, 720p, and 1080p, and are understood by youtube as rec709 at resolution "original". The VUI hints in the h264 stream are completely ignored in all cases.
Posted: 1/17/2012 1:06 AM
Post subject: Genesis Aspect Ratio (320x224) (NTSC)
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
This website suggests a 6.67mhz pixel clock in 320x224 mode: http://www.atariage.com/forums/topic/179080-atari-sm147-monochrome-monitor-impressions/ This website suggests a 6.70mhz pixel clock in 320x224 mode: http://www.geocities.ws/podernixie/htpc/modes-en.html#smd This website suggests a 53.694175mhz reference clock for the GPU: http://cgfm2.emuviews.com/txt/vdppin.txt If we assume that the pixel clock is generated from simple integer division off the reference clock (quite easy to go), 53.694175/8=6.712mhz which is suspiciously close to both of the other sources. Using this for AR calculation (I've found http://lipas.uwasa.fi/~f76998/video/conversion/ to be pretty good), we get 320/224 * 58320/4739 / (53.694175/8) / 2 = 1.3097... As the "Display Aspect Ratio"
Posted: 1/16/2012 10:43 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Just in case anyone picks this thread up on search: The combat RNG for FFXII is fully understood (however, not everything that calls it is). It's very easy to force chest contents (in fact, it can easily be accomplished in realtime) but hard to force combat results, because there's nothing you can control very well in realtime that "burns" RNs. As far as the "simplicity" comment goes, it has a period of 10^6000 (MT19937).
Posted: 1/14/2012 7:27 PM
Quote
natt
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Another usage example: http://tasvideos.org/forum/viewtopic.php?p=273784#273784 So with 4 resolutions 640x480 ("disc switch" screens, etc) 368x216 (menu) 320x224 (normal gameplay) 320x216 (battle) To fit everything with no downsizing, the final encode has to be at least 640x480. If you encode at 640x480 and use DAR = 1.234, you get the following processes: 640x480->640x480 (leave as is) 320x224->640x448 (point resize 2x) 320x216->640x432 (point resize 2x) 368x216->644x216 (1.75x (width), 2x (height), crop 4 pixels width) On the other hand, if you want to do a square pixel encode this is one possible way to do it: 1184x960, square pixels 640x480->1184x960 (1.85x w, 2x h) 320x224->1184x896 (3.7x w, 4x h) 320x216->1184x864 (3.7x w, 4x h) 368x216->1191.4x864 (3.2375w, 4x h, crop 7.4 pixels width)
1 2
42 43 44