Posts for Aktan

Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Pretty neat! Thanks for the shameless plug!
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
exileut wrote:
79.74% of Windows users use IE and Chrome combined. (required for 1080p60)Source
The requirement for IE is Win8+ and IE, so I don't think that's correct.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Anty-Lemon wrote:
Firefox works fine for me :/
Are you sure? I've done some research and it seems it may work if you enable "media.mediasource.enabled" and "media.mediasource.ignore_codecs" (more info http://www.ghacks.net/2014/07/25/enable-mse-h2-64-support-youtube-firefox-right-now/), but for me on Windows 7, it doesn't work. Can you post a screenshot with stats on to show it?
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
modify
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
franpa wrote:
This will both be glorious when they enable support for more resolutions but also probably a detriment. It could mean my internet will no longer be suitable for watching 720p videos due to poor download speeds once more and more people upload 60fps videos and Youtube starts feeding me 60fps footage...
I'm a bit late, but until "film" goes 60 FPS aka video cameras capture at higher FPS, you don't have much to worry about in terms of live video. Games on the other hand, I can see this as a problem.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
TASGameplayEncodes wrote:
2. Why don't you use CRF encoding for YT instead of qp in the Hybrid Encoding Script?
Because for YT which is known to transcode the video again, you want something to be encoded fast and don't care about file size (to a point). So doing qp makes it very easy, there is less to "think" about. As for lossless, you pretty much have to use qp, as crf 0 will not be lossless (old bug?). In general qp will have bigger files but better quality in less noticeable areas and encode fast, while crf will have smaller files and about the same quality, taking quality (make smaller file) from the less noticeable areas with slower encode speed. At lower numbers, it gets harder and harder to tell the difference between both.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
TimpZ wrote:
x264.exe didn't like me outputting an mp4 :/. Also I got a couple warnings when I changed the output to an AVI, not sure what they're about. This gave me a 65MB file that can't be rendered. Also I was hoping for as good quality as possible but I just noticed that for example Tee-N-Tee's TAS-encode by feos have the same artifacts so I guess I can't complain too much :p. The MKV program said something about being a buggy preview. Is that the correct version? Also I realised that I want inputs to be visible on the screen but I'm unsure how to do that without capturing the emulator with a separate program. Any advice?
Since I didn't know x264 doesn't come with MP4 muxer anymore, I'm sorry I told you that way. You should now output to MKV instead. So basically --output <whatever>.mkv As for playback, you probably don't have the right codecs. Though using the latest MPC-HC should give you the right codecs.... I'd say try MKV and playback that.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
creaothceann wrote:
Btw. I'm not sure why you'd use the "TV" range for input and output - the input is definitely full range (0..255 for each RGB channel) since you're using an emulator (they always output full-range in RGB colorspace), and I'd assume that most digital TVs can already convert full-range video on their own if needed...
The input is TV range because the script already converted to TV range. The output is TV range because YT converts only to TV range. This is why I also converted the input to TV range because YT only supports TV range. I rather control how it is converted than let YT do it.
creaothceann wrote:
Also, try CRF 16 or even 20, it should be visually very close to the original but much smaller.
I think a 65 MB file is pretty small already, lol. Especially with the upload speed he has. I rather send lossless H.264 at that rate. May give slightly better quality on YT!
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I don't know what you were expecting TimpZ, YT compresses regardless of what you send. At fast motion like sonic, most people won't see the artifacts you pointed out. Of course it won't ever beat your lossless upscale version. I should point out, the bigger the resolution, the more bits per pixel it gets, and the less artifacts you should see. So yes, upscale it by 12x like I suggested =p. As for why I extracted the WAV, the MP4 doesn't have audio when you encode the video, nor does the spec allow it regularly, which is why I mux in MKV which supports H.264 + WAV. As for output to AVI in VDub, that's a no no, as you probably didn't set the correct settings in both VDub and Lagarith to send the correct AVI (aka there is a slight quality loss you probably didn't notice but it probably made YT encode worse than it could). If you want, I can explain what settings were probably not set and why they should be set. The file also will be quite a big larger than using the command line I gave you. I forgot about the 30 Hz flicker. IMO I take care of it via selecting even/odd frames which makes it look a bit jittery, but IMO preserves the pictures the best.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I'm guessing you had no problem getting video in VirtualDub then. Well you have awesome speed so size really isn't a factor. I forgot one last program: MKVToolNix: http://app.fosshub.com/download/mkvtoolnix-7.2.0-setup.exe/18c9c22ad234b9394b750fb66f11f321 Get that and install it. Do you want 4k video? If so, change the
PointResize(1280, 896)
line to
PointResize(last.width * 12, last.height * 12)
In fact I made mistake in telling you that line last post. It should have been originally
PointResize(last.width * 4, last.height * 4)
So you have a choice. I think you can tell which is which. I also forgot to give you two more lines to add to the AviSynth script. They are:
ConvertToYV24(matrix="Rec709", chromaresample="point")
ConvertToYV12(matrix="Rec709", chromaresample="point")
So all the lines together should be something like:
AVISource("HG1.avi")
PointResize(last.width * 12, last.height * 12)
ConvertToYV24(matrix="Rec709", chromaresample="point")
ConvertToYV12(matrix="Rec709", chromaresample="point")
Test it out to make sure it works fine in VirtualDub again by opening the AviSynth script. After you are satisfied on the video size, go to (in VirtualDub) File->Save WAV... and save the audio WAV file somewhere. You will need that later. Now for video, open command prompt on the folder where the AVI, AviSynth script, and x264.exe is. You can do this easily via hold down the shift key and right clicking the folder and go to "Open command window here". Once in command prompt, type the following command:
x264.exe --qp 0 --keyint infinite --input-range tv --range tv --colormatrix bt709 --output <whatever>.mp4 <whatever>.avs
Where the first <whatever> is the output file you want and the 2nd <whatever> is the name you set to the AviSynth script. After that is done (which should be pretty quick), open "mkvmerge GUI." Click on add on the right and add both the MP4 file for video and WAV file for audio. You can change where to output to near the bottom and once you are satisfied, press "Start muxing" at the bottom which will create a MKV file. You can play this file back to see if it is fine (depends if you have the right codecs installed), then upload it to YouTube. Don't forget to add the tag yt:stretch=4:3 to correct the aspect ratio. If you have any questions let me know. Also provide a YT link on the final result! I love to see it =)!
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Welp hopefully I can help you. First get the latest software: Lagarith: http://lags.leetcode.net/LagarithSetup_1327.exe (You probably already have this) Avisynth: http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%205%20%5B130918%5D/AviSynth_130918.exe/download VirtualDub: http://sourceforge.net/projects/virtualdub/files/virtualdub-win/1.10.4.35491/VirtualDub-1.10.4.zip/download x264: http://download.videolan.org/pub/videolan/x264/binaries/win32/x264-r2479-dd79a61.exe Install Lagarith (which you probably already did) and Avisynth. VirtualDub just extract somewhere and I'll tell you where to place x264.exe (rename x264-r2479-dd79a61.exe to x264.exe to make it easier). You already figured out how to capture so I won't tell you how to do that. Now you have an AVI. I'm guessing HG1.avi. Place that AVI in an empty directory with x264.exe. In that same directory, create a new "AviSynth Script" (either right click a blank area and go to "New" or go to File->New). Now name that new file as something and then open that blank file in a text editor (like Notepad). Inside enter the following lines:
AVISource("HG1.avi")
PointResize(1280, 896)
(Change "HG1.avi" if that is not the correct filename) And save. Now open VirtualDub.exe in the extracted VirtualDub directory and in VirtualDub, open the AviSynth script you created above. If all goes well, you should see video. Now for some question before listing the next steps. How fast is your internet? If you have fast internet, you can encode really fast and upload it in very nice quality. Also how much free hard drive space do you have? For the best quality to YouTube, you need a bit of space. Not too much if the clip is short. Let me know if you have any questions.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Warp wrote:
It would be neat, though. NVENC can encode in real-time a 60FPS 1920x1080 videocapture of a game into a H.264 file, while taking something like 5% of the resources of the graphics card, and basically no resources from the CPU.
Like I said, most likely with a simpler settings. The crazy settings we do to squeeze every last byte is probably not possible on it. I do admit it would be great if it can be used, and I could be completely wrong now since I've not kept up.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Warp wrote:
I don't know if this topic has been discussed before, but I was wondering that since modern Nvidia cards have hardware support for H.264 encoding (NVENC), if there are any software or plugins that could be used to take advantage of this. A mencoder or a kdenlive plugin would be wonderful.
There has been attempts in the past with CUDA on NVidia with x264, but in the end one of the main x264 developer said it was not beneficial. I forgot exactly why, but I do know that usually the HW solution doesn't do the more complicated stuff available in the H.264 spec. What we do in our encodes is use the most complicated parts of it to maximize the quality vs compression. I've not kept up so maybe there is something now that can utilize this.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Back on topic, usually I do lower the settings a ton when doing high resolution encodes. --me and --merange is lowered. Also depending on the the amount of RAM you have, you may also need to lower b-frames or reference frames or rc-lookahead. I'm for higher res downscaling because IMO, even if it's blurry, it actually contains more information than the original. If you guys want I can post a very obvious screenshot in OoT credits where this is very apparent. Edit: Thanks for the cheers feos! =D
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
CoolKirby wrote:
I support this. I remember downloading the Modern HQ MP4 for the Ocarina of Time MST run in July and finding it a little blurry. Not enough to make it unwatchable but it would be nice if there was an Aktan-tier HQ option as well. I would download it.
Maybe I missed your point, but there is that option! It's only in the thread though...
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Kurabupengin wrote:
Wow never saw this one here. Does N64 emulation has better syncing now? did someone has solved this problem yet?
Unfortunately there has not been any development in N64 emulation (that I know of).
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
For downloadable encodes, keeping it at 4:4:4 is the best, but for online streaming like YouTube, you are forced to use 4:2:0, so at least 2x point resize is needed.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
But thanks to this, we know how to completely untouch the chroma in a 2x upscale. I'd say this is better than using ConvertToYV12() though I am unsure on how accurate the placement is.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Sp00kyFox wrote:
yeah I also found this thread in my search, this script only makes sense in the case of converting back to yv24. thanks for the help though. I started a thread on doom9 regarding this issue, let's see what the veterans have to say about this: http://forum.doom9.org/showthread.php?p=1681752
It will make sense not only in converting to YV24 for also RGB32. Great that you made a thread. I would like to see the answer. It could be I've been doing it wrong all this time...
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
I don't have time to try this now, but will later, but here is a good link you may want to try to see if it helps: http://forum.doom9.org/showthread.php?p=1551421#post1551421
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Yep, I'm a bit confused now too. I thought I got it working before, but I think the best I got was with that vertical shift with ConvertToRGB32(). I'll try asking the devs as seemly chromaplacement does nothing. Reading some comments, it seems this is the norm for resample="point" but right now I'm not sure why.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
Check my edits above in case you missed something. Also in VDub, uncheck Options -> Allow video overlays and see if it helps. Edit: Indeed adding ConvertToRGB32() still has a shift, but nothing like your screenshot. It's a lot less than without. Edit 2: Something is very screwed up. It seems like you did the color conversion, then upscaled it again by 4. This is incorrect. The color conversion should be the last thing you do.
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
How are you viewing it? My guess is the conversion back to RGB to view is screwing it up. Otherwise it looks fine. Easy test? Add this to the end and view it again.
ConvertToRGB32(chromaresample="point", matrix="PC.601")
Edit: To give more information, there are a few ways on how the sample is converted back to RGB. If it's done wrong, you get what you saw, which is bleeding. If it's done right, then the problem wouldn't show. The problem is, since there is nothing standard in the stream to indicate which way to convert, things like this sometimes happen. More information here: http://www.mir.com/DMG/chroma.html under "Three Varieties of 4:2:0". Edit 2: If you want to match what I would guess your computer is doing to convert back to RGB (MPEG 1 placement), I would use this line in your script instead:
ConvertToYV12(chromaresample="point", matrix="PC.601", ChromaOutPlacement="MPEG1")
More info here: http://avisynth.nl/index.php/ConvertToYV12
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
McBobX wrote:
I have a question:What is interlacing?Is it like deblink? What is the defferent betwen interlacing and deinterlacing?
Check http://www.100fps.com/
Experienced Forum User, Publisher
Joined: 4/23/2009
Posts: 1283
creaothceann wrote:
Then even 320kbits/s MP3 would be better (by being smaller) than raw WAV, because YT re-encodes it anyway and at that level you're not going to hear a difference. Of course you might not mind the audio stream's size being ~5 times larger... I just think it's a waste of uploading time.
Won't be better (in terms of quality) but yes it be smaller =p. You are right that prob won't hear a difference though, but it's easy to do, and one less step even though encoding to MP3 or any audio is pretty quick.