Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
nanogyth wrote:
If you download the roadrunner clip it has the three side by side (on/off, 60fps, blended). I think the blended looks more like the 60fps, would you disagree?
I would disagree, but that's not necessarily relevant, as I admit the 60fps flicker probably looked different on a CRT TV 20 years ago than it does on my LCD today.
I find this all very frustrating because of course there's an obvious best solution: stick with original 60fps. I hate youtube ><
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
edit: i personally would recommend the following settings for HD encodes after this test:
edit2: changed GB/GBC: 8x8 is big enough to get full HD
#GB/GBC:
PointResize(1280,1152) # 8x8
#GBA:
PointResize(1920,1280) # 8x8
#NTSC NES, SNES (256x224)
PointResize(2048,1792) # 8x8, must force 4:3 on youtube
#NTSC Gens (320x224 dominant) must force 4:3 on youtube
#320x224 sections:
PointResize(2560,1792) # 8x8
#256x224 sections:
PointResize(2560,1792,32,0,256,224) # 10x8
#NTSC Gens (256x224 dominant) must force 4:3 on youtube
#320x224 sections:
PointResize(1024,896).PointResize(2048,1792) # 6.4x8
#256x224 sections:
PointResize(2048,1792,32,0,256,224) #8x8
#psx: too may possibilities, and too complex to list here. the method also doesn't even work for many psx resolutions (in particular, if the normal encode is 240 high)
#arcade systems: not well standardized enough, so just BS something that looks good enough
#other systems: i haven't researched..
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
353M encoded to HD
method one:
PointResize(960,720).PointResize(1920,1440)
http://www.youtube.com/watch?v=Jpq0IKdOfYU
encoded 21162 frames, 19.60 fps, 1524.68 kb/s
(video streamsize: 153MiB) (lossless 4:2:0)
method 2:
PointResize(2560,1792)
http://www.youtube.com/watch?v=V0YBtYkgNSI
ytstretch tag added
encoded 21162 frames, 14.19 fps, 680.27 kb/s
(video streamsize: 68.6MiB) (lossless 4:2:0)
both encodes have the same final aspect ratio. here's one screenshot comparison of the "original" encodes, 1920x1440 on left. make sure view the screenshots at fullsize (1920x1080, fullscreen on my monitor)
http://imageshack.us/gal.php?id=sZWmks7i09za1tqUpKWWna2YpZHb4c2b
it doesn't look close at all to me; look at the detail loss in the 1920x1440 on the green building in the background. Sorry the shots aren't the same frame; have you ever tried to do anything with flash player? =p
That being said, I think the 1920x1440 one looks better at 480p encode when viewed on youtube's "large player". This makes sense because that 480p transcode is exactly 640x480, which gets viewed 1:1 (no output scaler) on the youtube "large player". Where as the other one is 686x480
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Use of flickering in games is usually used to simulate transparency, not flickering.
I don't think I agree with this. It's been a while, but I did play some classic console games on conventional CRT TVs back in the day. When my dude took damage, I flickered. Now, I wasn't doing careful observation, nor was I comparing with frame advance in an emulator to know which flicker pattern I was supposed to be observing (there are so many), but I think the expected user viewing result with a lot of these flicker patterns was in fact flicker.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
There's certainly no technical flaw in MeGUI that makes it unsuitable.
As far as easy to use, I personally find that gui solutions can be easier at first, but then once you've gotten an idea of what you want to do and how you want to do it, they make you jump through needless hoops.
My batch setup requires me to set up one normal avs script, one youtube avs script, and a few parameters in a project file, and then it automatically spits out:
vorbis audio
aac audio
flac audio
normal encode (original res, 4:2:0, flagged AR, dedupped)
hi10 encode (original res, 4:4:4#10, flagged AR, dedupped)
512 encode (lancos resize to calculated AR, 4:2:0, no dedup)
youtube encode (resize by avisynth, decimate by avisynth, 4:2:0, no dedup)
normal mux (normal+vorbis in mkv)
hi10 mux (hi10+vorbis in mkv)
512 mux (512+aac in mp4)
youtube mux (youtube+flac in mkv)
Each output file is given the project name I specified, plus its type, plus the CRF that it was encoded at. When I audition the results, if I don't like one I can just change the CRF in the project file, and it automatically redoes only what's necessary and gives me the new output (with different name by CRF) to compare with the previous one.
Now, was this complex to set up? Maybe. Took a decent amount of time to hammer everything down. Now that it's done though, I'm not clickety-clacking through UIs all day. Plus it's easily extensible. Adding things like Turska's 4:4:4 mkv workaround is trivial and doesn't increase encoding effort required at all. Even a whole extra encode, say, WebM, wouldn't be that bad.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I agree that this looks very interesting. That being said, I'd like something concrete to go on; in the near future, I'm going to do a suitable Genesis run both ways and upload them both to Youtube.
In the meantime, I have a question: Is there a way to do this with the _512kb encodes as well? Some _512kb suffer greatly from the codec poison that is resizing.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
.........
During the course of processing runs, I've seen that logo go across my screen about 23052835023850238520385023468394 times.
/sigh
Well, the archive.org encodes aren't affected. Re-encoding. I'll decide what to do with the other 22 youtubes later...
Potential screenshots:
http://www.mediafire.com/?dyrnwk4vl77drd9
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
mpc-hc ignores all mkv container dimensions. this bug does not affect mpc-hc at all.
i believe mplayer is the primary playing program that's affected by this.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
http://www.mediafire.com/?wyg109apis3ahbt
160x161, 10 bit yuv 4:4:4
intended PAR: square pixels (1:1)
intended DAR: 160:160
The circle and square should be exactly circle and exactly square; no oval or rectangle.
actual PAR/DAR: varies by player
Some programs will think this video has dimensions and or display dimensions of 160x146, because of braindead handling in mkvtoolnix.
The fun part is, you can't actually make it "right", because the "video pixel size" information in the header will be wrong no matter what. Fortunately, most players seem to rely on the decoder for that information.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
If you create mkv files with the mkvtoolnix toolchain, that contain colorspaces other than 4:2:0 yuv (4:2:2, 4:4:4), and have dimensions that are not divisible by 16, these files will generally have container-level aspect ratio set to something other than what you want. In order to fix this, you must explicitly set parameters to mkvmerge
--display-dimension TID:wxh
There is little cause for concern; this affects a very small number of encodes, and the effect ranges from nothing on some players to a slightly incorrect AR on other players.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
nfq wrote:
DrHell wrote:
How do Tasers or encoders do, for having the video in HD?
HD sucks for 2D games that have low resolutions like 320x240, better just encode with the normal in-game resolution, it looks better, is much easier to encode, and doesn't waste as much space and bandwidth on youtube.
It doesn't look better, in fact it looks awful. I don't care if it's easier to encode, my job is to do things well, not easily. And it's not my problem that youtube's wasting bandwidth. If their transcode system wasn't a pile of crap, I wouldn't need to use such hackery.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Because I apparently can't figure it out. I run this script, and player HP immediately changes to 68... but it doesn't stay there. I'm pretty sure I have the right memory address; and I see the values at that address changing in memory watch, but my callback never gets called.
Language: lua
-- this sucessfully changes player HP once
memory.writeshort (0x00097ba0, 68)
-- this does not sucessfully freeze player HP
memory.register (0x00097ba0, function ()
memory.writeshort (0x00097ba0, 68)
end)
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
nanogyth wrote:
Why not have lossless RGB as the primary encode?
The quality would be better, and it would fail properly if you didn't have it setup right.
I've heard lossless is smaller than x264 compressed on some games, is that generally true?
Lossless RGB with what codec? H264? That's not generally true. I just went back to my most recent completed encode (http://tasvideos.org/507M.html) and ran an RGB h264 lossless command for it. The raw .h264 file I got is more than 4 times the size of the .h264 files that were published for the normal and hi10 encodes.
Now, 74.0MB and truly lossless beats the intermediate codecs we currently use (more information here: http://tasvideos.org/forum/viewtopic.php?t=12390) but that's a workflow thing. The files are unnecessarily large for final encodes.
It's possible there are some particular games (it would have to be very low detail ones) where it comes out below lossy, but I doubt it. H264 lossy mode scales down very well.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
UraniumAnchor wrote:
Encoding NES videos at 1080p is essentially harmless to the people who don't care that much about quality, but limiting everything to 10-bit encodes is going to shut out a lot of people who can't be arsed to install something new. They'll just watch it on youtube instead.
Edit: Also, if "QUALITY" is the rallying cry here, isn't telling people to go watch the youtube encodes if they can't play the files sort of contradictory?
Hmm? No one said the youtube encodes were low quality. They're just massively inefficient spacewise. On the other hand, if you want to download an encode, 4:4:4 obliterates 4:2:0 any day.
As far as the "people who can't be arsed", how good an outcome are they ever going to get? I'd say getting them to even click on the youtube link is a major win.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Cool Matty wrote:
I actually registered (with the encouragement of a few others) to post just for this topic. I am writing this in response to the recent news post of this soon becoming the primary codec.
I am asking that you strongly reconsider this.
First let me state plainly that I don't mind whatsoever if there are secondary encodes in 10-bit, or what have you. Options are always nice.
However making 10-bit the primary encode, I can't agree with. Here is my list of reasons, in no particular order:
1. Codec support is mostly experimental. VLC being one of the only ones I can think of that is shipping it as a stable release.
2. It requires viewers to obtain completely new software or codecs in order to appropriately view the content. Worse, if viewed on incompatible viewers, it will look abnormal, leading viewers to believe the video is corrupt or otherwise.
3. It completely removes hardware acceleration support across the board. I don't think there is a single consumer device out there that has 10-bit support with hardware decoding.
4. As a corollary to #3, the removal of hardware acceleration significantly impacts the playability for any mobile device. Smartphones, tablets, and netbooks all rely on hardware acceleration (especially for resolutions above 640x480). These devices would have to rely on YouTube encodes instead, which is hardly ideal. Furthermore, adding compatible decoders/players on these devices are incredibly slim.
5. The future of 10-bit playback is not certain at all. Considering the ratification of h.265 is coming in the near future (Which will offer much greater performance overall as a codec), 10-bit is becoming little more than a stop-gap.
6. As a corollary to #5, it's a stop-gap measure that doesn't serve much purpose. The quality improvements are minimal at best, file size reductions are also minimal (on the order of single-digit megabytes per 100MB).
1. 10 bit support is in all current libavcodec builds. I am curious though; does anyone know when it was introduced? Searching changelogs is no fun.
2. I agree that this is a disappointment. It always surprised me about 10 bit h264 that an 8 bit decoder can decode it and in many cases show something "good enough" that the user will assume it's being decoded correctly and blame the problem on the content producer.
3. As far as desktop computers go, I doubt there's a single one in existence that both can't handle 240p60 10bit in pure software yet can handle 240p60 8bit in pure hardware. As far as other devices go, see #4.
4. There is some truth to this, but what's also true is our other encodes don't necessarily fare any better in this respect. Many hardware decoders have limitations that we don't respect. I'm not up on all the details, but I know high numbers of reference frames causes problems in many cases, and the current guidelines use max reference searching. Our normal encodes often times use MKV container with all bells and whistles activated; even though this isn't an h264 decoding issue, it can still be a playback issue. Even the "_512kb" encodes, which don't even have direct download links, are targeted towards the Main Concept decoder, which has little to no limitations other than colorspace, and so those encodes aren't suitable for many mobile devices either.
5. I do not follow this point at all. 10 bit encoding will not get worse than it is now if and when h265 comes out. There's just no logic to this statement.
6. As far as the filesize argument goes, I think you are missing something: these are 4:4:4 encodes, where as the old encodes were 4:2:0. Low res pixel art has extremely detailed chroma information, and these encodes are much higher in quality than the 4:2:0 ones while maintaining a similar filesize. 4:4:4 is the real winner here and the reason why all of this is being done. 10-bit is just a moderate compression improvement that is used because once you bring in 4:4:4, you've already lost all the hardware players anyway.
If you want to watch TASes on your mobile device, use the youtube versions. That's what they're there for.
If you see a mode which is similar but slightly different (eg 256x232 vs 256x224 vs 256x240), use the exact same PAR. I think turbografix 16 has more modes, haven't researched it...
edit: i personally would recommend the following settings for HD encodes after this test:
edit2: changed GB/GBC: 8x8 is big enough to get full HD