yua

2014-02-26 06:10:18 pm

no, yua doesn't know whether there's a statid present. the audio commentary functionality is totally separate from the rest of the program. in fact you could probably even be muxing in audio commentary to random files while yua is busy encoding something else.

puwexil

2014-03-03 09:04:51 am

Professional Second Banana

Feature I'd like to see in a future version of yua: ability to crop by inputting pixel #'s (ie how cropping worked in anri-chan) in addition to via the GUI.

Sir VG

2014-03-06 07:02:01 am

Fucking Weeaboo

Ran across an interesting bug today.

I ripped a DVD using DVD Decrypter, then tried to open the IFO in Yua. It said it couldn't open it. Then after I closed the prompt, virtually all controls were locked out, except for the Tools and Help menu items, and the "Shut Down When Done" checkbox. Everything went back to normal when I closed and reopened Yua though.

Also, I'm still getting a weird audio issues where a portion of the audio from the video I'm encoding gets stuffed into the closing statID. It's not the beginning or the end of the video's audio file, but some portion usually near the end.

ballofsnow

Edit history:

ballofsnow: 2014-03-08 05:18:08 pm

2014-03-08 05:16:48 pm

Quote from TheThrillness:

Do you have any plans to switch to CQP mode for Yua? Primarily the reason being for high resolution and high frame rate source files where even 10,000 Kbps XQ starts to show big degradation.

Quote from nate:

snow, what's your take on this again? personally i'm not very attached to the 10 megabit rate limit for xq. xq i think is a good one to turn into the "max quality" quality. maybe if there becomes too much of a gap between iq and xq, another quality could be added, but i don't see that happening in the next year or two at least. and even then it might make more sense to just "upgrade" the existing qualities all at once for high res/high fps sources, so hq becomes mq, iq becomes hq, xq becomes iq, and then the new quality is called xq.

but for now it seems like raising or eliminating the rate limit on xq can be studied. it's especially convincing to me in the case of 4k f1 video. x264 is good but it's not magic. there's no way 10 megabit is enough for that if you're playing something bright and/or fast-paced.

Quote from TheThrillness:

Yes it's a problem trying to work this out. I guess if you are going to upgrade the qualities you would be making a distinction for HD sources and keeping SD the same?

I guess it's not that far fetched to just leave all qualities the same and just tweak XQ to something like 15,000? People that want a good HD viewing experience can still get IQ at 5,000 but for a no expense spared experience the XQ is where it's at. I do wonder if even 15,000 would be enough for 4K F1 though. Might even need to set 20,000 for that.

I haven't really thought this last idea through but it should cover both SD and HD sources fairly well. You set a CQP for each quality level. Maybe start LQ at 25/26 and continually lower it for each quality until XQ becomes like 18/19? I guess one advantage of this is no need for 2 pass anymore.

Quote from nate:

no bitrate control was considered in the past and abandoned as unworkable due to the wide variety of content sda posts. compare silent hill and a recent sonic game. it's not just for me having to fund the infrastructure either because people might get a 2389238989232893 meg file for mq for a recent sonic game and go "wtf, silent hill mq was like 2 bytes".

Quote from TheThrillness:

Maybe just beef up XQ for now and consider other qualities when x265 is widely adopted? It's already near x264 level: http://chromashift.org/img/x265/comparison_abr_27sep2013.png

Keep bitrate caps but create a new pseudo-archival quality: AQ? AQ would be a CRF only encode, thus no max bitrate. Or maybe CQP would actually make sense here, after all lossless is CQP.

Any thoughts on breaking out 30 vs 60 fps quality versions? For example an HQ30 vs HQ60 and so on? Or keep it "HQ" but allow different bitrate caps? 30 fps could be 100% current bitrate, and allow +33 or +50% for 60 fps qualities.

Also, does anyone think SDA may wind up with too many different *Q versions to the point of confusion? I've always thought of it as LQ/MQ=240p, HQ=480p, IQ=720p, XQ=1080p, but what happens at 1440/1600p and then 2160p? I do like that the *Q affixes are a bit of an abstraction from "240p"->...->"2160p", since for example an IQ encode may not actually be 720p but a 480p with higher bitrate. Maybe just go with a number instead like Q1 = LQ, Q2 = MQ and so on?

Also, I tried out x265 for a bit over at http://forum.doom9.org/showthread.php?t=168814 and I'm not impressed. Still very early though so keeping an eye on it.

[quote="TheThrillness"]Do you have any plans to switch to CQP mode for Yua? Primarily the reason being for high resolution and high frame rate source files where even 10,000 Kbps XQ starts to show big degradation.[/quote][quote="nate"]snow, what's your take on this again? personally i'm not very attached to the 10 megabit rate limit for xq. xq i think is a good one to turn into the "max quality" quality. maybe if there becomes too much of a gap between iq and xq, another quality could be added, but i don't see that happening in the next year or two at least. and even then it might make more sense to just "upgrade" the existing qualities all at once for high res/high fps sources, so hq becomes mq, iq becomes hq, xq becomes iq, and then the new quality is called xq.

but for now it seems like raising or eliminating the rate limit on xq can be studied. it's especially convincing to me in the case of 4k f1 video. x264 is good but it's not magic. there's no way 10 megabit is enough for that if you're playing something bright and/or fast-paced.[/quote][quote="TheThrillness"]Yes it's a problem trying to work this out. I guess if you are going to upgrade the qualities you would be making a distinction for HD sources and keeping SD the same?

I guess it's not that far fetched to just leave all qualities the same and just tweak XQ to something like 15,000? People that want a good HD viewing experience can still get IQ at 5,000 but for a no expense spared experience the XQ is where it's at. I do wonder if even 15,000 would be enough for 4K F1 though. Might even need to set 20,000 for that.

I haven't really thought this last idea through but it should cover both SD and HD sources fairly well. You set a CQP for each quality level. Maybe start LQ at 25/26 and continually lower it for each quality until XQ becomes like 18/19? I guess one advantage of this is no need for 2 pass anymore.[/quote][quote="nate"]no bitrate control was considered in the past and abandoned as unworkable due to the wide variety of content sda posts. compare silent hill and a recent sonic game. it's not just for me having to fund the infrastructure either because people might get a 2389238989232893 meg file for mq for a recent sonic game and go "wtf, silent hill mq was like 2 bytes".[/quote][quote="TheThrillness"]Maybe just beef up XQ for now and consider other qualities when x265 is widely adopted? It's already near x264 level: http://chromashift.org/img/x265/comparison_abr_27sep2013.png[/quote]
Keep bitrate caps but create a new pseudo-archival quality: AQ? AQ would be a CRF only encode, thus no max bitrate. Or maybe CQP would actually make sense here, after all lossless is CQP.

Any thoughts on breaking out 30 vs 60 fps quality versions? For example an HQ30 vs HQ60 and so on? Or keep it "HQ" but allow different bitrate caps? 30 fps could be 100% current bitrate, and allow +33 or +50% for 60 fps qualities.

Also, does anyone think SDA may wind up with too many different *Q versions to the point of confusion? I've always thought of it as LQ/MQ=240p, HQ=480p, IQ=720p, XQ=1080p, but what happens at 1440/1600p and then 2160p? I do like that the *Q affixes are a bit of an abstraction from "240p"->...->"2160p", since for example an IQ encode may not actually be 720p but a 480p with higher bitrate. Maybe just go with a number instead like Q1 = LQ, Q2 = MQ and so on?

Also, I tried out x265 for a bit over at [url]http://forum.doom9.org/showthread.php?t=168814[/url] and I'm not impressed. Still very early though so keeping an eye on it.

Mystery

2014-03-08 09:39:51 pm

Constant quantizer doesn't make sense and never will (except for lossless), but we aren't doing any lossless encodes, are we?
If we would use an archival quality, it would make sense to go with CRF. A factor of 20 or even 21 is pretty much transparent, at least to my eyes. During tests, I saw that a factor of 21 caused some slight blocking in mist (you know, stuff that's hard to compress), but I wouldn't have noticed it unless I had frame advanced while comparing to the encode @ CRF = 20.

Anyway, for the curious, I just did a test on a game @ 1080p60 [settings maxed out] (for the curious, it was the intro of Lords of Shadow 2, PC version). The average bitrate ended up at around 13 MBps. The 30 fps version of the same clip ended up at around 12 MBps. This was all with CRF = 20. The max bitrate, for the curious, was roughly 30 MBps for the 60 fps. See attached picture.
Modern games are pretty demanding regarding bitrate, so if you're going to use bitrate cap, keep that is mind.

Attachment:

Screenshot 2014-03-09 05.37.32.png

ballofsnow

Edit history:

ballofsnow: 2014-03-08 10:25:00 pm

2014-03-08 10:23:03 pm

I doubt SDA will start hosting lossless encodes, so I guess CQP is out.

The CRF being used right now is 17, but somewhere between 17-20 is probably fine.

For bitrate caps, I meant for the average bitrate; this is already in place here since.. forever. I forget if SDA cares about max bitrate (--vbv-maxrate). Probably not if we're not aiming for hardware support...

Is there any place to download 4K/UHD 60 fps gaming samples?? I'm on 1920x1200 native and can extend it to somewhere around 2560x1600 in Nvidia control panel, but extending to 3840x2160 simply doesn't work so I can't make my own recordings.

Mystery

Edit history:

Mystery: 2014-03-09 12:38:22 am

2014-03-09 12:37:14 am

Is it really necessary to start worrying about 4K right now? There are no games (on consoles) that outputs 4K as of now and you need a pretty beefy graphics card (or a couple) to handle 4K gaming on PC. I don't think there has been any game submissions with 4K yet... 1080 seems pretty scarce as it is. I can only do 1080 unfortunately. I have no TV/monitor that supports higher resolutions...

UraniumAnchor

2014-03-09 04:11:56 am

Not a walrus

Even five year old iOS devices can play HQ encodes now so the compatibility options are honestly pretty superfluous at this point.

That said my TV can't play 1080p60fps files, (720p60 or 1080p30 is fine), so there are still some hardware limits in play.

djcj

2014-03-11 09:04:43 am

I've been taking a look again at the whole build process on Linux again.
First of all, I had to add the following line to Yua.pro to make the final linking work: linux-g++-64:LIBS += -lz

Another thing is that, if I'm not mistaken, Yua will be linked with embedded fdk-aac, x264 and libav libraries and with ffmpeg embedded, which already contains the said embedded libraries. I don't know if stripping gets rid of the redundant libraries.

And I wonder if ffmpeg and mp4box really have to be embedded as whole binaries. Shouldn't it instead be possible to just include the libav and gpac libraries without the actual executable binary?

Does Yua itself do the encoding, using the libav libs, or is the video been processed by the internal ffmpeg binary? If it's the latter one, what about making it optional whether you want to link it with embedded ffmpeg or not?
On http://ffmpeg.gusari.org/static/64bit/ you can find to pre-compiled static binaries with x264 and fdk-aac enabled. If it were possible to use those, the whole building process would become much easier (we don't have to worry about ffmeg and x264 to be compatible with each other and don't need to compile everything by hand). Then Yua would use only the nasty_decoder to decode the video (I guess?) and pass the encoding options to either the embedded ffmpeg, or to the systems PATH variable and use the encoder installed on the system.

Well, that's at least the theory, not sure if that really works or not. But many programs can be compiled as either a static single binary, or with shared libraries or the use of external CLI tools enabled.

I've been taking a look again at the whole build process on Linux again.
First of all, I had to add the following line to Yua.pro to make the final linking work: linux-g++-64:LIBS += -lz

Another thing is that, if I'm not mistaken, Yua will be linked with embedded fdk-aac, x264 and libav libraries [b]and[/b] with ffmpeg embedded, which already contains the said embedded libraries. I don't know if stripping gets rid of the redundant libraries.

And I wonder if ffmpeg and mp4box really have to be embedded as whole binaries. Shouldn't it instead be possible to just include the libav and gpac libraries without the actual executable binary?

Does Yua itself do the encoding, using the libav libs, or is the video been processed by the internal ffmpeg binary? If it's the latter one, what about making it optional whether you want to link it with embedded ffmpeg or not?
On http://ffmpeg.gusari.org/static/64bit/ you can find to pre-compiled static binaries with x264 and fdk-aac enabled. If it were possible to use those, the whole building process would become much easier (we don't have to worry about ffmeg and x264 to be compatible with each other and don't need to compile everything by hand). Then Yua would use only the nasty_decoder to decode the video (I guess?) and pass the encoding options to either the embedded ffmpeg, or to the systems PATH variable and use the encoder installed on the system.

Well, that's at least the theory, not sure if that really works or not. But many programs can be compiled as either a static single binary, or with shared libraries or the use of external CLI tools enabled.

nate

2014-03-11 11:36:25 am

the crux of the problem is that yua allows appending and accepts input with nonmonotonic timestamps. i don't know how to use standalone binaries to encode material like that. gpac is the exception. the entire mp4box binary is included because i don't want to figure out how to use it as a library when the commandline options work fine for what yua does. then the ffmpeg binary is included to encode audio commentary iirc. way easier that way than dealing with the ffmpeg api.

djcj

Edit history:

djcj: 2014-03-11 03:13:45 pm

djcj: 2014-03-11 12:54:50 pm

djcj: 2014-03-11 12:54:18 pm

2014-03-11 12:28:18 pm

Quote:

then the ffmpeg binary is included to encode audio commentary iirc. way easier that way than dealing with the ffmpeg api.

You can compile a simple single binary wav-to-aac cli encoder from the fdk-aac source code with these options:
./configure --enable-shared=no --enable-example

The disadvantage is, that it only supports wav as input, but the stripped binary is only 400 KiB small and works fine for me.

edit:

Something else I saw was, that Yua.pro needs libavresample and libswresample. I did a very quick google research and it seems both libs are used for audio resampling, but the libavresample thing is actually from ffmpeg's fork libav/avconv. None of the cpp files seem to include code from libswresample, so I guess I can remove that one from the pro file.

PS: Does the GPL2 license apply to the SDA banner and Yua logos too? I just wonder since they're included and your first post only says that "yua is gpl2".

------------------------------------------

I did some tests and whenever I used an ffmpeg build without libx264 Yua failed to encode the video because it "didn't find the codec". And this happened also when I appended two clips and encoded those. To me it seems as if it always encodes with ffmpeg instead of its own libraries. Huh?

[quote]then the ffmpeg binary is included to encode audio commentary iirc. way easier that way than dealing with the ffmpeg api.[/quote]
You can compile a simple single binary wav-to-aac cli encoder from the fdk-aac source code with these options:
./configure --enable-shared=no --enable-example

The disadvantage is, that it only supports wav as input, but the stripped binary is only 400 KiB small and works fine for me.

edit:

Something else I saw was, that Yua.pro needs libavresample and libswresample. I did a very quick google research and it seems both libs are used for audio resampling, but the libavresample thing is actually from ffmpeg's fork libav/avconv. None of the cpp files seem to include code from libswresample, so I guess I can remove that one from the pro file.

PS: Does the GPL2 license apply to the SDA banner and Yua logos too? I just wonder since they're included and your first post only says that "yua is gpl2".

------------------------------------------

I did some tests and whenever I used an ffmpeg build without libx264 Yua failed to encode the video because it "didn't find the codec". And this happened also when I appended two clips and encoded those. To me it seems as if it always encodes with ffmpeg instead of its own libraries. ???

djcj

Edit history:

djcj: 2014-03-15 02:37:27 am

2014-03-15 02:33:58 am

I found another small mistake:
You forgot to add icon.qrc to the linux ressources. That's why the icon was missing from the task bar and the "about Yua" window.

nate

2014-03-16 10:05:02 pm

interesting. so the icon works if it's compiled with icon.qrc under linux?

djcj

2014-03-17 04:07:20 pm

It works for me:

nate

2014-03-17 05:49:31 pm

wonder how i overlooked that then. thanks for reporting.

Dangerless

Edit history:

Dangerless: 2014-03-17 11:07:51 pm

2014-03-17 11:07:29 pm

Excellent!

nate, rarely when I record and try to render in IQ it'll skip phase 2 and say it's done but it didn't actually do anything. It will record LQ, MQ, HQ fine though.

I've only had it happen twice. If I get another one to occur I'll be sure to upload my raw video footage so you can check it out.

TheThrillness

Edit history:

TheThrillness: 2014-03-17 11:55:09 pm

2014-03-17 11:53:57 pm

thethrillness.blogspot.com

Quote from Dangerless:

nate, rarely when I record and try to render in IQ it'll skip phase 2 and say it's done but it didn't actually do anything. It will record LQ, MQ, HQ fine though.

I've only had it happen twice. If I get another one to occur I'll be sure to upload my raw video footage so you can check it out.

I'm pretty sure that is normal if your source material does not require the (average?) 5,000 bit rate of IQ on the first pass. It's a waste of SDA's hosting bandwidth in that regard.

Granted, it should maybe be decided/modified on a case by case basis if the material is very close to the threshold. Yua skipped my XQ encode because the first pass was like 9,900 (it requires 10,000 to go for an XQ encode). I managed to get an XQ encode from anri though as the x264 used in anri was much older and not as optimized in bit rate as Yua.

nate

2014-03-18 08:21:52 am

if that's really what it is then i believe there is a message about it in the yua console. like "i skipped iq because it wasn't needed" or something like that. so you might check for that.

ballofsnow

Edit history:

ballofsnow: 2014-03-23 03:08:15 pm

ballofsnow: 2014-03-23 03:06:14 pm

2014-03-23 03:05:42 pm

Quote from TheThrillness:

Yua skipped my XQ encode because the first pass was like 9,900 (it requires 10,000 to go for an XQ encode).

That's not how it works, or at least it's not how it should work. Can you double-check on the latest version?

XQ would have been skipped if its video properties were the same as IQ, and IQ maxed out (SDA CRF 17) at equal or below its bitrate cap making XQ redundant.

This is how it works, in principle, yua's process is a bit more efficient.

Scenario A - IQ and XQ have same video properties
1. Encode IQ first pass (CRF 17), result is 4500 kbps
2. Skip IQ second pass because it is already under the 5000 kbps bitrate cap
3. Skip XQ entirely since the result would be exactly that of IQ

Scenario B - IQ and XQ have same video properties
1. Encode IQ first pass (CRF 17), result is 8000 kbps
2. Encode IQ second pass, result is 5000 kbps
3. Encode XQ first pass (CRF 17), result is 8000 kbps
4. Skip XQ second pass because it is already under the 10000 kbps bitrate cap

Scenario C - IQ and XQ have same video properties
1. Encode IQ first pass (CRF 17), result is 12000 kbps
2. Encode IQ second pass, result is 5000 kbps
3. Encode XQ first pass (CRF 17), result is 12000 kbps
4. Encode XQ second pass, result is 10000 kbps

I don't know if nate programmed in tolerances for skipping qualities, i.e. skip/discard XQ if result is 5001 kbps.

[quote="TheThrillness"]Yua skipped my XQ encode because the first pass was like 9,900 (it requires 10,000 to go for an XQ encode).[/quote]
That's not how it works, or at least it's not how it should work. Can you double-check on the latest version?

XQ would have been skipped if its video properties were the same as IQ, and IQ maxed out (SDA CRF 17) at equal or below its bitrate cap making XQ redundant.

This is how it works, in principle, yua's process is a bit more efficient.

Scenario A - IQ and XQ have same video properties
1. Encode IQ first pass (CRF 17), result is 4500 kbps
2. Skip IQ second pass because it is already under the 5000 kbps bitrate cap
3. Skip XQ entirely since the result would be exactly that of IQ

Scenario B - IQ and XQ have same video properties
1. Encode IQ first pass (CRF 17), result is 8000 kbps
2. Encode IQ second pass, result is 5000 kbps
3. Encode XQ first pass (CRF 17), result is 8000 kbps
4. Skip XQ second pass because it is already under the 10000 kbps bitrate cap

Scenario C - IQ and XQ have same video properties
1. Encode IQ first pass (CRF 17), result is 12000 kbps
2. Encode IQ second pass, result is 5000 kbps
3. Encode XQ first pass (CRF 17), result is 12000 kbps
4. Encode XQ second pass, result is 10000 kbps

I don't know if nate programmed in tolerances for skipping qualities, i.e. skip/discard XQ if result is 5001 kbps.

nate

2014-03-23 04:03:33 pm

Code:

        while (!jobs.isEmpty()
                        && output_bitrate < current_job.video.bitrate_kbit
                        && output_bitrate < jobs.at(0).video.bitrate_kbit
                        && jobs.at(0).name != "MQ" && current_job.name != "MQ"
                        && jobs.at(0).video.colorspace == current_job.video.colorspace
                        && jobs.at(0).video.number_of_frames == current_job.video.number_of_frames
                        && jobs.at(0).video.framerate == current_job.video.framerate
                        && jobs.at(0).video.f == current_job.video.f
                        && jobs.at(0).video.interlaced == current_job.video.interlaced
                        && jobs.at(0).video.tff == current_job.video.tff
                        && jobs.at(0).video.height == current_job.video.height
                        && jobs.at(0).video.height_after_cropping == current_job.video.height_after_cropping
                        && jobs.at(0).video.width == current_job.video.width
                        && jobs.at(0).video.width_after_cropping == current_job.video.width_after_cropping
                        ) {
                set_status(tr("The %1 video was renamed to %2 because %1 was not necessary to encode.\n").arg(current_job.name).arg(jobs.at(0).name));
                current_job.name = jobs.at(0).name;
                jobs.removeFirst();
        }

[code]        while (!jobs.isEmpty()
                        && output_bitrate < current_job.video.bitrate_kbit
                        && output_bitrate < jobs.at(0).video.bitrate_kbit
                        && jobs.at(0).name != "MQ" && current_job.name != "MQ"
                        && jobs.at(0).video.colorspace == current_job.video.colorspace
                        && jobs.at(0).video.number_of_frames == current_job.video.number_of_frames
                        && jobs.at(0).video.framerate == current_job.video.framerate
                        && jobs.at(0).video.f == current_job.video.f
                        && jobs.at(0).video.interlaced == current_job.video.interlaced
                        && jobs.at(0).video.tff == current_job.video.tff
                        && jobs.at(0).video.height == current_job.video.height
                        && jobs.at(0).video.height_after_cropping == current_job.video.height_after_cropping
                        && jobs.at(0).video.width == current_job.video.width
                        && jobs.at(0).video.width_after_cropping == current_job.video.width_after_cropping
                        ) {
                set_status(tr("The %1 video was renamed to %2 because %1 was not necessary to encode.\n").arg(current_job.name).arg(jobs.at(0).name));
                current_job.name = jobs.at(0).name;
                jobs.removeFirst();
        }
[/code]

Crow!

2014-03-26 06:03:05 pm

What's that gemma?

I find myself using Anri instead of Yua because it encodes WAY faster. I'm guessing it's because Yua keeps stopping to update the preview (x5 for videos where it asks for the deflicker option) as it encodes the video.

Perhaps there could be a checkbox where you could indicate whether you want Yua to be showing you the preview images as it encodes? Bonus points if you can turn it on and off mid-encode.

nate

2014-03-26 06:33:35 pm

it is true that yua will be slower than anri, significantly slower in some cases, but it's not due to the preview. what are you encoding? input, d/f/nd, qualities?

TheVampire

Edit history:

TheVampire: 2014-03-29 12:40:42 pm

2014-03-29 12:39:20 pm

I have a issue similar to the ones above. I used yua to encode a 720p60fps video, selected just the XQ preset and ended up with a weird bitrate and just 1 pass. Here is a screenshot of the original file that was encoded and the encode itself, or 40 seconds of it to be exact.
https://mega.co.nz/#!x4QyXR4Z!i1IIpcyGCWEg8L1IBfKIwlFgWNNZKLPharCPbtE4dXI

PS: Quality looks fine on the encode, which is surprising considering the relative "low" bitrate.

Mystery

2014-03-29 12:52:50 pm

Quote from TheVampire:

PS: Quality looks fine on the encode, which is surprising considering the relative "low" bitrate.

This is not surprising at all. Yua uses x264's constant quality mode, which decides how many bits each scene needs depending on its complexity.
If the game is mostly static, with no quick motions and not that detailed, then the necessary bitrate won't at all be that high (especially due to reference frames). The less detail the game has and the less quick motion, the less bitrate it uses.
Only one pass is again, not surprising, since that it was x264's constant quality does. 2 passes are only needed the the maximum bitrate is exceeded.

Crow!

2014-04-01 09:02:25 am

What's that gemma?

Quote from nate:

it is true that yua will be slower than anri, significantly slower in some cases, but it's not due to the preview. what are you encoding? input, d/f/nd, qualities?

D4 F1 2D, low/medium/high qualities. Specifically, it's Secret of Mana, in case that matters.