yua

ballofsnow

Edit history:

ballofsnow: 2013-04-16 05:07:06 pm

ballofsnow: 2013-04-16 05:03:00 pm

ballofsnow: 2013-04-16 05:01:30 pm

ballofsnow: 2013-04-16 05:01:16 pm

ballofsnow: 2013-04-16 05:00:57 pm

ballofsnow: 2013-04-16 05:00:29 pm

ballofsnow: 2013-04-16 04:59:42 pm

2013-04-16 04:59:07 pm

Here are some tests from Jay's raw. The 640x240 looks the same as the 640x480 after setting nearest neighbor in media player classic. The sample aspect ratio of 1:2 survives even on youtube.

Notice the difference in file size, especially both 320x240 videos. Softer edges are apparently easier to compress.

320x240_lanczosresize_YUV420_SAR1to1_video.mp4 = 848,352 bytes
320x240_pointresize_YUV420_SAR1to1_video.mp4 = 1,542,129 bytes
640x240_sepfieldsonly_YUV420_SAR1to2_video.mp4 = 2,450,787 bytes
640x480_pointresize_YUV420_SAR1to1_video.mp4 = 3,615,954 bytes

Attachments:

320x240_lanczosresize_YUV420_SAR1to1_video.mp4

320x240_pointresize_YUV420_SAR1to1_video.mp4

640x240_sepfieldsonly_YUV420_SAR1to2_video.mp4

640x480_pointresize_YUV420_SAR1to1_video.mp4

honorableJay

Edit history:

honorableJay: 2013-04-16 06:32:31 pm

honorableJay: 2013-04-16 06:31:59 pm

honorableJay: 2013-04-16 06:21:33 pm

honorableJay: 2013-04-16 06:20:00 pm

2013-04-16 06:19:00 pm

The Dork Knight himself.

Very interesting. I think the best compromise would be to use the 640x240 and set the aspect ratio to 4:3. That actually gets what I want in the end since even with bilinear or bicubic filtering the text doesn't get completely muddy and is perfectly readable.

One thing I did notice with the 320x240 pointresize is it introduces vertical bars in the final video that are very distracting. The point resize does preserve the text better, but doubling the filesize is really interesting.

As far as softer edges being easier to compress, I'm guessing the encoder is simply blending the pixels on soft edges to lower the file size (since the detail is halfway gone to begin with) but with sharp edges it doesn't blend to keep the original detail.

ballofsnow

2013-04-17 10:27:29 am

The 640x240 was just an experiment... see what can be done... I mean it's cool that it worked but when you step back and look at it, it's kind of a shitty solution/compromise. It's the KISS principle, just go 640x480 and avoid potential headaches. If you're doing it just for yourself, ok fine, but I'd be hesitant to hand out such 640x240 videos to others, and I don't see it ever becoming sda official.

Anyway, back to Yua testing..

nate

2013-04-19 08:41:15 am

just a small update. in the last few days there have been several (4+) runs submitted to the site as vobs with nonmonotonic timestamps. this means if you open the vob in vlc it goes like 0:01 0:02 0:03 0:04 0:02 0:03 0:04 0:05 0:03 0:04. that's an exaggeration but you get the idea. the regressions don't seem to be related to anything the runner was doing in many cases. now this is not a big deal on its own because it's exactly as though several vobs were concatenated to form one. however it has special implications for yua.

the only way yua could seek in a frame-accurate way in a file without an index (such as a vob, an mpeg-2 stream) was to use av_seek_frame() with a decoding timestamp (dts) yua learned while indexing the stream (happens on open, "yua is examining the video"). obviously when the dts values in the file are like 1 2 3 4 2 3 4 5 6 7 2 3 4 that no longer works. if we go to dts 4, which one is it? it seems to use the last one in the file. either that or the one nearest the current position. so scrubbing through a file like this is totally insane. you see frames from all over the video. so i need to write another way of seeking in files like this.

luckily i seem to have worked out something that works last night. when indexing the file, also record byte offsets in the file where the first packets containing keyframes are. then use avformat_seek_file() in AVSEEK_FLAG_BYTE | AVSEEK_FLAG_BACKWARD mode to seek to that offset. unfortunately this does not work at all for indexed formats such as my standard Clip.avi of knuckles in angel island 1 - no frames can be decoded successfully. so my guess right now is that i am going to have to distinguish between formats and use the correct seeking method. that's assuming indexed formats will never have nonmonotonic timestamps but so far so good on that ... realistically the ffmpeg encoders i've used don't even allow you to write nonmonotonic timestamps to an indexed file format so maybe that's going to be exceedingly rare. if not then it'll just be back to the workshop to try to figure something out.

i also considered going ahead and implementing appending and using that system to pretend that vobs with retrograde timestamps are more than one vob appended, but i felt like that was inappropriately complex given the fact that i can read through the whole file and decode it successfully one frame at a time; it's just that the timestamps interfered with frame-accurate seeking, so it made more sense to try to fix seeking.

just a small update. in the last few days there have been several (4+) runs submitted to the site as vobs with nonmonotonic timestamps. this means if you open the vob in vlc it goes like 0:01 0:02 0:03 0:04 0:02 0:03 0:04 0:05 0:03 0:04. that's an exaggeration but you get the idea. the regressions don't seem to be related to anything the runner was doing in many cases. now this is not a big deal on its own because it's exactly as though several vobs were concatenated to form one. however it has special implications for yua.

the only way yua could seek in a frame-accurate way in a file without an index (such as a vob, an mpeg-2 stream) was to use av_seek_frame() with a decoding timestamp (dts) yua learned while indexing the stream (happens on open, "yua is examining the video"). obviously when the dts values in the file are like 1 2 3 4 2 3 4 5 6 7 2 3 4 that no longer works. if we go to dts 4, which one is it? it seems to use the last one in the file. either that or the one nearest the current position. so scrubbing through a file like this is totally insane. you see frames from all over the video. so i need to write another way of seeking in files like this.

luckily i seem to have worked out something that works last night. when indexing the file, also record byte offsets in the file where the first packets containing keyframes are. then use avformat_seek_file() in AVSEEK_FLAG_BYTE | AVSEEK_FLAG_BACKWARD mode to seek to that offset. unfortunately this does not work at all for indexed formats such as my standard Clip.avi of knuckles in angel island 1 - no frames can be decoded successfully. so my guess right now is that i am going to have to distinguish between formats and use the correct seeking method. that's assuming indexed formats will never have nonmonotonic timestamps but so far so good on that ... realistically the ffmpeg encoders i've used don't even allow you to write nonmonotonic timestamps to an indexed file format so maybe that's going to be exceedingly rare. if not then it'll just be back to the workshop to try to figure something out.

i also considered going ahead and implementing appending and using that system to pretend that vobs with retrograde timestamps are more than one vob appended, but i felt like that was inappropriately complex given the fact that i can read through the whole file and decode it successfully one frame at a time; it's just that the timestamps interfered with frame-accurate seeking, so it made more sense to try to fix seeking.

ballofsnow

2013-04-19 10:17:28 am

Is this related to the problem I had with my DMC3 vob?

https://docs.google.com/spreadsheet/ccc?key=0AqZ-c9XrMkM7dFFzU25zbWJ0anhGaFMyLXpoeUY2ZXc#gid=0
MPEG2_AC3_720x480i_4x3_2997_YUV420_D1F13D---DMC3.VOB
No crash this time. HQ=CFR, length 5:30. MQ&LQ=VFR, both ~full framerate, length 2:52, playback too fast.

Also check out the mario test at the top of the spreadsheet. I'm seeing very strange time issues in alpha 7.

honorableJay

2013-04-19 12:11:54 pm

The Dork Knight himself.

I'm assuming that creating a yua-only index (i.e. doesn't get written to the file but is generated while reading the frames) is too resource heavy or is this what you're already trying to do?

nate

2013-04-19 05:15:45 pm

Quote from ballofsnow:

Is this related to the problem I had with my DMC3 vob?

https://docs.google.com/spreadsheet/ccc?key=0AqZ-c9XrMkM7dFFzU25zbWJ0anhGaFMyLXpoeUY2ZXc#gid=0
MPEG2_AC3_720x480i_4x3_2997_YUV420_D1F13D---DMC3.VOB
No crash this time. HQ=CFR, length 5:30. MQ&LQ=VFR, both ~full framerate, length 2:52, playback too fast.

Also check out the mario test at the top of the spreadsheet. I'm seeing very strange time issues in alpha 7.

yeah, probably. i'm unable to connect to your sftp atm to verify it but it will be interesting to see how many of these issues magically clear up when i release alpha 8. also, you will actually be able to see for yourself what's going on with the decoded timestamps with two new debug logs i create on the desktop. the format i use makes it very easy to see whether the input is strict cfr or not.

Quote from honorableJay:

I'm assuming that creating a yua-only index (i.e. doesn't get written to the file but is generated while reading the frames) is too resource heavy or is this what you're already trying to do?

yeah, yua creates an index for every file when you open it regardless of the type ("yua is examining the video ..."). it's nate-style programming i guess. don't trust what's there - perform the worst-case actions every time.

[quote="ballofsnow"]Is this related to the problem I had with my DMC3 vob?

https://docs.google.com/spreadsheet/ccc?key=0AqZ-c9XrMkM7dFFzU25zbWJ0anhGaFMyLXpoeUY2ZXc#gid=0
MPEG2_AC3_720x480i_4x3_2997_YUV420_D1F13D---DMC3.VOB
No crash this time. HQ=CFR, length 5:30. MQ&LQ=VFR, both ~full framerate, length 2:52, playback too fast.

Also check out the mario test at the top of the spreadsheet. I'm seeing very strange time issues in alpha 7.[/quote]
yeah, probably. i'm unable to connect to your sftp atm to verify it but it will be interesting to see how many of these issues magically clear up when i release alpha 8. also, you will actually be able to see for yourself what's going on with the decoded timestamps with two new debug logs i create on the desktop. the format i use makes it very easy to see whether the input is strict cfr or not.

[quote="honorableJay"]I'm assuming that creating a yua-only index (i.e. doesn't get written to the file but is generated while reading the frames) is too resource heavy or is this what you're already trying to do?[/quote]
yeah, yua creates an index for every file when you open it regardless of the type ("yua is examining the video ..."). it's nate-style programming i guess. don't trust what's there - perform the worst-case actions every time.

gyth

2013-04-19 06:12:02 pm

Quote from honorableJay:

It's too bad we can't get more clarity out of the 320x240 encodes during playback resizing Sad

You can get better clarity on encode by cropping the non image pixels.

Code:

avisource("ama.avi")
assumetff
separatefields
crop(28,10,582,224)
lanczosresize(320,224,taps=2)

Attachments:

320x224.png

320x240.png

honorableJay

2013-04-19 07:47:12 pm

The Dork Knight himself.

Gyth: true, but as soon as you resize that image with any normal video player the clarity on things like text is completely destroyed.

nate

2013-04-21 05:32:30 pm

alpha 8.

- pretty display of video and audio stream information
- frame number and current timestamp display
- new seeking mode for "stream" format files (e.g. vobs); should work even in streams with retrograde timestamps
- automatic audio level normalization: in yo face avisynth
- aspect ratio is now a checkbox: if it's unchecked then yua won't touch the aspect ratio
- cli: the opposite of --widescreen is --standard; if you specify neither and the input is progressive scan then the aspect ratio checkbox will not be checked
- bugfix: apparently avresample_convert() flips stereo channels
- bugfix: avoid quacktime-incompatible 64-bit timestamps on frames by reducing the video container's timebase denominator to something sane

snow et al: you can inspect input streams' timestamps and what the yua encoders do with them with the four new logfiles. the files show the current frame timestamp and the difference between it and the previous frame timestamp. a bang means something went wrong, usually yua had to autogenerate the timestamp because it would have been nonmonotonic.

support for retrograde vobs is not quite done yet. i don't account for the case when the difference between the previous timestamp and the first retrograde timestamp is not modulo the standard monotonic increase. this causes up to one frame of desync after the timewarp. since timewarps happen every few seconds in some of these retrograde vobs (zelda 1 no up+a, i'm looking at you), the desync is noticeable soon enough.

right now my dogfooding of yua with sda material is working extremely well. all of the improvements this time came from using yua in my normal sda work. i'm actually feeling kind of good about this release. it's weird.

alpha 8.

- pretty display of video and audio stream information
- frame number and current timestamp display
- new seeking mode for "stream" format files (e.g. vobs); should work even in streams with retrograde timestamps
- automatic audio level normalization: in yo face avisynth
- aspect ratio is now a checkbox: if it's unchecked then yua won't touch the aspect ratio
- cli: the opposite of --widescreen is --standard; if you specify neither and the input is progressive scan then the aspect ratio checkbox will not be checked
- bugfix: apparently avresample_convert() flips stereo channels
- bugfix: avoid quacktime-incompatible 64-bit timestamps on frames by reducing the video container's timebase denominator to something sane

snow et al: you can inspect input streams' timestamps and what the yua encoders do with them with the four new logfiles. the files show the current frame timestamp and the difference between it and the previous frame timestamp. a bang means something went wrong, usually yua had to autogenerate the timestamp because it would have been nonmonotonic.

support for retrograde vobs is not quite done yet. i don't account for the case when the difference between the previous timestamp and the first retrograde timestamp is not modulo the standard monotonic increase. this causes up to one frame of desync after the timewarp. since timewarps happen every few seconds in some of these retrograde vobs (zelda 1 no up+a, i'm looking at you), the desync is noticeable soon enough.

right now my dogfooding of yua with sda material is working extremely well. all of the improvements this time came from using yua in my normal sda work. i'm actually feeling kind of good about this release. it's weird.

nate

2013-04-23 08:57:12 am

found out this morning that yua can get all the audio from avi files with pcm audio >= 2³² bytes. credit goes entirely to ffmpeg. this is a 7:23:19.26 long avi with 44100 hz 16-bit stereo audio saved from vdub from an avisynth script that appended two avis each of about half that length.

of course the only reason i found this out is that yua doesn't support appending yet so i had to append the files using the old school windows tools.

bos

2013-04-23 10:26:04 am

How does that work? Is it not using wav at all and is just raw pcm and it doesn't have that 32 bit limitation? Or is their a 32 bit limitation and interleaving comes into play somehow? I have no idea.

nate

Edit history:

nate: 2013-04-23 11:32:27 am

nate: 2013-04-23 11:07:16 am

2013-04-23 10:57:20 am

best guess is ffmpeg's avi format code has a special case and ignores the length value in the header. i'm not exactly clear on the details of the situation. i thought that, when it comes to avi, pcm == wav. but like you say, maybe not. the thing is that this is an avi produced by virtualdub. in this exact same situation, stock anri's windows toolchain can't give you audio past the 32-bit boundary. one thing i should check when i get home is whether i can open the .avi file in vdub, seek somewhere in the last 10% or whatever of the file, and hit spacebar and hear audio. my hypothesis right now is no because why would virtualdub be different from avisynth? they both rely on the same vfw avi format code that hasn't changed in like 10-15 years right?

edit: reading this it seems like vdub may simply append 4 gb chunks one after the other, setting the size in the header of each one to 2³²-1 until the last one. then the reason for the dropout at the 32-bit boundary is vfw not supporting this scheme - not looking for additional chunks. still interested to see whether vdub supports it - whether it can read all the audio in files it wrote, lol. but again this is all guesswork by me because googling for info on how ffmpeg does things is totally hopeless as usual.

edit 2: decided to ask where someone is likely to know the details.

best guess is ffmpeg's avi format code has a special case and ignores the length value in the header. i'm not exactly clear on the details of the situation. i thought that, when it comes to avi, pcm == wav. but like you say, maybe not. the thing is that this is an avi produced by virtualdub. in this exact same situation, stock anri's windows toolchain can't give you audio past the 32-bit boundary. one thing i should check when i get home is whether i can open the .avi file in vdub, seek somewhere in the last 10% or whatever of the file, and hit spacebar and hear audio. my hypothesis right now is no because why would virtualdub be different from avisynth? they both rely on the same vfw avi format code that hasn't changed in like 10-15 years right?

edit: reading [url=http://en.wikipedia.org/wiki/RF64]this[/url] it seems like vdub may simply append 4 gb chunks one after the other, setting the size in the header of each one to 2[sup]32[/sup]-1 until the last one. then the reason for the dropout at the 32-bit boundary is vfw not supporting this scheme - not looking for additional chunks. still interested to see whether vdub supports it - whether it can read all the audio in files it wrote, lol. but again this is all guesswork by me because googling for info on how ffmpeg does things is totally hopeless as usual.

edit 2: [url=http://forums.virtualdub.org/index.php?act=ST&f=2&t=21593]decided to ask where someone is likely to know the details.[/url]

Tranquilite

2013-04-23 07:53:23 pm

I did a test encode with a video file with almost completely silent audio, and the normalization boosted the volume until you could hear my computer thinking. I suppose few people will do encodes with such quiet sound, but it's interesting to note anyway. You may want to make audio normalization optional, or perhaps have a normalization threshold.

Attachment:

yua_XQ.mp4

Tranquilite

2013-04-23 07:56:53 pm

Oh and here is the original audio in case you are interested.

Attachment:

almostsilent.wav

nate

2013-04-23 09:20:06 pm

heh, cool. my old pc had really cheap on-board audio hardware so i'm pretty familiar with that phenomenon. i think the solution for pc capture people is to just boost the recording level in the first place so the signal to noise ratio is better. then like for nes capture you will hear some noise from the system, but that's the way it is ... you are always going to hear that if you turn the volume up. all i'm doing is turning the volume up for you so you don't have to do it watching runs you download from this site.

at some point i may decide to add an "expert features" dialog or something like that with a warning to keep novice users out. i've managed to avoid that thus far and i'm starting to feel like i can see the light at the end of the tunnel in terms of development. we shall see. for a long time i thought i would never throttle the preview display while encoding and i did that so who knows.

denart5

2013-04-26 01:14:31 pm

Doesn't show show the recorded avi files and crashes when I click encode

Mystery

2013-04-26 01:22:27 pm

It might help if you had a sample of what you are trying to encode.

denart5

2013-04-26 01:26:00 pm

Quote from Mystery:

It might help if you had a sample of what you are trying to encode.

I tested it with a 5 second, 800/600, 60 fps, 184 mb .AVI file recorded with dxtory. The window where the game preview should be is blank.

Patrick

2013-04-26 02:04:14 pm

sample means 'upload the file'. I'd record a 0.5-second clip and attach that to the post (next to 'preview').

Molotov

2013-04-26 05:48:11 pm

I've been having some trouble using Yua lately and I can't understand why. I'll give it a file to encode and it will seem to work fine, but then it gets to the end of the encode and literally gives up. No error message or crash (it popped up a message once and it hasn't happened since), but it just stops trying. It only happens when I encode insane quality or higher, so the main three settings work perfectly fine. Sometimes I can fix it by replacing the .exe with a new copy and trying again, but that doesn't always work.

I'd upload a file if my internet wasn't total garbage, but I'm not sure what good it would do when it has happened to multiple videos. I doubt it matters, but for whatever reason my copy of Anri-chan won't encode high quality videos anymore either (insane and higher is fine). It always complains about some line not existing in the AVS file and won't continue. Could I have borked Avisynth somehow and it's affecting Yua too? This is all very confusing without any error messages.

If it matters, I'm encoding with these settings: Progressive scan, widescreen, D1, F2, 3D, insane quality, and normal station ID.

I've been having some trouble using Yua lately and I can't understand why. I'll give it a file to encode and it will seem to work fine, but then it gets to the end of the encode and literally gives up. No error message or crash (it popped up a message once and it hasn't happened since), but it just stops trying. It only happens when I encode insane quality or higher, so the main three settings work perfectly fine. Sometimes I can fix it by replacing the .exe with a new copy and trying again, but that doesn't always work.

I'd upload a file if my internet wasn't total garbage, but I'm not sure what good it would do when it has happened to multiple videos. I doubt it matters, but for whatever reason my copy of Anri-chan won't encode high quality videos anymore either (insane and higher is fine). It always complains about some line not existing in the AVS file and won't continue. Could I have borked Avisynth somehow and it's affecting Yua too? This is all very confusing without any error messages.

If it matters, I'm encoding with these settings: Progressive scan, widescreen, D1, F2, 3D, insane quality, and normal station ID.

nate

2013-04-26 07:53:32 pm

there is a known crash with encoding high resolution input under windows. i'm working on it but it's slow going. it sounds like you're hitting that because sometimes windows will pop up a crash dialog and sometimes not (due to yua calling exit(1) following a fatal error from ffmpeg). if you have access to a mac or linux machine (or virtual machine), that should solve the problem temporarily. in the meantime ... i'm working on it. with any luck i'll have plenty of time to plow into it this weekend.

i'm less qualified to speak about anri. the problems are unrelated though since yua has nothing to do with avisynth.

Carcinogen

2013-04-27 07:30:11 am

One thing you could add with the next build that would be convenient and awesome - the option to shut down the computer when encoding is finished.

Dead serious.

nate

2013-04-27 07:52:50 am

noted.

Mystery

2013-04-27 03:59:38 pm

Quote from nate:

...(due to yua calling exit(1) following a fatal error from ffmpeg)...

Is it wise to do that? I cannot speak for your code, but std::exit does not call destructors for local variables. Perhaps it might just be better to throw some exception that is not caught?