yua

2013-02-11 10:29:31 am

For the resolutions, what did you have in mind in terms of bounding boxes for the various qualities? Maximum width; maximum height; or enforce maximum on both (don't like this one..)?

Your code is setting a certain width, and changing the height based on aspect ratio. Anri does the inverse: sets the height and width depends. I think it will be a lot easier doing it this way, especially when you start getting into x264 SAR which will affect width and not height.

nate

2013-02-11 10:32:12 am

Quote from Terribleno:

While I'm not ballofsnow, I looked at it and wrote comments based on if I believe I'm reading this correctly. I'm probably not, though, since I haven't done C++ in about 2 years:

Code:

void Yua::set_sizes() {
        native_width = original_native_width;  // set width to the source file's width?
        native_height = original_native_height;  // set height to the source file's height?
        native_aspect_ratio = (double)native_height / (double)native_width;  // set our aspect ratio now, in case of a progressive source, but...

        if (interlaced_button->isChecked() && native_height <= 576 + 8) { //analog tv (20130123)
                native_width = 640;
                native_height = 480;
                native_aspect_ratio = 3.0/4.0;  // ...we overwrite what aspect ratio was based on computation earlier, but ONLY if it's interlaced
                if (widescreen_button->isChecked()) {
                        native_height = 360;
                        native_aspect_ratio = 9.0/16.0;  // ...we overwrite what aspect ratio was based on computation earlier, but ONLY if it's interlaced
                }
                if (d4_button->isChecked()) {  // D4 is half resolution, so...
                        native_width /= 2;
                        native_height /= 2;  // cut the resolution in half
                }
        } else if (d4_button->isChecked()) {  // at first I misread this and thought this would always execute if the previous D4 did, but luckily I reread the code and recognized "else if"
                native_width = 320;
                native_height = 240;
                if (widescreen_button->isChecked()) {
                        native_height = 180;
                }
        }

        lq_width = 320;
        mq_width = 320;
        hq_width = 640;
        if (hq_width > native_width) hq_width = native_width;  // 640 if D1, 320 if D4
        iq_width = 1280;
        if (iq_width > native_width) iq_width = native_width;  // > 1280 if D1, N/A if D4

				// take the width values we just set, and round them up; however, it seems as though only high quality and insane quality will possibly be affected.
        lq_width = round_up_to_mod_4(lq_width);  // this should always be 320?
        mq_width = round_up_to_mod_4(mq_width);  // this should always be 320?
        hq_width = round_up_to_mod_4(hq_width);
        iq_width = round_up_to_mod_4(iq_width);

        lq_height = round_up_to_mod_4(lq_width * native_aspect_ratio);
        mq_height = round_up_to_mod_4(mq_width * native_aspect_ratio);
        hq_height = round_up_to_mod_4(hq_width * native_aspect_ratio);
        iq_height = round_up_to_mod_4(iq_width * native_aspect_ratio);

        xq_width = round_up_to_mod_4(native_width);
        xq_height = round_up_to_mod_4(xq_width * native_aspect_ratio);

				//  force set low, medium, and high qualities, since they are defaults
        lq_button->setChecked(true);
        mq_button->setChecked(true);
        hq_button->setChecked(true);
        iq_button->setChecked(false);  // uncheck insane quality for now
        xq_button->setChecked(false);  // uncheck extreme quality for now
        if (native_width > 640) {
                iq_button->setChecked(true);  // set insane quality only if the width is greater than 640, do most DVD recorders at highest quality do 720?
                if (native_width > 1280) {
                        xq_button->setChecked(true);  // set extreme quality only if the width is greater than 1280, should this be greater than or equal to?
                }
        }


        preview_size = QSize(native_width, native_height);
        emit set_preview_size(preview_size.width(), preview_size.height());
        return process_current_image();
}

i think we may have had a misunderstanding here - i actually wrote that set_sizes() function, so i'm pretty sure i know what it's doing. the problem is that anri currently handles aspect ratio in a more intelligent way, and i need snow to basically tutor me on that because i'm too dumb to understand the anri source, especially when it actually resizes the input in the avisynth output files. that set_sizes() is just my first shot at it. it probably does the right thing in a lot of cases, but i need yua to be as good or better than anri.

snow: so you're saying i should calculate the width from the height? the reason i calculate the height from the width (the reason i wrote it that way as a first try) is that there is at least one width that is really nasty ... i think it's the 16:9 width for 480 pixels height. or do you just always round up to mod 4, ignoring the slight aspect ratio error, and that solves it? or do you actually still set the dar using mp4box?

[quote="Terribleno"]
While I'm not ballofsnow, I looked at it and wrote comments based on if I believe I'm reading this correctly. I'm probably not, though, since I haven't done C++ in about 2 years:
[spoiler][code]void Yua::set_sizes() {
        native_width = original_native_width;  // set width to the source file's width?
        native_height = original_native_height;  // set height to the source file's height?
        native_aspect_ratio = (double)native_height / (double)native_width;  // set our aspect ratio now, in case of a progressive source, but...

if (interlaced_button->isChecked() && native_height <= 576 + 8) { //analog tv (20130123)
                native_width = 640;
                native_height = 480;
                native_aspect_ratio = 3.0/4.0;  // ...we overwrite what aspect ratio was based on computation earlier, but ONLY if it's interlaced
                if (widescreen_button->isChecked()) {
                        native_height = 360;
                        native_aspect_ratio = 9.0/16.0;  // ...we overwrite what aspect ratio was based on computation earlier, but ONLY if it's interlaced
                }
                if (d4_button->isChecked()) {  // D4 is half resolution, so...
                        native_width /= 2;
                        native_height /= 2;  // cut the resolution in half
                }
        } else if (d4_button->isChecked()) {  // at first I misread this and thought this would always execute if the previous D4 did, but luckily I reread the code and recognized "else if"
                native_width = 320;
                native_height = 240;
                if (widescreen_button->isChecked()) {
                        native_height = 180;
                }
        }

lq_width = 320;
        mq_width = 320;
        hq_width = 640;
        if (hq_width > native_width) hq_width = native_width;  // 640 if D1, 320 if D4
        iq_width = 1280;
        if (iq_width > native_width) iq_width = native_width;  // > 1280 if D1, N/A if D4

// take the width values we just set, and round them up; however, it seems as though only high quality and insane quality will possibly be affected.
        lq_width = round_up_to_mod_4(lq_width);  // this should always be 320?
        mq_width = round_up_to_mod_4(mq_width);  // this should always be 320?
        hq_width = round_up_to_mod_4(hq_width);
        iq_width = round_up_to_mod_4(iq_width);

lq_height = round_up_to_mod_4(lq_width * native_aspect_ratio);
        mq_height = round_up_to_mod_4(mq_width * native_aspect_ratio);
        hq_height = round_up_to_mod_4(hq_width * native_aspect_ratio);
        iq_height = round_up_to_mod_4(iq_width * native_aspect_ratio);

xq_width = round_up_to_mod_4(native_width);
        xq_height = round_up_to_mod_4(xq_width * native_aspect_ratio);

//  force set low, medium, and high qualities, since they are defaults
        lq_button->setChecked(true);
        mq_button->setChecked(true);
        hq_button->setChecked(true);
        iq_button->setChecked(false);  // uncheck insane quality for now
        xq_button->setChecked(false);  // uncheck extreme quality for now
        if (native_width > 640) {
                iq_button->setChecked(true);  // set insane quality only if the width is greater than 640, do most DVD recorders at highest quality do 720?
                if (native_width > 1280) {
                        xq_button->setChecked(true);  // set extreme quality only if the width is greater than 1280, should this be greater than or equal to?
                }
        }

preview_size = QSize(native_width, native_height);
        emit set_preview_size(preview_size.width(), preview_size.height());
        return process_current_image();
}[/code][/spoiler][/quote]
i think we may have had a misunderstanding here - i actually wrote that set_sizes() function, so i'm pretty sure i know what it's doing. the problem is that anri currently handles aspect ratio in a more intelligent way, and i need snow to basically tutor me on that because i'm too dumb to understand the anri source, especially when it actually resizes the input in the avisynth output files. that set_sizes() is just my first shot at it. it probably does the right thing in a lot of cases, but i need yua to be as good or better than anri.

snow: so you're saying i should calculate the width from the height? the reason i calculate the height from the width (the reason i wrote it that way as a first try) is that there is at least one width that is really nasty ... i think it's the 16:9 width for 480 pixels height. or do you just always round up to mod 4, ignoring the slight aspect ratio error, and that solves it? or do you actually still set the dar using mp4box?

ballofsnow

Edit history:

ballofsnow: 2013-02-11 10:44:12 am

ballofsnow: 2013-02-11 10:43:19 am

ballofsnow: 2013-02-11 10:42:26 am

2013-02-11 10:42:04 am

Indeed, 480 gets you ~853, rounding up to 856; 3 pixel width! Anri uses addborders when it can to avoid too much stretching. It's pretty funky code... e.g.:

last.width %% 4 <> 0 ? AddBorders(floor((4 - last.width %% 4) / 2.), 0, ceil((4 - last.width %% 4) / 2.), 0) : NOP

That ends up adding whatever it can on left and right side of video to get to mod4.

Don't use mp4box DAR, it's not reliable. x264 SAR is quite awesome.

nate

2013-02-11 10:44:28 am

ok, i totally missed where you were padding the width. that makes more sense now. but what's this about x264 --sar? if you pad the width then where's the need to tell the encoder anything?

ballofsnow

Edit history:

ballofsnow: 2013-02-11 10:52:48 am

ballofsnow: 2013-02-11 10:52:29 am

ballofsnow: 2013-02-11 10:51:19 am

2013-02-11 10:49:54 am

To preface, they use the term SAR in x264 which is confusing since I think it should actually be called PAR for pixel aspect ratio.. So when I mention SAR with x264, I mean PAR.

SAR (PAR) is just for stuff like DVD 720x480 with 16x9 flag. Ends up with 720x480 (3:2) sample aspect ratio, with a pixel aspect ratio of 1.##:1, ending up with a display aspect ratio of 16x9.

It's also been useful on weird dvd recordings where the sample aspect ratio is ~320x480 (instead of typical 720x480) but still with the intention of displaying as 4:3.

I think if all this is too annoying to code, maybe forget aspect ratios and simple set a hard resolution.

man I edit too much

nate

2013-02-11 11:00:21 am

so you don't resize *or* pad in avisynth at all if the input is 720x480 and just pass --sar 640:480 to x264 and that handles it correctly in a way that is compatible? reason i ask is resizing with yua before it gets to x264 is really no problem ... i was more curious about how to handle progressive scan input. right now i don't let the user set the aspect ratio at all. the ui is hidden when you switch to progressive mode and in that set_sizes() it just assumes the input is already correct. the problem is that i think in 99% of cases, it is correct, because why the hell would screen capture and stuff like that not have par == dar. so i don't want people seeing the ui and going "uh oh, what is this" when 99% likely it's irrelevant to them.

thinking more about it now i think it's better to set the width from the height and pad than to set the height from the width like i'm doing because in analog tv the one thing you do have is vertical resolution. i really shouldn't be throwing that away for widescreen analog stuff. so that at least will be changed in alpha 2.

so you don't resize *or* pad in avisynth at all if the input is 720x480 and just pass --sar 640:480 to x264 and that handles it correctly in a way that is compatible? reason i ask is resizing with yua before it gets to x264 is really no problem ... i was more curious about how to handle progressive scan input. right now i don't let the user set the aspect ratio at all. the ui is hidden when you switch to progressive mode and in that set_sizes() it just assumes the input is already correct. the problem is that i think in 99% of cases, it is correct, because why the hell would screen capture and stuff like that not have par == dar. so i don't want people seeing the ui and going "uh oh, what is this" when 99% likely it's irrelevant to them.

thinking more about it now i think it's better to set the width from the height and pad than to set the height from the width like i'm doing because in analog tv the one thing you do have is vertical resolution. i really shouldn't be throwing that away for widescreen analog stuff. so that at least will be changed in alpha 2.

ballofsnow

Edit history:

ballofsnow: 2013-02-11 11:14:34 am

ballofsnow: 2013-02-11 11:12:00 am

ballofsnow: 2013-02-11 11:11:39 am

ballofsnow: 2013-02-11 11:11:16 am

2013-02-11 11:10:18 am

720x480 with 4:3 flag actually does get width-resized down to 640x480 sample aspect ratio. The idea here is to not have to spend bitrate on what you don't need. 720x480 -> DAR 640x480 = 80x480 pixels removed, not being encoded. 720x480 -> DAR 856x480, no pixels added, no bitrate spent.

Don't confuse SAR, PAR, and DAR. SAR is the actual resolution of the video. PAR is the aspect ratio of the pixels, so a square pixel is 1:1. DAR is what you want it to look like in your video player.

640x480 with intent to display at 640x480 is easy. SAR = 640x480, PAR = 1:1. DAR is the multiplication of SAR and PAR which results in 640x480.
640x480 with intent to display at 1280x480. SAR = 640x480, PAR = 2:1. DAR is the multiplication of SAR and PAR which results in 1280x480.

The last example was.. just an example, didn't feel like doing the math for PAR on a 16x9.

nate

Edit history:

nate: 2013-02-11 12:18:03 pm

2013-02-11 12:08:13 pm

ok well correct operation is more important to me than the terminology. that makes sense about not passing more information to x264 than will actually be displayed. so basically i need to calculate the width from the height. if the calculated width is greater than the native width then resize to the native width rounded up to mod 4 (do not pad) and tell x264 what the aspect ratio should be with --sar. if the calculated width is equal to or less than the native width then width-resize to the calculated width and pad if necessary to mod 4, then pass that to x264 without --sar.

just going to punt on the whole progressive scan aspect ratio thing right now since enough people will be using yua that i will find out if/when i need to add that functionality.

IsraeliRD

Edit history:

IsraeliRD: 2013-02-11 06:16:05 pm

2013-02-11 06:14:29 pm

Dragon Power Supreme

nate, here's the video: https://www.dropbox.com/s/oc4egku4b6h0ydn/EpicCombo-1%2757%27%2767s.7z
I've attached the txt files that I got from it. I was actually pleasantly surprised to see the audio be encoded and finished first (based on temp filesizes) before it encoded the majority of the video.. not sure if intentional. Basically it did 2.7mbs of AAC and a few dozen KBs of the x264 before it started solely working on the x264.

About the output directory, I thought it would create a sub-directory because I could put in a name of the project/directory (?) right under the 'change' button. Since I only got 3 text files on the desktop and no sub-directories I was wondering what was going on.

The temp. audio the reason I request this is due to the runs I've encoded on Anri so far. The idea was that if you need to encode a very lengthy run as one file, rather than wait hours until the audio gets encoded for each quality, it gets done once and is kept for other qualities. Maybe even be deleted as an optional post-encoding step if we're done with it.
As I'm interested in encoding my next speedrun (3-4 hrs length) as one file, for me it would save a lot of time from being unable to use my computer as the encode process occurs.

Also, maybe it's possible not to display the video during the encode process? I think cpu is wasted on that and slows the process down, but honestly not sure.

Good thing I realised about the tooltips on the start, because since I mostly encode PC runs I wouldn't know what options I should use... which were the default.

nate, here's the video: https://www.dropbox.com/s/oc4egku4b6h0ydn/EpicCombo-1%2757%27%2767s.7z
I've attached the txt files that I got from it. I was actually pleasantly surprised to see the audio be encoded and finished first (based on temp filesizes) before it encoded the majority of the video.. not sure if intentional. Basically it did 2.7mbs of AAC and a few dozen KBs of the x264 before it started solely working on the x264.

About the output directory, I thought it would create a sub-directory because I could put in a name of the project/directory (?) right under the 'change' button. Since I only got 3 text files on the desktop and no sub-directories I was wondering what was going on.

The temp. audio the reason I request this is due to the runs I've encoded on Anri so far. The idea was that if you need to encode a very lengthy run as one file, rather than wait hours until the audio gets encoded for each quality, it gets done once and is kept for other qualities. Maybe even be deleted as an optional post-encoding step if we're done with it.
As I'm interested in encoding my next speedrun (3-4 hrs length) as one file, for me it would save a lot of time from being unable to use my computer as the encode process occurs.

Also, maybe it's possible not to display the video during the encode process? I think cpu is wasted on that and slows the process down, but honestly not sure.

Good thing I realised about the tooltips on the start, because since I mostly encode PC runs I wouldn't know what options I should use... which were the default.

Attachments:

yua.ffmpeg.stderr.log

yua.video_encoder.log

yua.x264.stderr.log

Mystery

2013-02-12 01:18:36 am

Why do you think you can't use the computer while encoding? If yua doesn't do it automatically, you can set the priority of the x264 process to idle. That should allow you to use the computer while the encoder is running.

IsraeliRD

2013-02-12 07:17:33 am

Dragon Power Supreme

From anri's experience, using the computer and/or lowering x264 priority by any means will drop its encoding by a fair bit; if I was to stop using the computer afterwards or set priority back to normal, it would take it a long time to return to its original encoding speed state. Since yua doesn't show details like anri, I have no idea if this will occur here too.
But for myself having a temp audio file I can use for encoding would really save a lot of time. I know its a really odd request.

Mystery

2013-02-12 08:52:59 am

Well, you seem to misunderstand some things.
First, yes, using the computer will slow down encoding since cpu power is diverted to other things. How much it slows down depends on what you do. I don't think it slows down significantly unless you are doing very cpu intensive work.
As for taking a lot time to get back to its original speed, that's just not true. It is true that x264 tend to show the average fps, so when you do stuff that lowers the fps, it may take some time for it converge back again. But have no worries - the actual fps will be the same directly after you stop using the computer.
I am a little confused about the audio, too. Audio does not take long to encode usually. Furthermore, you would still need specific qualities for the audio for different qualities, AFAIK. So how does a temp file help? The end result would be the same.

nate

2013-02-12 09:08:53 am

the question's moot either way since yua encodes the audio and the video at the same time, so there's no discrete audio encoding step. that should result in a pretty good speed boost for these long/large input runs. the speed should be even better when i reintegrate video and audio decoding (right now audio is done entirely in the ffmpeg.exe subprocess) and the machine doesn't have to seek past the same data more than once.

i rewrote video encoding yesterday so that it uses the x264 c api now. good news is that ird's video encodes perfectly - and the audio is even in sync! so if this is the kind of thing you encode then you should be good to go when i release alpha 2.

the reason yua doesn't make a directory to output files is that it's not correct behavior if you're encoding multiple segments of one run. sda historically doesn't use directories in that situation (it does use directories to separate different qualities for bittorrent compatibility, but that happens after it's uploaded to the server). you can always make a new folder in the choose output folder dialog if you want a new folder for some other reason.

i'm going to benchmark the video display but for a variety of reasons i suspect it's not going to be significant enough to even allow people to disable it.

the question's moot either way since yua encodes the audio and the video at the same time, so there's no discrete audio encoding step. that should result in a pretty good speed boost for these long/large input runs. the speed should be even better when i reintegrate video and audio [i]de[/i]coding (right now audio is done entirely in the ffmpeg.exe subprocess) and the machine doesn't have to seek past the same data more than once.

i rewrote video encoding yesterday so that it uses the x264 c api now. good news is that ird's video encodes perfectly - and the audio is even in sync! so if this is the kind of thing you encode then you should be good to go when i release alpha 2.

the reason yua doesn't make a directory to output files is that it's not correct behavior if you're encoding multiple segments of one run. sda historically doesn't use directories in that situation (it does use directories to separate different qualities for bittorrent compatibility, but that happens after it's uploaded to the server). you can always make a new folder in the choose output folder dialog if you want a new folder for some other reason.

i'm going to benchmark the video display but for a variety of reasons i suspect it's not going to be significant enough to even allow people to disable it.

IsraeliRD

Edit history:

IsraeliRD: 2013-02-13 07:50:23 am

2013-02-13 07:49:16 am

Dragon Power Supreme

Mystery: my computer seems to be different then with regards to actual fps, and just doing anything slows it down. Sad

I decided to take anri on a test for a 43 minutes segmented speedrun I got and while I had to leave the computer unattended so I couldn't see how long the audio took, based on estimates it would've been roughly 15-20 minutes. In lengthier videos this would add up (probably an hour+ for 3 hours video) plus it has to repeat the process in other qualities, so it can save time if anri did not have to redo the audio.
From what I understood based on anri's filesize outputs in previous encodes (marble blast gold comes to mind) I saw the temp audio being the same filesize for every quality (LQ-IQ) right before it was muxed into the video. As such even if the audio does end up in different qualities, the original temp file is clearly the same (at least in filesize). However if it is different quality per encode then that's just odd for me.
Anyhow this would be anri only so this request can be dropped.

Looking towards alpha 2.

Mystery: my computer seems to be different then with regards to actual fps, and just doing anything slows it down. :(
I decided to take anri on a test for a 43 minutes segmented speedrun I got and while I had to leave the computer unattended so I couldn't see how long the audio took, based on estimates it would've been roughly 15-20 minutes. In lengthier videos this would add up (probably an hour+ for 3 hours video) plus it has to repeat the process in other qualities, so it can save time if anri did not have to redo the audio.
From what I understood based on anri's filesize outputs in previous encodes (marble blast gold comes to mind) I saw the temp audio being the same filesize for every quality (LQ-IQ) right before it was muxed into the video. As such even if the audio does end up in different qualities, the original temp file is clearly the same (at least in filesize). However if it is different quality per encode then that's just odd for me.
Anyhow this would be anri only so this request can be dropped.

Looking towards alpha 2.

nate

2013-02-13 08:57:15 am

it's probably just that you have large input files and a spinning disk rather than a solid state drive. that's totally normal. at least for the audio. dunno on the video. when optimizing things you want to keep all of your resources busy all the time. it's a balance. if you have idle cpu, then give the cpu more to do. that may mean getting a faster disk or doing more than one thing at a time on the cpu. i think encoding the audio at the same time as the first pass of the video is a good solution since the cpu will be faster than the disk for just about everyone in the case of the audio. now if i could just get ffmpeg to decode stereo aac properly ...

just curious, what are your system specs, ird? especially the cpu and disk.

nate

Edit history:

nate: 2013-02-13 09:50:19 am

2013-02-13 09:49:47 am

ok snow:

Code:

void Yua::set_width_from_height_clamped_to_native_width_and_mod_2_height(int &width, int &height) {
        width = round_up_to_mod_4(height / aspect_ratio);
        if (width > original_native_width) { //oops - don't make it wider than native width - x264's "sar" functionality will take care of displaying it wider (20130212)
                width = round_up_to_mod_4(original_native_width);
        }
        height = round_up_to_mod_2(height);
}

void Yua::set_sizes() {
        native_width = original_native_width;
        native_height = original_native_height;
        int aspect_ratio_num = native_width;
        int aspect_ratio_den = native_height;


        if (interlaced_button->isChecked()) {
                aspect_ratio_num = widescreen_button->isChecked() ? 16 : 4;
                aspect_ratio_den = widescreen_button->isChecked() ?  9 : 3;
                if (d4_button->isChecked()) {
                        native_height /= 2;
                }
        } else if (d4_button->isChecked()) {
                native_height = 240;
        }
        //right now we don't change or let the user change the aspect ratio for progressive scan input (20130212)
        //if the input is progressive and the d1 box is checked we do nothing - if d4 is checked we reduce to d4 (20130212)
        aspect_ratio = (double)aspect_ratio_den / (double)aspect_ratio_num;
        emit set_aspect_ratio(aspect_ratio_num, aspect_ratio_den); //we will use this to calculate the pixel aspect ratio passed to x264 so that we can display at the correct aspect ratio without stretching the image horizontally and without losing resolution vertically (i.e., without setting the height from the width) (20130213)


        //heights
        lq_height = 240;
        if (lq_height > native_height) lq_height = native_height;

        mq_height = 240;
        if (mq_height > native_height) mq_height = native_height;

        hq_height = 480;
        if (hq_height > native_height) hq_height = native_height;

        iq_height = 1280;
        if (iq_height > native_height) iq_height = native_height;

        xq_height = native_height;

        //widths
        set_width_from_height_clamped_to_native_width_and_mod_2_height(native_width, native_height);
        set_width_from_height_clamped_to_native_width_and_mod_2_height(lq_width, lq_height);
        set_width_from_height_clamped_to_native_width_and_mod_2_height(mq_width, mq_height);
        set_width_from_height_clamped_to_native_width_and_mod_2_height(hq_width, hq_height);
        set_width_from_height_clamped_to_native_width_and_mod_2_height(iq_width, iq_height);
        set_width_from_height_clamped_to_native_width_and_mod_2_height(xq_width, xq_height);


        qDebug() << "native" << native_width << native_height;
        qDebug() << "lq" << lq_width << lq_height;
        qDebug() << "mq" << mq_width << mq_height;
        qDebug() << "hq" << hq_width << hq_height;
        qDebug() << "iq" << iq_width << iq_height;
        qDebug() << "xq" << xq_width << xq_height;


        lq_button->setChecked(true);
        mq_button->setChecked(true);
        hq_button->setChecked(true);
        iq_button->setChecked(false);
        xq_button->setChecked(false);
        if (native_height > 576+8) { //FIXME bother them about making iq if f1 is checked (20130212)
                iq_button->setChecked(true);
                if (native_height >= 720) {
                        xq_button->setChecked(true);
                }
        }


        preview_size = QSize(native_width, native_height);
        emit set_preview_size(preview_size.width(), preview_size.height());
        return process_current_image();
}

i just punted on padding since i can't think of a way to do it that's not trivial in terms of cpu and x264 --sar can be mod 1. so scale to mod 4 width, mod 2 height, rely on --sar for correct aspect ratio on playback. it seems to be working quite well so far. only thing i'm not satisfied with is how the preview display (that everyone hates because they think it's stealing their cpu) is now the wrong aspect ratio for e.g. 720x480 widescreen input where --sar is what is ensuring it displays wider on playback. i can't resize every frame for display with the cpu for performance reasons so i'm thinking about rewriting my opengl display encapsulation class that handles aspect ratio (Webcam_Display) to accept arbitrary aspect ratios rather than setting its own based purely on 1:1 par. that would solve it but i'm honestly not looking forward to it. at the same time i don't like showing that bad aspect ratio preview because it's misleading. so we'll see.

ok snow: [hidden="new aspect ratio code"][code]void Yua::set_width_from_height_clamped_to_native_width_and_mod_2_height(int &width, int &height) {
        width = round_up_to_mod_4(height / aspect_ratio);
        if (width > original_native_width) { //oops - don't make it wider than native width - x264's "sar" functionality will take care of displaying it wider (20130212)
                width = round_up_to_mod_4(original_native_width);
        }
        height = round_up_to_mod_2(height);
}

void Yua::set_sizes() {
        native_width = original_native_width;
        native_height = original_native_height;
        int aspect_ratio_num = native_width;
        int aspect_ratio_den = native_height;

if (interlaced_button->isChecked()) {
                aspect_ratio_num = widescreen_button->isChecked() ? 16 : 4;
                aspect_ratio_den = widescreen_button->isChecked() ?  9 : 3;
                if (d4_button->isChecked()) {
                        native_height /= 2;
                }
        } else if (d4_button->isChecked()) {
                native_height = 240;
        }
        //right now we don't change or let the user change the aspect ratio for progressive scan input (20130212)
        //if the input is progressive and the d1 box is checked we do nothing - if d4 is checked we reduce to d4 (20130212)
        aspect_ratio = (double)aspect_ratio_den / (double)aspect_ratio_num;
        emit set_aspect_ratio(aspect_ratio_num, aspect_ratio_den); //we will use this to calculate the pixel aspect ratio passed to x264 so that we can display at the correct aspect ratio without stretching the image horizontally and without losing resolution vertically (i.e., without setting the height from the width) (20130213)

//heights
        lq_height = 240;
        if (lq_height > native_height) lq_height = native_height;

mq_height = 240;
        if (mq_height > native_height) mq_height = native_height;

hq_height = 480;
        if (hq_height > native_height) hq_height = native_height;

iq_height = 1280;
        if (iq_height > native_height) iq_height = native_height;

xq_height = native_height;

//widths
        set_width_from_height_clamped_to_native_width_and_mod_2_height(native_width, native_height);
        set_width_from_height_clamped_to_native_width_and_mod_2_height(lq_width, lq_height);
        set_width_from_height_clamped_to_native_width_and_mod_2_height(mq_width, mq_height);
        set_width_from_height_clamped_to_native_width_and_mod_2_height(hq_width, hq_height);
        set_width_from_height_clamped_to_native_width_and_mod_2_height(iq_width, iq_height);
        set_width_from_height_clamped_to_native_width_and_mod_2_height(xq_width, xq_height);

qDebug() << "native" << native_width << native_height;
        qDebug() << "lq" << lq_width << lq_height;
        qDebug() << "mq" << mq_width << mq_height;
        qDebug() << "hq" << hq_width << hq_height;
        qDebug() << "iq" << iq_width << iq_height;
        qDebug() << "xq" << xq_width << xq_height;

lq_button->setChecked(true);
        mq_button->setChecked(true);
        hq_button->setChecked(true);
        iq_button->setChecked(false);
        xq_button->setChecked(false);
        if (native_height > 576+8) { //FIXME bother them about making iq if f1 is checked (20130212)
                iq_button->setChecked(true);
                if (native_height >= 720) {
                        xq_button->setChecked(true);
                }
        }

preview_size = QSize(native_width, native_height);
        emit set_preview_size(preview_size.width(), preview_size.height());
        return process_current_image();
}
[/code][/hidden]
i just punted on padding since i can't think of a way to do it that's not trivial in terms of cpu and x264 --sar can be mod 1. so scale to mod 4 width, mod 2 height, rely on --sar for correct aspect ratio on playback. it seems to be working quite well so far. only thing i'm not satisfied with is how the preview display (that everyone hates because they think it's stealing their cpu) is now the wrong aspect ratio for e.g. 720x480 widescreen input where --sar is what is ensuring it displays wider on playback. i can't resize every frame for display with the cpu for performance reasons so i'm thinking about rewriting my opengl display encapsulation class that handles aspect ratio (Webcam_Display) to accept arbitrary aspect ratios rather than setting its own based purely on 1:1 par. that would solve it but i'm honestly not looking forward to it. at the same time i don't like showing that bad aspect ratio preview because it's misleading. so we'll see.

bos

2013-02-13 03:23:20 pm

Punted? Do you punt a football to let off steam when you're raging? Sometimes I consider hoisting up a punching bag closeby. jk.

Cool code.
Custom ratios in the future?
IQ height, you have the width in there. You'll want 720... or..... 768? How strict do you want to be on the "720p" encode? Anri IQ at some point was 720p height, but was changed on request (by bmn I believe) to 768.

You should get the display to look right. People will freak out. People freaked back when I had sample creation field-split instead of YV12+interlacedflag.

nate

2013-02-13 03:37:04 pm

yeah i dunno, i think it's british english i picked up somewhere. it's really weird for sheltered americans because we think of football, but then again maybe they have a game where they punt things also. or maybe it has nothing to do with that and i'm misinterpreting it.

good call on the iq dimensions. i changed the first reference to 768 since i don't really care whether we cut off at 720 or 768 and consistency with anri is good. there is also the second reference where i attempt to suggest which qualities to encode. that one i left at 720 since if you're encoding hd video you should encode xq. ... right?

already got my display code rewritten so i think we are good there. also switched over to sse2 resizing input to x264. but then i realized i didn't test the new libx264 video encoder with statids so i'm fixing all the bugs that came from that now.

IsraeliRD

2013-02-13 03:53:58 pm

Dragon Power Supreme

Windows XP SP3, Core 2 Duo 2.4GHz, 4GB RAM, GeForce 8800GTS 320gb.
I have 2 HDs:
One is 320gb WD3200AAJS - 7200rpm - used as main system directory, got fraps/games etc running on it
The other is 1.5TB samsung HD154UI - 5400rpm - used to store the speedruns. I know the rpm is bad (i had a proper barracuda 7200 before) but it works like magic so no complaints.
Oddly enough Camtasia never gave me problems for encoding unless those were extremely lengthy ones (1+ hrs).

I know I'll get a new comp this year :p

ballofsnow

Edit history:

ballofsnow: 2013-02-13 05:05:34 pm

2013-02-13 05:04:33 pm

nate, what are the issues you are having with progressive scan input?

Quote from nate:

there is also the second reference where i attempt to suggest which qualities to encode. that one i left at 720 since if you're encoding hd video you should encode xq. ... right?

Makes sense to me.

Oh, regarding the whole audio redundant encoding stuff. I thought about this, and it's actually been on the anri to-do list for a long time now. Well, it actually says specifically to reduce x264 passes, but audio would have followed. Nate, you may want to consider doing something like this. E.g. If input 640x480 and encoding HQ/IQ, the first slow-pass crf17 is identical, and only on 2nd pass does it bring it back down to different bitrates.

nate

2013-02-13 05:37:55 pm

i'm just skeptical that there are use cases for specifying the aspect ratio of progressive scan input. is it when the aspect ratio in the mpeg transport stream metadata is incorrect? that's the only thing i can think of. i don't know whether that actually happens to people though.

i actually never once thought of the implications of what you're saying now. yet when i look at my own code it's obvious:

Code:

        if (video_information.pass == 1) {
                param.rc.b_stat_read = 0;
                param.rc.b_stat_write = 1;
                param.rc.psz_stat_out = stat_file_name_pointer;
                param.rc.i_rc_method = X264_RC_CRF;
                param.rc.f_rf_constant = 17;

        } else if (video_information.pass == 2) {
                param.rc.b_stat_read = 1;
                param.rc.b_stat_write = 0;
                param.rc.psz_stat_in = stat_file_name_pointer;
                param.rc.i_rc_method = X264_RC_ABR;
                param.rc.i_bitrate = video_information.bitrate;
        }

there is almost no difference between the first and second passes except that one is the first pass and the other is the second pass.

it's even easier because potentially like qualities are contiguous. right now yua goes from xq down to lq. so if we are encoding the same run and not encoding mq and didn't change dimensions or framerate from the previous encode and the existing output is too high bitrate to use as-is (skipping encoding entirely) then skip straight to the second pass, otherwise do first pass as normal. does that sound right? it's a little scary how much computation this could cut because of how often iq and hq are the same dimensions and framerate.

i'm just skeptical that there are use cases for specifying the aspect ratio of progressive scan input. is it when the aspect ratio in the mpeg transport stream metadata is incorrect? that's the only thing i can think of. i don't know whether that actually happens to people though.

i actually never once thought of the implications of what you're saying now. yet when i look at my own code it's obvious:

[code]        if (video_information.pass == 1) {
                param.rc.b_stat_read = 0;
                param.rc.b_stat_write = 1;
                param.rc.psz_stat_out = stat_file_name_pointer;
                param.rc.i_rc_method = X264_RC_CRF;
                param.rc.f_rf_constant = 17;

} else if (video_information.pass == 2) {
                param.rc.b_stat_read = 1;
                param.rc.b_stat_write = 0;
                param.rc.psz_stat_in = stat_file_name_pointer;
                param.rc.i_rc_method = X264_RC_ABR;
                param.rc.i_bitrate = video_information.bitrate;
        }
[/code]
there is almost no difference between the first and second passes except that one is the first pass and the other is the second pass.

it's even easier because potentially like qualities are contiguous. right now yua goes from xq down to lq. so if we are encoding the same run and not encoding mq and didn't change dimensions or framerate from the previous encode and the existing output is too high bitrate to use as-is (skipping encoding entirely) then skip straight to the second pass, otherwise do first pass as normal. does that sound right? it's a little scary how much computation this could cut because of how often iq and hq are the same dimensions and framerate.

ballofsnow

Edit history:

ballofsnow: 2013-02-13 06:43:52 pm

ballofsnow: 2013-02-13 06:43:24 pm

ballofsnow: 2013-02-13 06:11:22 pm

2013-02-13 06:02:03 pm

Quote from nate:

i'm just skeptical that there are use cases for specifying the aspect ratio of progressive scan input. is it when the aspect ratio in the mpeg transport stream metadata is incorrect? that's the only thing i can think of. i don't know whether that actually happens to people though.

Are you thinking we'll only see progressive input from fraps type pc recordings so why bother with non-square pixels? What about progressive dvd at 720x480? You have more visibility than me on what people are submitting. With Anri it wasn't something I even thought about; there was just the sequence of events. User has input, progressive or interlaced, whatever -> bla bla intermediate steps -> set aspect ratio or not -> etc. Anyway this is why I'm puzzled that you're seeing this as an issue(?).

edit- Hmm, actually is this because with progressive, the current interface will force a 4:3 or 16:9, when PC recordings have a million different possible resolutions and that'll screw things up? In that case, I see your point. So yeah, hide it until you have the input box to specify custom ratio, pre-filled with what Yua thinks you want, i.e. native res as fallback or do something smarter.

Quote from nate:

i actually never once thought of the implications of what you're saying now. yet when i look at my own code it's obvious

there is almost no difference between the first and second passes except that one is the first pass and the other is the second pass.

it's even easier because potentially like qualities are contiguous. right now yua goes from xq down to lq. so if we are encoding the same run and not encoding mq and didn't change dimensions or framerate from the previous encode and the existing output is too high bitrate to use as-is (skipping encoding entirely) then skip straight to the second pass, otherwise do first pass as normal. does that sound right? it's a little scary how much computation this could cut because of how often iq and hq are the same dimensions and framerate.

Yep, it could be reeeeaaally beneficial to people. It's also because I feel a little bit guilty changing the first pass to a slow-pass crf, whereas previously it was a fast first pass, slow second pass with minimum quantizers thrown in. So if we can save them some time.. that'd be awesome. Obviously, in terms of saving time, a worst case scenario of having to encode a 1080p input will save no time since each version will have different resolution; and LQ & MQ, while having the same resolution, are encoded differently, MQ being the compatibility version.

edit- uuuggh, I'm too tired to think. Here's a bit of logic, you can probably do something better than this:

Code:

XQ:
Encode XQ crf pass1, XQ.stats generated
If XQ crf pass1 > 10000 kbps, then encode XQ bitrate pass2
If XQ crf pass1 =< 10000 kbps, woot


IQ:
Check if XQ was encoded
If XQ not encoded
    Encode IQ crf pass1, IQ.stats generated
    If IQ crf pass1 > 5000 kbps, then encode IQ bitrate pass2
    If IQ crf pass1 =< 5000 kbps, awesome
If XQ was encoded
    IF IQ and XQ have same output
        If XQ crf pass1 > 5000 kbps, then encode IQ bitrate pass2 using XQ.stats
        If XQ crf pass1 =< 5000 kbps, sweet I have no IQ
    IF IQ and XQ do not have same output
        blaargh to be continued after these commercials...

[quote="nate"]i'm just skeptical that there are use cases for specifying the aspect ratio of progressive scan input. is it when the aspect ratio in the mpeg transport stream metadata is incorrect? that's the only thing i can think of. i don't know whether that actually happens to people though.[/quote]
Are you thinking we'll only see progressive input from fraps type pc recordings so why bother with non-square pixels? What about progressive dvd at 720x480? You have more visibility than me on what people are submitting. With Anri it wasn't something I even thought about; there was just the sequence of events. User has input, progressive or interlaced, whatever -> bla bla intermediate steps -> set aspect ratio or not -> etc. Anyway this is why I'm puzzled that you're seeing this as an issue(?).

edit- Hmm, actually is this because with progressive, the current interface will force a 4:3 or 16:9, when PC recordings have a million different possible resolutions and that'll screw things up? In that case, I see your point. So yeah, hide it until you have the input box to specify custom ratio, pre-filled with what Yua thinks you want, i.e. native res as fallback or do something smarter.

[quote="nate"]i actually never once thought of the implications of what you're saying now. yet when i look at my own code it's obvious

there is almost no difference between the first and second passes except that one is the first pass and the other is the second pass.

it's even easier because potentially like qualities are contiguous. right now yua goes from xq down to lq. so if we are encoding the same run and not encoding mq and didn't change dimensions or framerate from the previous encode and the existing output is too high bitrate to use as-is (skipping encoding entirely) then skip straight to the second pass, otherwise do first pass as normal. does that sound right? it's a little scary how much computation this could cut because of how often iq and hq are the same dimensions and framerate.[/quote]
Yep, it could be reeeeaaally beneficial to people. It's also because I feel a little bit guilty changing the first pass to a slow-pass crf, whereas previously it was a fast first pass, slow second pass with minimum quantizers thrown in. So if we can save them some time.. that'd be awesome. Obviously, in terms of saving time, a worst case scenario of having to encode a 1080p input will save no time since each version will have different resolution; and LQ & MQ, while having the same resolution, are encoded differently, MQ being the compatibility version.

edit- uuuggh, I'm too tired to think. Here's a bit of logic, you can probably do something better than this:

[code]
XQ:
Encode XQ crf pass1, XQ.stats generated
If XQ crf pass1 > 10000 kbps, then encode XQ bitrate pass2
If XQ crf pass1 =< 10000 kbps, woot

IQ:
Check if XQ was encoded
If XQ not encoded
    Encode IQ crf pass1, IQ.stats generated
    If IQ crf pass1 > 5000 kbps, then encode IQ bitrate pass2
    If IQ crf pass1 =< 5000 kbps, awesome
If XQ was encoded
    IF IQ and XQ have same output
        If XQ crf pass1 > 5000 kbps, then encode IQ bitrate pass2 using XQ.stats
        If XQ crf pass1 =< 5000 kbps, sweet I have no IQ
    IF IQ and XQ do not have same output
        blaargh to be continued after these commercials...
[/code]

Flip

2013-02-16 10:27:39 am

1-Up!

Decided to give this a look after you mentioned it this morning. Might give it a shot in osx if I can transfer some raw video over to this hard drive.

Other than that, not much to say besides +1 support and that I've always associated punting the way you used it with American football - "I dont' want to deal with this now, so I'll punt it away and worry about it when it's back in my hands later."

presjpolk

Edit history:

presjpolk: 2013-02-16 02:22:27 pm

presjpolk: 2013-02-16 02:22:13 pm

presjpolk: 2013-02-16 02:21:19 pm

presjpolk: 2013-02-16 02:21:02 pm

2013-02-16 12:05:53 pm

HELLO!

Good luck on trying to read old perl code, nate. Smiley

Having done 5 years of KDE back in the day, it kinda makes me happy to see Qt still exists and is used. Qt really was C++ done right, in serious and important ways.

Good luck, sir. Trying it now.

[EDIT. NEVER MIND WHAT WAS HERE. SKYPE WAS CROWDING EVERYTHING ELSE OUT. STUPID SKYPE]

nate

2013-02-17 04:38:23 pm

haha. fortunately i don't have to read anri 4 or anri 3 thanks to snow helping me.

just sent up alpha 2. the links in the first post are the same (what is linked to is now alpha 2).

there is a very good argument for making yua usable to as many people as possible as quickly as possible. unfortunately then it becomes more difficult for me to force myself to finish those technically more challenging features that fewer people would use.

there are two major challenges with yua that i outlined at the end of my first post in this thread. i decided to tackle them before moving on to other things. i'm pleased to report that one of the two, d1 deinterlacing, is now behind me. with the assembly-optimized version of the nnedi3 deinterlacer in, d1 deinterlacing is sped up by at least an order of magnitude.

this leaves just convincing ffmpeg to decode audio correctly in order to implement av sync, and i will be on to the features you all have requested. rest assured that i have not forgotten about them.

the only other major change this time is the introduction of libx264 to replace the standalone x264 binary in alpha 1. hung encodes should be a thing of the past. obviously let me know if not. thanks.

i ended up copying each function with inline assembly to its own file, then "compiling" them using the apple version of gcc, which has a switch -fasm-blocks which allows it to take msvc-style inline asm. i then modified the .s files gcc -S emitted for the other two platforms. porting to amd64 was mostly as easy as changing eax to rax, etc. it took me some time to get the windows build (32-bit) running because i had to learn about fpo (frame pointer omission) and how to enable that optimization for the function whose inline assembly assumed it had taken place. then under linux i had to massage the apple gcc-generated .s files so that the linux assembler would accept them. all in all it's been a packed four days.

haha. fortunately i don't have to read anri 4 or anri 3 thanks to snow helping me.

just sent up alpha 2. the links in the first post are the same (what is linked to is now alpha 2).

there is a very good argument for making yua usable to as many people as possible as quickly as possible. unfortunately then it becomes more difficult for me to force myself to finish those technically more challenging features that fewer people would use.

there are two major challenges with yua that i outlined at the end of my first post in this thread. i decided to tackle them before moving on to other things. i'm pleased to report that one of the two, d1 deinterlacing, is now behind me. with the assembly-optimized version of the nnedi3 deinterlacer in, d1 deinterlacing is sped up by at least an order of magnitude.

this leaves just convincing ffmpeg to decode audio correctly in order to implement av sync, and i will be on to the features you all have requested. rest assured that i have not forgotten about them.

the only other major change this time is the introduction of libx264 to replace the standalone x264 binary in alpha 1. hung encodes should be a thing of the past. obviously let me know if not. thanks.

[hidden="nnedi3"]i ended up copying each function with inline assembly to its own file, then "compiling" them using the apple version of gcc, which has a switch -fasm-blocks which allows it to take msvc-style inline asm. i then modified the .s files gcc -S emitted for the other two platforms. porting to amd64 was mostly as easy as changing eax to rax, etc. it took me some time to get the windows build (32-bit) running because i had to learn about fpo (frame pointer omission) and how to enable that optimization for the function whose inline assembly assumed it had taken place. then under linux i had to massage the apple gcc-generated .s files so that the linux assembler would accept them. all in all it's been a packed four days.[/hidden]