yua

2014-04-08 12:12:19 am

Might be magic...

Quote from ballofsnow:

You guys need to actually test this stuff. It's not the %, it's the colon. Try renaming a file in windows, as soon as you attempt a ":" it gives an error, so of course you won't be able to output a file like that.

From memory, a "%" sign in windows command line or batch file indicates a variable name. The percent sign may also need to be escaped (by using two percent signs in a row "%%") in some cases.

bos

2014-04-08 06:05:04 am

Yep, and that was annoying in Anri. Yua doesn't seem to have the same problem which is great. In either program, can't get around the real invalid characters in windows: \ / : * " < > |

nate

2014-04-08 03:59:53 pm

Quote from sinister1:

Quote from nate:

can you upload it?

See attached. All I did was open Yua.exe and then File > Open > (.vob file Anri ripped from my DVD). Let me know if there is more I am supposed to do there. I could just be super dumb and missed an obvious step. Thanks.

sorry, i meant the vob itself.

snow:

Code (field input validator for yua 7):

QRegExp("[\\w_\\- ]+")

djcj

Edit history:

djcj: 2014-04-11 06:37:37 am

2014-04-11 06:37:03 am

Can you add a configurable option into your source code that allows one to use the system's mp4box and ffmpeg (or preferably fdk-aac's aac-enc) instead of embedded ones? I was thinking about something like this:

Code:

#ifdef USE_SYSTEM_BINARIES
        system("MP4Box " mp4box_args);  /* it doesn't seem to work exactly this way, but I think you know what I mean */
#else
        audio_commentary_muxer_process.start(resource_pathname["mp4box"], mp4box_args);
#endif

This option can be given i.e. as config.h or maybe added to Yua.pro. Or you're using a Yua.pro.in template file and a small configure script will add this option if needed. Such a script could also be used to automatically add all the helper resources. It could also add custom paths to the required static libraries.

nate

2014-04-13 12:00:38 pm

you're welcome to do that yourself of course but i'm not going to support it. i wouldn't worry about having to maintain your own fork of the code because i see yua development as more or less finished at this point. there will be additional versions released but it will be stuff you don't care about like input validation in the output basename field.

Hatespark

2014-04-15 12:13:10 pm

Hi there everyone,

i have some trouble with yua.
If u render my movie, then i have a SOUND-Delay - i mean the sound comes 2 seconds after the movie (sorry for my bad english).

Can somebody help me please??

Greetings

Nicky

nate

2014-04-17 02:46:39 pm

if it's the same delay the whole time then it will probably not be hard to fix. yua can't do it right now but you can maybe use virtualdub. what is your source file? lagarith .avi? or dvd or something?

Hatespark

2014-04-18 07:57:14 am

Quote from Hatespark:

Hello Nate,

i capture with Elgato from my PS3 - its a MP4 File - and it is always the same Delay.
I just tried Virtual Dub but i doesnt support MP4 Files ;(

I tried it again with a avi File but the delay is the same :*(

nate

2014-04-21 05:16:33 pm

mp4 is harder. you can install a codec pack such as the cccp, then load the video in an avisynth script like this:

Code:

directshowsource("your.mp4")
delayaudio(5.5)

to make the audio delayed e.g. 5.5 seconds. then you can load this avisynth script in virtualdub and select the lagarith codec and save as a new avi which you can then load in yua.

more info: https://kb.speeddemosarchive.com/AviSynth#Constant_audio_desync

TheThrillness

2014-04-27 10:51:22 am

thethrillness.blogspot.com

Kudos on supporting 4:4:4 encoding for RGB sources. However, there seems to be some discrepancies between the RGB source file and the RGB encode file (specifically with the red colour). The encoded RGB file isn't properly reproducing what the RAW RGB colors are giving it. In fact, the Encode RGB seems to have colors comparable to the YUY2. YUY2 Raw to YUY2 Encode is fine so I can only assume this is a problem with x264 encoding RGB into YUV 4:4:4?

Attachment:

RGBandYUY2Screens.zip

djcj

2014-04-28 09:50:57 am

@TT: I guess that's normal. yuv 4:4:4 is still yuv and not RGB, and of course h264 is a lossy format. I don't know if Lossles x264 supports true RGB, but you don't want to encode a lossless video (its hueg). Supporting 10 bit x264 might be an idea*, but the quality increasement is only slightly higher than 8 bit.

*Could be supported via two static libraries with different names. But I don't think libav will support it without some hacking.

bos

2014-04-28 10:27:01 am

Are RGB encodes allowed on SDA? If Yua doesn't support it, you could still do it yourself via whatever toolchain you prefer, i.e. avisynth, x264, mp4box.

TheThrillness

2014-04-28 11:08:01 am

thethrillness.blogspot.com

Yeah I just selected the RGB mode in x264vfw with CQP and it was identical to the Raw RGB colour. The same issue in Yua happens in VirtualDub if you select YUV 4:4:4 to send to the compressor. I guess it really is just YUV to RGB (although I expected it to be far closer than that).

Regardless I can see very few issues for capturing RGB (encode filesizes are huge!). YUY2 is good enough.

nate

2014-05-02 08:24:49 am

yeah, i wasn't able to figure out how to encode rgb with ffmpeg, so it's yuv444. i'm glad to see it's probably not even noticeable except with a side-by-side comparison.

Cauptain

2014-05-03 10:43:22 pm

To open any AVI/MPG/WMV/MOV/MP4/MKV/TS/MTS/*.* in Virtualdub just download plugins32 complete pack. No more avisynth script.

Download pack here: http://goo.gl/T8fvEs

Extract to Virtualdub root folder.

Claudio

TheThrillness

2014-05-06 01:04:56 pm

thethrillness.blogspot.com

A new bug. If your raw capture has no audio (aka silence) and then you encode it in Yua, you get this really loud noise. Encoding the same video from say x264vfw in VirtualDub does not have this buzzing. See attached encode for what I mean. I can give the source if you need it.

Attachment:

blackmagic_IQ.mp4

nate

2014-05-12 04:02:43 pm

yeah, that's because it normalized the near-silence. it's kind of not a common use case since audio is required for submission to sda. for personal use you could always remove the silent audio track before opening it in yua (i believe encoding without an audio track actually works - it warns you "no audio track found!" but it produces good output if you encode). or remove the nasty audio track afterward from the output using mp4box.

TheThrillness

2014-06-23 07:20:10 am

thethrillness.blogspot.com

Any idea what is wrong with this .ts file nate? It is reported as 59.94 in MediaInfo (as it should be) but if I choose to encode it in Yua at F2 it'll give me 12.011 fps in MediaInfo and when imported it says the file is 119.88 fps in Yua! If I choose to encode it at F1 I get 24.0 fps in MediaInfo.

Attachment:

testforyua.ts

nate

2014-06-23 09:37:05 am

i'm hoping support for reading a lot of transport streams will be better once i update the version of ffmpeg in yua. it's pretty bad right now and the fact that you can find files that are butchered like that does not surprise me. i have some hope because the version of ffmpeg in yua currently is over a year old and improvements are made all the time.

for me, standard procedure when encoding files like that as sources for sda runs is to first dump nmf using this command:

Code:

ffmpeg -i "$_" -c:v ffvhuff -c:a pcm_s16le -y nmf-"$basename".avi

note that the use of the cli ffmpeg there does not necessarily imply that things would be better in yua. the problem is seeking. when running ffmpeg like in the above command, it never has to seek, whereas yua basically does. i could add a non-seeking mode but it would be incredibly awkward and mostly useless, e.g. the preview wouldn't work or would take 15 minutes (no exaggeration) to respond to user input.

the main holdup on a new release of yua right now is getting a static compile of qt for windows. with qt 5 support for static compiling took a hit and windows is always the most squirrely of the platforms you know. i need a static compile in order for yua to continue to be a standalone .exe and not a folder full of files.

i'm hoping support for reading a lot of transport streams will be better once i update the version of ffmpeg in yua. it's pretty bad right now and the fact that you can find files that are butchered like that does not surprise me. i have some hope because the version of ffmpeg in yua currently is over a year old and improvements are made all the time.

for me, standard procedure when encoding files like that as sources for sda runs is to first dump nmf using this command:
[code]ffmpeg -i "$_" -c:v ffvhuff -c:a pcm_s16le -y nmf-"$basename".avi[/code]
note that the use of the cli ffmpeg there does not necessarily imply that things would be better in yua. the problem is seeking. when running ffmpeg like in the above command, it never has to seek, whereas yua basically does. i could add a non-seeking mode but it would be incredibly awkward and mostly useless, e.g. the preview wouldn't work or would take 15 minutes (no exaggeration) to respond to user input.

the main holdup on a new release of yua right now is getting a static compile of qt for windows. with qt 5 support for static compiling took a hit and windows is always the most squirrely of the platforms you know. i need a static compile in order for yua to continue to be a standalone .exe and not a folder full of files.

TheThrillness

2014-06-25 08:26:46 pm

thethrillness.blogspot.com

That's cool. Just do what you gotta do.

I actually have another request but I don't know if there is enough demand. Some USB2 capture cards from AVerMedia/Elgato are setting SD capture with 709 values (either they assign --colorprim, --transfer or --colormatrix to bt709). Any good media player like MPC uses these (VLC will not). I'd like Yua to ensure the proper value is being assigned based on resolution to the final encodes (the Yua encode still shows it as 709 but it gets decoded inside Yua at 601).

If I recall it should just be anything equal to or less than 576p, set it to 601. Anything over that is 709.

If you want to test this here is an Elgato sample with transfer characteristics set to 709.

Attachment:

bt709sdfile.mp4

nate

2014-06-25 09:23:03 pm

ok, thanks. there may actually be support for this in ffmpeg since you're saying it's decoding it differently. so yua should convert sd 709 input to 601 output basically? and also presumably convert hd 601 input to 709 output but that's less common of a problem right now?

TheThrillness

Edit history:

TheThrillness: 2014-06-26 12:24:54 am

2014-06-25 09:31:07 pm

thethrillness.blogspot.com

Quote from nate:

so yua should convert sd 709 input to 601 output basically?

Yip. For every HD card I have, they all treat HD as 709 so it's only SD we have to worry about.

Edit: The actual problem with HD content (specifically consoles) is much harder to fix on a wider scale. I've noticed that the most popular HDMI card (AVerMedia H727) will only accept 0-255 (originally I and many others thought they were looking for 16-235). If you feed them a 16-235 source, it just looks washed out (although still pretty decent I have to say). Of course the solution here is to capture 0-255 but if your TV does not have 0-255 support (like mine), then you are always going to be playing with an incorrect picture.

I only actually noticed this because the Elgato Game Capture HD I got last week actually processes correct 16-235 and 0-255 values (you choose it in the software). The 0-255 capture from that device looks like the AVerMedia C027 (which confirms it is looking for 0-255... of course you set the console to output Full). I definitely want to look at my other DS cards in more detail to see which ones are fine and which aren't. Now I think about it, the second most popular card (Blackmagic) should be fine since it expects YCbCr and that can only ever be limited range anyway. The third most popular is probably PEXHDCAP and that has a driver control for 0-255/16-235 so we might not be in as much trouble as I previously thought. I guess it's just educating users on HD capture... I smell another guide coming on... hehe. Anyway, I'm just rambling on... I'll stop now lol.

[quote="nate"]so yua should convert sd 709 input to 601 output basically?[/quote]

Yip. For every HD card I have, they all treat HD as 709 so it's only SD we have to worry about.

Edit: The actual problem with HD content (specifically consoles) is much harder to fix on a wider scale. I've noticed that the most popular HDMI card (AVerMedia H727) will only accept 0-255 (originally I and many others thought they were looking for 16-235). If you feed them a 16-235 source, it just looks washed out (although still pretty decent I have to say). Of course the solution here is to capture 0-255 but if your TV does not have 0-255 support (like mine), then you are always going to be playing with an incorrect picture.

I only actually noticed this because the Elgato Game Capture HD I got last week actually processes correct 16-235 and 0-255 values (you choose it in the software). The 0-255 capture from that device looks like the AVerMedia C027 (which confirms it is looking for 0-255... of course you set the console to output Full). I definitely want to look at my other DS cards in more detail to see which ones are fine and which aren't. Now I think about it, the second most popular card (Blackmagic) should be fine since it expects YCbCr and that can only ever be limited range anyway. The third most popular is probably PEXHDCAP and that has a driver control for 0-255/16-235 so we might not be in as much trouble as I previously thought. I guess it's just educating users on HD capture... I smell another guide coming on... hehe. Anyway, I'm just rambling on... I'll stop now lol.

TheThrillness

2014-07-01 05:52:35 am

thethrillness.blogspot.com

Actually nate, scrap that 709 > 601 idea. It looks to be an issue with EVR CP (where graphic drivers mess up the colors). It seems if you use madVR for everything, the quality is fine (as it's independent of any graphic driver changes). I guess it can't hurt to directly specify the tags but don't worry about it.

nate

2014-07-01 06:20:50 pm

ok, if you say so.

nate

2014-07-06 05:45:32 pm

thrillness, thanks for pointing this out. it actually helped me find two (count em) distinct issues. while working on those i found and fixed a third (regarding the colorspace standard, which you had also mentioned recently).

full color range input was not handled correctly. yua assumed mpeg (16..235) range for everything. fraps is a little cock and writes full range yuv for no apparent reason. now yua detects jpeg (full) range input and converts to the correct (mpeg) range before encoding.
full color range ("jpeg") input colorspaces were not understood at encoding time, so for example 4:2:0 input was incorrectly converted to 4:4:4 for the higher qualities. this is what led directly to the extreme aliasing you noticed in the iq encode.
following from the above, something was wrong with yua's color format conversion from subsampled chroma to full res chroma. specifically that horrible aliasing. i had suspected this for a long time but i was told it was normal. well it turns out it's possible to do a better job. thanks to reading the source code of ffms2 i can now provide better conversion in yua. this should increase the output quality of all chroma subsampled input (everything that isn't yuv 4:4:4 or rgb).

so obviously this is a big deal and now i need to do a release asap. i also need you to help me test, especially with the colorspace standard (709 vs 601) stuff since i'm not totally sure i got it right. i added a display of the colorspace standard if yua detects it in the info line which may help (can see it in the second picture below).

i have to prepare a new vm for compiling qt static. not sure when i will get to that since the weekend is almost over and i'm traveling most of next week. but hopefully i will have a test build for you sooner rather than later.

thrillness, thanks for pointing [url=https://forum.speeddemosarchive.com/post/quality_test__teslagrad_pc_2.html]this[/url] out. it actually helped me find two (count em) distinct issues. while working on those i found and fixed a third (regarding the colorspace standard, which you had also mentioned recently).
[ol]
[li]full color range input was not handled correctly. yua assumed mpeg (16..235) range for everything. fraps is a little cock and writes full range yuv for no apparent reason. now yua detects jpeg (full) range input and converts to the correct (mpeg) range before encoding.[/li]
[li]full color range ("jpeg") input colorspaces were not understood at encoding time, so for example 4:2:0 input was incorrectly converted to 4:4:4 for the higher qualities. this is what led directly to the extreme aliasing you noticed in the iq encode.[/li]
[li]following from the above, something was wrong with yua's color format conversion from subsampled chroma to full res chroma. specifically that horrible aliasing. i had suspected this for a long time but i was told it was normal. well it turns out it's possible to do a better job. thanks to reading the source code of ffms2 i can now provide better conversion in yua. this should increase the output quality of all chroma subsampled input (everything that isn't yuv 4:4:4 or rgb).[/li]
[/ol]
so obviously this is a big deal and now i need to do a release asap. i also need you to help me test, especially with the colorspace standard (709 vs 601) stuff since i'm not totally sure i got it right. i added a display of the colorspace standard if yua detects it in the info line which may help (can see it in the second picture below).

i have to prepare a new vm for compiling qt static. not sure when i will get to that since the weekend is almost over and i'm traveling most of next week. but hopefully i will have a test build for you sooner rather than later.

Attachments:

Screen Shot 2014-07-06 at 2.02.55 PM.png

Screen Shot 2014-07-06 at 5.54.49 PM.png

teslagrad_IQ.mp4