yua

2015-01-11 02:39:21 pm

it's finally that time.

windows
mac
linux
source

can people (especially thrillness) check this yua 8 release candidate to make sure it's handling different colorspace input -> output correctly? again, the wacky input that started this discussion in the first place is here:

http://nate.quandra.org/dffpd-Test.avi

... but it would be good to check with a variety of input since it's a new way of going about handling color now. thanks.

Quote from nate:

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.

it's finally that time.

[url=http://nate.quandra.org/yua/windows/YuaRC.zip]windows[/url]
[url=http://nate.quandra.org/yua/mac/YuaRC.dmg]mac[/url]
[url=http://nate.quandra.org/yua/linux/YuaRC.tar.gz]linux[/url]
[url=http://nate.quandra.org/yua/yua_sourceRC.tar.gz]source[/url]

can people (especially thrillness) check this yua 8 release candidate to make sure it's handling different colorspace input -> output correctly? again, the wacky input that started this discussion in the first place is here:

http://nate.quandra.org/dffpd-Test.avi

... but it would be good to check with a variety of input since it's a new way of going about handling color now. thanks.

[quote="nate"]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.[/quote]

TheThrillness

2015-01-11 04:27:40 pm

thethrillness.blogspot.com

That wacky input file now plays back fine with madVR.

I thought that when you would implement this, it was only going to affect SD material and HD aka native 709 would stay unaffected. It's actually the opposite. I can't detect any real color change with SD material.

I've attached a zip with a HD source screenshot and what version 8 does to the video (skin tone, reds) as well as version 7. I've then shown a source and v8 encode with Yua for Street Fighter 4.

This was confusing me for like 5 minutes straight until I sort of came up with an explanation. I don't think the newest Yua is properly outputting files to 709 and instead setting them to 601. The reason I say this is because the Yua 8 encode that has wrong colors becomes a perfect match to the source if you apply a BT.601 to BT.709 shader in MPC. This sort of explains why SD material never changed.

I think the fix is easy though. Include all 3 VUI settings? http://forum.doom9.org/showthread.php?t=147387

Attachment:

Yua 709 stuff.rar

nate

Edit history:

nate: 2015-01-11 05:24:50 pm

2015-01-11 05:13:57 pm

how sure are you that mpc or whatever you're viewing it in is respecting the 709 flag?

edit: do your sources have any colorspace flag set (i.e. the fourth column in yua's info display)?

TheThrillness

2015-01-12 05:22:59 am

thethrillness.blogspot.com

I'm pretty sure MPC/madVR respects the flag. The players that don't respect the flag like VLC also showed the same issue.

The fourth column in Yua looks to be the key. The videos did not have anything set. I then used UT Video to set my source so it read 709 in the 4th column and it produced correct colors on playback.

nate

2015-01-13 05:50:03 pm

ok, give this one a try.

windows

now yua uses the following algorithm:

1. if the source colorspace standard is specified, use that to decode.
2. if not, and the source is rgb, use rgb to decode.
3. if not, and the source is yuv, use bt601 to decode.

the output colorspace standard is still always bt709 (and marked explicitly as such for supported players to see).

i considered adding a 4. which assumes bt709 if width >= 1184 or height >= 666 (source). but i ended up not doing it because i noticed the fraps test video has bt709 explicitly marked which means it would get 709 anyway and maybe some hd resolution input is actually 601. don't want to erroneously decode 601 stuff as 709. thoughts?

TheThrillness

2015-01-14 05:47:16 am

thethrillness.blogspot.com

Still same issue. I did come across a possible reason as to why this is happening but again I have no idea how you implemented this but maybe it helps.

https://www.doom9.org/showthread.php?p=1662233

Basically a guy with a HD source flags a video with every 709 setting but he is still getting incorrect colors. They tell him it's because x264 uses 601 for the RGB>YUV conversion. Maybe something similar is happening in Yua?

Still don't understand that myself. Like even if it was decoding to 601, I would have though the 709 flags should rectify that.

nate

2015-01-15 07:59:04 am

yeah i'm going to have to do more debugging on this ... can you do me a favor and upload the test vids you are using? thanks.

TheThrillness

2015-01-15 08:37:29 am

thethrillness.blogspot.com

https://drive.google.com/file/d/0B77WilHHzh2za1ZwT1VCXzRqdHc/view?usp=sharing

https://drive.google.com/file/d/0B77WilHHzh2zQ0NNVGRfbUdlaXM/view?usp=sharing

nate

2015-01-17 09:48:14 pm

ok now give this one a try. i activated that hd resolution cutoff for bt709 thing i was talking about since apparently your hd sources are bt709 even though they aren't marked that way as they come. i also have knowledge that other software is doing this so it's not totally unprecedented.

windows

TheThrillness

2015-01-18 07:55:27 am

thethrillness.blogspot.com

Looks perfect to me.

nate

2015-01-18 09:34:41 am

released yua 8.

for posterity, the hd cutoff is (to assume bt709 when no input colorspace standard is marked):

Code:

input width > 1184 AND input height > 666

djcj

2015-01-24 02:58:17 am

I've updated my Github repository with the version 8 changes: https://github.com/darealshinji/yua

Linux binaries (64 bit):
http://www.mediafire.com/download/ko7uzy7x59sk1cr/yua-qt4_amd64.tar.xz
http://www.mediafire.com/download/hxo9mt6vcbb68h6/yua-qt5_amd64.tar.xz

Ubuntu PPA (linked against static libraries): https://launchpad.net/~djcj/+archive/ubuntu/hybrid

presjpolk

2015-01-26 10:36:48 pm

HELLO!

Minor Bug report: on Mac OS with the new version, dragging a file onto the window errors out, and then makes the menus unresponsive. Have to quit and restart to open the menu to open it that way.

Attachment:

Screen Shot 2015-01-27 at 12.28.41 AM.png

J.Y

2015-01-27 01:47:34 am

I encoded a gameboy run (played with SGB2 on a SFC) with the latest version of yua yesterday when I noticed something new. After the HQ file was done, it renamed itself to MQ because it didn't need to be any higher quality than that (forgot to take a picture of it, but said something like that).
After MQ and LQ was done, I tried once more with HQ, and this time it came out as a HQ file, but it was exactly as big as the "converted" MQ file.

Should I just keep MQ and LQ and go with those instead?

Sir VG

2015-01-27 05:20:40 am

Fucking Weeaboo

Quote from J.Y:

I encoded a gameboy run (played with SGB2 on a SFC) with the latest version of yua yesterday when I noticed something new. After the HQ file was done, it renamed itself to MQ because it didn't need to be any higher quality than that (forgot to take a picture of it, but said something like that).
After MQ and LQ was done, I tried once more with HQ, and this time it came out as a HQ file, but it was exactly as big as the "converted" MQ file.

Should I just keep MQ and LQ and go with those instead?

Yes. If a HQ encode doesn't reach a certain threshold, then it will just be a MQ file. And Gameboy games generally aren't going to hit HQ quality ever.

J.Y

Edit history:

J.Y: 2015-01-27 08:05:14 am

2015-01-27 08:04:43 am

Alright, I'll just stick with MQ and LQ then. Thanks!

djcj

2015-01-30 01:16:24 am

Yua can't encode a clip I've recorded in lossless x264. It shows a white clip after opening the video in Yua and when I start encoding it crashes.
I've attached a log and a sample of that clip. I guess I have to convert the clip to raw yuv or something first.

Attachments:

log.txt

test.mkv

puwexil

2015-01-31 01:30:10 pm

Professional Second Banana

Got an RGB-modded SNES recently and am now working on getting set up for recording/encoding. Yua's statid looks to be built based on the raw's native resolution (720x240 in this case), which then looks pretty bad after I set the 4:3 aspect ration. Is there a way to force a 4:3 statid as well?

Sir VG

2015-01-31 10:35:27 pm

Fucking Weeaboo

Quote from puwexil:

Got an RGB-modded SNES recently and am now working on getting set up for recording/encoding. Yua's statid looks to be built based on the raw's native resolution (720x240 in this case), which then looks pretty bad after I set the 4:3 aspect ration. Is there a way to force a 4:3 statid as well?

Yeah, I've had that same issue with encoding my Legend of Mana runs, since PS1 outputted with component is 240p/60. I'm pretty sure I've spoke up before about it, but can't remember what the response was.

TheThrillness

2015-02-01 06:26:33 am

thethrillness.blogspot.com

dj, definitely need nate to look at that.

puwexil, I think this is a bug that nate never fixed. Best to just line double in AmaRec for future sources: https://forum.speeddemosarchive.com/post/blurry_statid_with_rgb.html

nate

2015-02-03 06:39:02 pm

Quote from presjpolk:

Minor Bug report: on Mac OS with the new version, dragging a file onto the window errors out, and then makes the menus unresponsive. Have to quit and restart to open the menu to open it that way.

gaaaaaaaaaaah i am going to have to do another release once qt 5.4.1 hits. i actually knew about this but forgot about it because i run 10.8 on my home machine which it apparently doesn't affect. so fucking annoying.

Quote from djcj:

Yua can't encode a clip I've recorded in lossless x264. It shows a white clip after opening the video in Yua and when I start encoding it crashes.
I've attached a log and a sample of that clip. I guess I have to convert the clip to raw yuv or something first.

afaik matroska input is not and has never been supported. don't ask me why. --> ffmpeg

Quote from puwexil:

Got an RGB-modded SNES recently and am now working on getting set up for recording/encoding. Yua's statid looks to be built based on the raw's native resolution (720x240 in this case), which then looks pretty bad after I set the 4:3 aspect ration. Is there a way to force a 4:3 statid as well?

yeah this is known as thrillness said. iirc i actually knew about it while i was writing statid but i considered it too difficult to implement. maybe some day.

[quote="presjpolk"]Minor Bug report: on Mac OS with the new version, dragging a file onto the window errors out, and then makes the menus unresponsive. Have to quit and restart to open the menu to open it that way.[/quote]
gaaaaaaaaaaah i am going to have to do another release once qt 5.4.1 hits. i actually knew about this but forgot about it because i run 10.8 on my home machine which it apparently doesn't affect. so fucking annoying.

[quote="djcj"]Yua can't encode a clip I've recorded in lossless x264. It shows a white clip after opening the video in Yua and when I start encoding it crashes.
I've attached a log and a sample of that clip. I guess I have to convert the clip to raw yuv or something first.[/quote]
afaik matroska input is not and has never been supported. don't ask me why. --> ffmpeg

[quote="puwexil"]Got an RGB-modded SNES recently and am now working on getting set up for recording/encoding.  Yua's statid looks to be built based on the raw's native resolution (720x240 in this case), which then looks pretty bad after I set the 4:3 aspect ration.  Is there a way to force a 4:3 statid as well?[/quote]
yeah this is known as thrillness said. iirc i actually knew about it while i was writing statid but i considered it too difficult to implement. maybe some day.

djcj

2015-02-06 10:26:35 am

It seems that Yua has trouble displaying the correct time of video input with drop frames. It shows a time of 37 seconds for this clip, but the actual length is 50 seconds. And the final encoded video has 50 seconds too.

Attachment:

Bildschirmfoto-Yua - neu.avi.png

nate

2015-02-08 01:13:58 pm

that's correct.

yua uses a different method of generating timestamps for supported keyframe-only formats (e.g. huffyuv, lagarith) that may actually be accurate.

djcj

2015-02-20 12:27:19 pm

Yua has command line options to set things like qualities or output folder, but it doesn't have a command line option to autmatically start encoding or close the app after succesfully encoding all videos, right? Would it be difficult to implement this? Because that would make batch encoding very easy.

nate

2015-02-23 08:41:21 am

not sure what you mean. i write scripts that batch encode all the time. one example:

Code:

perl -we 'for(<*.avi>){s/\.avi//; `yua --input=$_.avi --qualities=h --output-basename=$_`}'

encode all .avi files in this directory to hq.