yua

2013-02-17 06:24:20 pm

Dragon Power Supreme

Gave alpha 2 a quick run on the epic combo video, and the speed in which it encodes is indeed faster than alpha 1. HQ was laggy, but MQ was encoding smoothly (no random pauses). How come LQ had to go through two passes though? the first pass was rather slow (still faster than HQ), second pass was fast but not as fast as MQ.
I checked the filesizes of the video encodes against the outputs from Anri-Chan, and I can report that LQ was roughly the same, MQ was slightly smaller (700kbs - 13mbs vs. 12.3mbs) but HQ was considerably smaller - 20mbs vs. 15mbs!

nate

2013-02-17 06:28:33 pm

glad to hear it's working. lq had to go through two passes because i haven't implemented snow's stuff yet.

honorableJay

2013-02-17 08:07:53 pm

The Dork Knight himself.

Why isn't this topic stickied yet??

nate

2013-02-17 11:32:59 pm

i don't think people need to find it easily. right now it's still just something to try out if you have the time. if it'd be helpful for me to sticky it then i can. already a lot of stickies in this board though.

IsraeliRD

Edit history:

IsraeliRD: 2013-02-18 04:03:52 am

IsraeliRD: 2013-02-18 04:03:29 am

2013-02-18 04:02:44 am

Dragon Power Supreme

Request for StatID font to be the same as Anri's. It looks better imo.

I went ahead and tested yua alpha 2 against Anri-Chan 3.3 on a single video recorded in FRAPS and its New Master File counterpart and received some interested results.
- yua lost 4 seconds from fraps video (3:46 mins output vs 3:50 mins as required), and audio/video desync
- yua output video, in terms of filesize, for HQ/IQ is considerably smaller than Anri-Chan. In fact, New Master File + yua on IQ encode resulted in the lowest filesize compared to other IQ encodes.
- Anri chan encodes every quality faster most of the time, let down by the audio coding.
- Anri chan's x264 process kept freezing, whereas with yua it always worked and always used more CPU.

If you're interested, nate, here are the tests I've done in doc format. Having Anri's results is a good base and I want to compare it to further yua versions.

Attachment:

EncodingTestResults.doc

nate

2013-02-18 08:43:14 am

cool, thanks. interesting that yua's decoding pipeline was more efficient in this case considering it's that horrible fraps codec. i wonder whether the ffmpeg implementation is just better than the fraps original one. it could even be multithreaded. i doubt that, but then i have no other explanation besides just "windows sucks," haha.

wonder if snow can weigh in on the file size thing. i just copied the x264 options directly from anri. there isn't even that much to screw up with non-mq since it's just the veryslow preset minus b-pyramid right? is it possible it's because yua's version of x264 is so much newer?

presjpolk

2013-02-18 10:16:22 am

HELLO!

Alpha 1 had an issue with me where it seemed to be de-interlacing my video even though I had progressive marked.

I've attached screenshots of my anri LQ encoding and my Yua MQ recording, so you can see what I mean.

I'll try alpha 2 in case it matters.

Attachments:

anri-lq.png

yua-mq.png

nate

2013-02-18 10:53:43 am

could you upload the input video? failing that, what are the dimensions?

presjpolk

Edit history:

presjpolk: 2013-02-18 11:00:52 am

2013-02-18 11:00:42 am

HELLO!

The input video is 123GB. I could upload it if it would be useful but I'll avoid it if possible. Smiley

The resolution is 720x486 per VLC

nate

Edit history:

nate: 2013-02-18 11:04:30 am

2013-02-18 11:03:06 am

ok, 90% sure the cause is resizing to 240 height instead of 486/2 height. wonder why blackmagic decided to be an asshole and make life difficult for people without caring about the consequences of going out on their own and generating their own standard of video. anyway it's on my todo list to figure out. thanks.

edit: snow, what do you think about chopping off the bottom 6 lines initially in the case that the input is 486 pixels tall?

presjpolk

2013-02-18 11:04:00 am

HELLO!

Great, thanks. Looking forward to getting this done. Smiley

I seem to find bugs in everything.

nate

2013-02-18 11:10:26 am

actually can you go ahead and try alpha 2? i just remembered that i changed how resizing works and it may have affected your problem. thanks.

presjpolk

Edit history:

presjpolk: 2013-02-19 12:24:29 am

2013-02-18 11:19:41 pm

HELLO!

In alpha 2, setting my video to D4... doesn't quite work. Height issue again?

Will try it at D1 overnight.

EDIT: seems to do the same at D1.

Attachment:

yua-alpha2-d4.png

nate

2013-02-19 08:40:18 am

yeah i screwed up the dimensions somehow. i thought i set all the widths to mod 4 but apparently not ... will be fixed in alpha 3.

ballofsnow

2013-02-19 10:21:53 am

Quote from nate:

edit: snow, what do you think about chopping off the bottom 6 lines initially in the case that the input is 486 pixels tall?

Indiscriminately? I guess it's unlikely that the top/bottom 2/4 pixel lines will have anything meaningful.. is that a safe assumption in your experience? Actually, while really unlikely I can picture someone doing manual cropping (whether in future version of yua, or outside of yua) such that the height becomes exactly 486 pixels. Ehhhh.... maybe playing it too safe here, just go for it.

I'm at work right now so can't really test, but are the lower resolution encodes like LQ & MQ taking up 100% CPU usage? If not, encode both LQ & MQ at the same time?

nate

2013-02-19 10:27:04 am

that's a good point. unfortunately it's not a question i can answer without testing a bunch of different input files on a bunch of different machines because it depends on how well decoding scales, right? if decoding isn't multithreaded for some reason then you don't have a prayer on newer machines. but i know that h.264 decoding is multithreaded. the only other major dog i can think of right now is lagarith and i don't know about it. need to check. if it's not then yeah. mq is probably bottlenecked on one core, can just encode mq and lq at the same time to mitigate it.

ballofsnow

2013-02-19 10:50:55 am

Just got setup here with a2. Simultaneous LQ&MQ might not be worth looking into, currently getting high cpu usage on a 60 second lagarith clip. On future tests I'll keep monitoring in case there are times when it would be useful.

nate

2013-02-19 10:51:20 am

how many cores is that system?

ballofsnow

2013-02-19 10:52:33 am

I'll admit, it's in a VM with 4 cores and 4 GB memory. System gets to max 4.0 GHz, waiting on a heatsink to come in..

nate

2013-02-19 10:54:07 am

was that mq you were encoding? if so then 4 cores is enough to say that lagarith decoding is probably multithreaded in which case i doubt people will run into single-threaded decoding bottlenecks very often. probably not enough to have additional logic for encoding mq and lq at the same time as you say.

ballofsnow

2013-02-19 10:55:16 am

Sorry, should have specified it's MQ and then LQ. I can separate them out if you want, but it's consistent between the two.

nate

2013-02-19 10:57:34 am

yeah there's no way the bottleneck is decoding then. thanks for looking into this. i hate to admit it but it's looking more and more like ffmpeg is our ace in the hole. if codec xyz becomes popular in the future then i can just write a multithreaded decoder and add it to ffmpeg, then upgrade yua's ffmpeg.

ballofsnow

Edit history:

ballofsnow: 2013-02-21 12:26:48 pm

2013-02-21 12:25:25 pm

Yo nate. Do you happen to have a list of things already that you test against Yua? Something I wanted to do with anri but never bothered was to created a comprehensive "test bench" and procedure. While I had a decent arrangement of input types, there was never a written down process. So basically it would just be a bunch of various input types, with stuff that could potentially break a program like odd-number dimensions (RGB input), crazy audio length, that sort of thing. I'd like to do that now for Yua, so if you have anything just let me know.

nate

2013-02-21 12:47:46 pm

nope ... it's all stone age right now, ad hoc. i agree we should have a test suite though. certainly this will get a lot easier once i put in the automation facility. haven't decided exactly how i want that to work yet, but it should allow someone with a single "command" (not sure what form this will take yet) to encode one or more input files, specifying d f fdp and so on. then i can write a little tool that outputs information about the resulting files in machine-readable form, and bam, we have automated testing. not sure how much of it would still have to be manual at that point, but automatically checking dimensions, framerate, number of audio channels, presence of sane audio (not all 0's on one or both channels), etc of yua's output would definitely cut down on it.

btw any ideas you have on the automation would be welcome. i think it wouldn't be a bad idea to have something really simple, like a kind of template that can easily be machine-generated that yua reads. so something like this:

Code:

D=1
F=1
FDP=2D
INPUT=c:\Users\mayu\desktop\test.vob
OUTPUT=c:\Users\mayu\desktop\test\
NAME=test
Q=LQ,MQ,HQ #if this is missing, yua will decide
etc

if you save that as test.job and run yua.exe test.job from the cli then everything happens automatically. right now i prefer this to embedding lua or something.

nope ... it's all stone age right now, ad hoc. i agree we should have a test suite though. certainly this will get a lot easier once i put in the automation facility. haven't decided exactly how i want that to work yet, but it should allow someone with a single "command" (not sure what form this will take yet) to encode one or more input files, specifying d f fdp and so on. then i can write a little tool that outputs information about the resulting files in machine-readable form, and bam, we have automated testing. not sure how much of it would still have to be manual at that point, but automatically checking dimensions, framerate, number of audio channels, presence of sane audio (not all 0's on one or both channels), etc of yua's output would definitely cut down on it.

btw any ideas you have on the automation would be welcome. i think it wouldn't be a bad idea to have something really simple, like a kind of template that can easily be machine-generated that yua reads. so something like this:

[code]D=1
F=1
FDP=2D
INPUT=c:\Users\mayu\desktop\test.vob
OUTPUT=c:\Users\mayu\desktop\test\
NAME=test
Q=LQ,MQ,HQ #if this is missing, yua will decide
etc[/code]

if you save that as test.job and run yua.exe test.job from the cli then everything happens automatically. right now i prefer this to embedding lua or something.

ballofsnow

Edit history:

ballofsnow: 2013-02-22 01:18:15 pm

2013-02-22 01:15:26 pm

Some ideas, please point out any flaws/suggestions.

1. A button to save as a template. It creates a template file that the user can run instead of yua. It will load all settings minus stuff that isn't appropriate like the input.

Use case: Imagine a user who's running multiple games. It'd be nice if they can easily switch batch and forth between encoding e.g. an NES game and a PC game. Or a user who is encoding many separate videos, with the template he doesn't have to change all the options over and over.

2. A button to save as a job. All settings passed into a job queue. I'm thinking of how they do it in virtualdub; set up all your jobs then press go.

Use case: Imagine a user who is not comfortable at all in doing CLI, but still wants the ability to create jobs, you need a purely GUI driven way to do it.

3. For those that like CLI, pass the missing parameter(s) such as input to a template and yua runs in single-job mode. This seems a bit hybrid like, in that you have to run the GUI to create the template and only then go CLI. Ideally you'd be able to pass all parameters in a single line to yua.exe.

Use case: Imagine a user sets up a batch file with multiple lines, all similar except for the input. Line 1 runs, encodes, comes back to line 2, etc.

Some ideas, please point out any flaws/suggestions.

1. A button to save as a template. It creates a template file that the user can run instead of yua. It will load all settings minus stuff that isn't appropriate like the input.

Use case: Imagine a user who's running multiple games. It'd be nice if they can easily switch batch and forth between encoding e.g. an NES game and a PC game. Or a user who is encoding many separate videos, with the template he doesn't have to change all the options over and over.

2. A button to save as a job. All settings passed into a job queue. I'm thinking of how they do it in virtualdub; set up all your jobs then press go.

Use case: Imagine a user who is not comfortable at all in doing CLI, but still wants the ability to create jobs, you need a purely GUI driven way to do it.

3. For those that like CLI, pass the missing parameter(s) such as input to a template and yua runs in single-job mode. This seems a bit hybrid like, in that you have to run the GUI to create the template and only then go CLI. Ideally you'd be able to pass all parameters in a single line to yua.exe.

Use case: Imagine a user sets up a batch file with multiple lines, all similar except for the input. Line 1 runs, encodes, comes back to line 2, etc.