yua

TheThrillness

Edit history:

TheThrillness: 2014-12-10 11:38:19 am

TheThrillness: 2014-12-10 11:38:00 am

TheThrillness: 2014-12-10 11:31:02 am

TheThrillness: 2014-12-10 11:29:23 am

TheThrillness: 2014-12-10 11:28:31 am

2014-12-10 11:27:41 am

thethrillness.blogspot.com

So I was going over GreenKnight129's d,f question in the sticky thread and he supplied a SNES source video. Besides just giving the normal D4,F1,2D answer I decided to just encode it because I was bored. Discovered what might be a big bug.

I got clarification from GreenKnight on his process over PM before I posted this.

1. Captured using a Dazzle and YUY2 with AmaRecTV. x264vfw set to capture YUY2.
2. For quality test he opened the video in VirtualDub and trimmed out a section he wanted. Set x264vfw as the output codec then did Save as AVI.
3. Encoded that in Yua. Here is the source from step 2: http://www.mediafire.com/download/uayxkt9ko4sy0yt/dffpd-Test.avi

The below picture is what gets displayed in the yua encode when you use madVR (attached an encode). Any other renderer or player like VLC is fine.

The issue (I think) comes from that VirtualDub is set to send RGB to the encoder as default (Video > Color Depth). Since GreenKnight had "Keep input colorspace" ticked in x264vfw, it set the codec to output RGB (Yua states this as does MediaInfo). I can also replicate this with any video file by following the above steps. The source can be anything and happens for all qualities.

I don't know if this is a yua or madVR bug since yua does produce good output for other media players/renderers. It's likely to be madVR though. I'll try and see if I can put together a bug report to the madVR developer or if someone more experienced in this wants to do it? To be honest, I'm lost past this stage as to what might be wrong. I should also say that blizzz verified this on his own madVR setup so not just me.

Edit: Just occurred to me to try anri. I can confirm that anri does not have this issue and madVR plays it back fine.

So I was going over GreenKnight129's d,f question in the sticky thread and he supplied a SNES source video. Besides just giving the normal D4,F1,2D answer I decided to just encode it because I was bored. Discovered what might be a big bug.

I got clarification from GreenKnight on his process over PM before I posted this.

1. Captured using a Dazzle and YUY2 with AmaRecTV. x264vfw set to capture YUY2.
2. For quality test he opened the video in VirtualDub and trimmed out a section he wanted. Set x264vfw as the output codec then did Save as AVI.
3. Encoded that in Yua. Here is the source from step 2: http://www.mediafire.com/download/uayxkt9ko4sy0yt/dffpd-Test.avi

The below picture is what gets displayed in the yua encode when you use madVR (attached an encode). Any other renderer or player like VLC is fine.

The issue (I think) comes from that VirtualDub is set to send RGB to the encoder as default (Video > Color Depth). Since GreenKnight had "Keep input colorspace" ticked in x264vfw, it set the codec to output RGB (Yua states this as does MediaInfo). I can also replicate this with any video file by following the above steps. The source can be anything and happens for all qualities.

I don't know if this is a yua or madVR bug since yua does produce good output for other media players/renderers. It's likely to be madVR though. I'll try and see if I can put together a bug report to the madVR developer or if someone more experienced in this wants to do it? To be honest, I'm lost past this stage as to what might be wrong. I should also say that blizzz verified this on his own madVR setup so not just me.

Edit: Just occurred to me to try anri. I can confirm that anri does not have this issue and madVR plays it back fine.

Attachments:

nosferatu_HQ.mp4

nosferatu.png

blizzz

2014-12-10 11:45:02 am

Top VLC, bottom madVR. Left is how it looks in the player and the three other pictures are the Red, Green and Blue channel. Looks like madVR decodes green as luma and red and blue are color differences. It also shows in its stats that the video is decoded as GBR. I'm not sure if this is an issue with the video file (maybe some meta data?) or the renderer.

nate

2014-12-10 10:47:40 pm

best guess at the cause looking at it briefly just now is that yua currently passes through the AVCodecContext::colorspace value of the input to the output. i added this earlier this year i believe when thrillness found that yua was discarding colorspace standard information (note that this is colorspace standard, aka this stuff, not yuv versus rgb or yuy2 versus yv12). but now with this new sample input the colorspace is inappropriate to pass through because it is "GBR" (even though the ffmpeg inline documentation in the header says this value is "YUV colorspace type" ...) and yua does not output rgb ever due to problems with x264. the most it will output is yuv 4:4:4. so maybe the fix is i need to pick up after ffmpeg's mess yet again and block colorspace standard passthrough if the source is not yuv (any sampling). thoughts?

nate

2014-12-10 10:49:35 pm

how did i miss this attachment?

Attachment:

Screen Shot 2014-12-10 at 11.37.00 PM.png

GreenKnight1294

Edit history:

GreenKnight1294: 2014-12-10 10:50:31 pm

2014-12-10 10:50:01 pm

Quote from Thrillness:

No the recording is fine. It's just VirtualDub setting it to RGB by default. If you ever use VirtualDub again for trimming, go to Video > Color Depth before you encode and set it up like this. This will keep everything as YUY2 and no issues will arise. You will notice by default one was set to RGB, thus the problem. Clicking Save as Default is not a bad idea. Wink

It was cropping the video with Vdub and the wrong colors were getting changed to wrong formats from the default settings of Color Depth. Luckily I fixed it since it even opens properly on VLC now. Thanks, Thrillness!

TheThrillness

2014-12-11 06:11:49 am

thethrillness.blogspot.com

hehe, I never thought to put the encode back into yua. I did check it in MediaInfo but the matrix coefficient value is hidden unless you scroll down. I just saw YUV 4:2:0 and thought it was fine.

As for how to combat this, I think you just block RGB (or gbr) if it's attached to h264. Just bring up a window that says something like "This colorspace has issues with this codec. Please use another".

nate

2014-12-11 08:05:32 am

isn't the output fine though except that some players get confused by the bogus colorspace value? it seems more like i could just cut that and it would be totally fine.

btw thinking about this more this morning i think that colorspace standard is just metadata in mp4. in other words it's up to the player to ignore it or do whatever with it. most players wisely ignore a bogus colorspace of "GBR" if the input is yuv but some apparently get confused. which is not surprising.

TheThrillness

2014-12-11 08:40:39 am

thethrillness.blogspot.com

Well ideally everyone should be using MPC with madVR for optimal quality (of course talking Windows). All the other players are fine because they aren't coded to read that metadata, or override it as you said.

Maybe you just leave yua as it is. Like the amount of times this will actually become an issue is so few it's not worth fixing. The only time this would ever crop up now is if a PC runner for some reason decided to use x264vfw in conjunction with AmaRecTV/VirtualDub to capture his run in RGB. Since PC runners have way better alternatives, this will never be an issue. That's the only conceivable scenario I can think of anyway.

Mystery

2014-12-11 04:00:59 pm

I don't see the point of madVR seeing as it doesn't seem to yield any quality improvement (to my eyes) over EVR. Also, madVR seems to affected by the problem, and it's not just MPC or whatever. Other players are affected (with madVR, but not EVR).

TheThrillness

2014-12-12 08:09:34 am

thethrillness.blogspot.com

It depends what you view with it. I've mostly seen the improvements with 4:2:0 content.

nate

2014-12-14 05:03:07 pm

i got halfway through dealing with the colorspace standard stuff when i realized that yua should probably not be outputting different colorspace standards depending on the input when i can just standardize on one standard (...) and decode all input to that, using it internally. so i patched yua to always decode to bt709 which seemed like a good standard (especially considering yua can only output yuv, hdtv-like stuff). yua also includes that colorspace standard in the output as metadata now so players that pick up on that will show the right colors. players that don't should be close since bt709 is apparently very close to bt601 which is probably what they will incorrectly decode as.

if no one sees any holes in this then i will upload a beta for your testing. really need to test this one since i'm not 100% sure about something (yua uses rgb internally and i'm not sure whether decoding to rgb with bt709 is really a good idea). worst that will happen is the colors are wrong for some input and we will have to think of something else.

i got halfway through dealing with the colorspace standard stuff when i realized that yua should probably not be outputting different colorspace standards depending on the input when i can just standardize on one standard (...) and decode all input to that, using it internally. so i patched yua to always decode to bt709 which seemed like a good standard (especially considering yua can only output yuv, hdtv-like stuff). yua also includes that colorspace standard in the output as metadata now so players that pick up on that will show the right colors. players that don't should be close since bt709 is apparently very close to bt601 which is probably what they will incorrectly decode as.

if no one sees any holes in this then i will upload a beta for your testing. really need to test this one since i'm not 100% sure about something (yua uses rgb internally and i'm not sure whether decoding to rgb with bt709 is really a good idea). worst that will happen is the colors are wrong for some input and we will have to think of something else.

TheThrillness

2014-12-15 07:21:47 am

thethrillness.blogspot.com

Over the past few months, colorspace has confused me (more so when you are bringing video game consoles into the mix). I still don't think I understand it (wrong assumptions probably). I used to think 601 was an actual colorspace but it just specs out how analog SD video should digitally be represented. It's actually SMPTE-C that outlines the colorspace for SD video (NTSC).

I like your idea as the differences between SMPTE-C and 709 seem negligible (simply looking at the table): http://www.chromapure.com/colorscience-decoding.asp

"SMPTE-C is pretty close to Rec. 709 and most people don't worry with it. That isn't to say you can't see the difference. The main issue is that you can't normally adjust the display devices primaries anyway, and the error in the TV primaries is typically larger than the difference between SMPTE-C and Rec. 709 anyway.": http://forum.doom9.org/showthread.php?t=132745

iWO

2014-12-19 08:09:05 am

laria fresca, vino puro ...

is there any way to set key frame to 5 seconds in yua?

Mystery

2014-12-19 09:20:28 am

Why would you want to?

iWO

2014-12-20 05:17:46 am

laria fresca, vino puro ...

way too often I want to rewind something and it always goes till last key frame
waiting up to 10 seconds is somewhat annoying, especially when you do it often

Mystery

Edit history:

Mystery: 2014-12-20 05:27:53 am

2014-12-20 05:27:07 am

Rewind in what? Normally it shouldn't go to the last keyframe in any program that I know of. Also, as far as I know, 8 (the maximum allowed by x264's default settings on 30 fps) seconds between keyframes is pretty rare. Unless yua changes that setting, of course.
Are you looking to encode something to submit or just for your own use?

iWO

2014-12-20 05:44:28 am

laria fresca, vino puro ...

> Normally it shouldn't go to the last keyframe in any program that I know of

mplayer does, it's very good program but has this 'ability'

> Are you looking to encode something to submit or just for your own use?

own use
I know that submitting policy is strict and not negotiable

Mystery

2014-12-20 05:50:14 am

I mean to say that while some players may have an "ability" to jump to the last keyframe, generally seeking is not "limited" to keyframes, so you should be able to seek anywhere you want.
Anyway, if you want to modify the keyframe interval, I suggest you use handbrake (get choco from chocolately.org and type choco install handbrake).
In handbrake, select your desired crf factor (use your eyes!), your desired preset (I like very fast; it generally provides the best size vs speed tradeoff in my opinion), and be sure to put "keyint=x" in extra options. Select "x" to be seconds * fps to ensure there's a keyframe every x seconds. I like to use 30 because it provides very fast seeking in Full HD videos.

Attachment:

Screenshot 2014-12-20 13.48.01.png

iWO

2014-12-20 06:01:39 am

laria fresca, vino puro ...

handbrake requires .net 4 and won't work under winXP (I installed successfully .net-4 but none of the programs using it started - well, it's time for XP but because I move constantly I can't switch into anything better now, and game I work is working the best under XP - tried under win7 on desktop but it was kinda disaster)

it would be better to switch to linux even than windows7

Mystery

2014-12-20 06:06:58 am

The solution would be to fix your game so that it works with non-legacy systems. If you stick to old operating systems, then you reap what you sow.

iWO

2014-12-22 09:33:57 am

laria fresca, vino puro ...

i tried avidemux and for some incomprehensible reason 2.6+ crashes and I can't even find where exaclty (debugger shows error in main loop of the program which says nothing and pushed more some exception but god knows where... puzzle really) and 2.4.x works but shows green box instead of video preview which makes it unusable

iWO

2014-12-22 09:42:22 am

laria fresca, vino puro ...

game (severance: blade of darkness) is fixable and can run under windows7 but there are problems which make the combination with fraps (other recording progams I tried couldn't do the job - either were too dark or didn't work at all under win7) unusable - with video quality/overall look, usb mouse handling and some other issues which adding up make this combo not an option (and I tried on two different computers and laptop)

Sir VG

2014-12-24 10:41:31 pm

Fucking Weeaboo

Quote from nate:

Quote from Sir VG:

Here's the raw footage.

curious - did you try changefps(last.framerate/4) in avisynth? does that make it play at the wrong speed and that's why you used assumefps()? that *would* be consistent with the framerate being outright wrong in the original.

Using that command drops the reported framerate to ~14 FPS. If I do it with /2 then I get 29.97 FPS. I'm gonna play around with that

I know why it is reporting at 59.94 FPS in the original footage - it's because it's 480i component. It's basically getting Yua to play nice with the footage for encoding.

TheThrillness

2014-12-31 04:32:20 pm

thethrillness.blogspot.com

Forgot to post this up earlier. Discussed it with nate and he said to post here and get opinions.

I'm actually wondering why PC footage (1080p) is set to 1368x768 for IQ. I know in the glossary that's the highest IQ res, but wouldn't it be better to make it 1280x720 so it will be mod16 for both values? With 1368x768, only the 768 conforms to mod16. nate said snow designed this years ago and he kept it for Yua. Based on when snow designed it, this was probably the perfect solution as the common res was probably 1368x768 or very close to it. The norm now though is probably 1080p displays where 1280x720 video would scale better (not to mention conform to proper 16:9 ratio).

It's not so much a problem now but when these 1080p60 cards become more available, do we really want to shrink PS4/XBOne games to 1368x768?

ballofsnow

Edit history:

ballofsnow: 2015-01-02 10:46:31 am

ballofsnow: 2015-01-02 10:31:44 am

2015-01-02 10:30:53 am

*x768; this is the why: https://forum.speeddemosarchive.com/post/anrichan488.html#anrichan488

Mod16: doesn't really matter. More opinions here: http://forum.doom9.org/showthread.php?t=157072 (also points out that 1080p != mod16)

Quote from TheThrillness:

It's not so much a problem now but when these 1080p60 cards become more available, do we really want to shrink PS4/XBOne games to 1368x768?

What exactly is wrong with 768p? 1080p60 would warrant an XQ encode anyway; the solution seems simple: download the XQ/native version.

Personally I don't really care. If the community decides 720p exactness should be the standard again for IQ, then so be it.