yua

2013-06-08 06:15:57 am

Due to internationalism, it is usually best to keep shortcuts to the letters A-Z; otherwise you are going to get issues with people having different keyboard layouts.
(Dunno how easy/bad it would be on a japanese/chinese keyboard, or for any non-latin alphabet keyboards, though.)

nate

2013-06-08 04:16:16 pm

alpha 11. bumped to fix a number of issues.

- append more than one file at a time (thanks ird)
- remember the last directory even under windows (thanks ird)
- fixed xq height threshold for ui (thanks ird)
- different keyboard shortcuts for setting trim points (more virtualdub-like) (thanks freakypaddy)
- "go to frame" dialog (should make marking anri-style trim ranges quicker)

Quote from IsraeliRD:

1) Can we get a 'save project' where it saves the project, the videos etc. so it can load much faster? I just accidentally pressed open instead of append without realising and lost the last 15 minutes of videos appending.

i've been thinking about this. i may wait until after the first non-beta release since it may be best integrated with cancel/resume encoding.

Quote from presjpolk:

"same directory as the yua program" makes no sense on Mac OS but I'm patient (I'm also skipping this release since I don't care about appending or multiple trim points Smiley

you're overthinking it - a lot of times i write with normal users in mind. force of habit. in power user terms, it's the same directory as the application bundle.

Code:

        QDir application_dir;
        application_dir.cd(QCoreApplication::applicationDirPath());
#ifdef Q_OS_MAC
        application_dir.cd("../../.."); //get out of the bundle
#endif
        QFileInfo alternate_statid_info(application_dir, "statid.png");
        if (alternate_statid_info.exists()) {
[...]

alpha 11. bumped to fix a number of issues.

- append more than one file at a time (thanks ird)
- remember the last directory even under windows (thanks ird)
- fixed xq height threshold for ui (thanks ird)
- different keyboard shortcuts for setting trim points (more virtualdub-like) (thanks freakypaddy)
- "go to frame" dialog (should make marking anri-style trim ranges quicker)

[quote="IsraeliRD"]
1) Can we get a 'save project' where it saves the project, the videos etc. so it can load much faster? I just accidentally pressed open instead of append without realising and lost the last 15 minutes of videos appending.[/quote]
i've been thinking about this. i may wait until after the first non-beta release since it may be best integrated with cancel/resume encoding.

[quote="presjpolk"]"same directory as the yua program" makes no sense on Mac OS but  I'm patient (I'm also skipping this release since I don't care about appending or multiple trim points :)[/quote]
you're overthinking it - a lot of times i write with normal users in mind. force of habit. in power user terms, it's the same directory as the application bundle.
[code]        QDir application_dir;
        application_dir.cd(QCoreApplication::applicationDirPath());
#ifdef Q_OS_MAC
        application_dir.cd("../../.."); //get out of the bundle
#endif
        QFileInfo alternate_statid_info(application_dir, "statid.png");
        if (alternate_statid_info.exists()) {
[...][/code]

presjpolk

2013-06-08 08:01:00 pm

HELLO!

Put putting the image in my Applications folder isn't really... elegant. Smiley

UraniumAnchor

2013-06-08 10:21:28 pm

Not a walrus

There's a reason it still says "alpha".

IsraeliRD

Edit history:

IsraeliRD: 2013-06-09 12:39:28 am

2013-06-09 12:38:37 am

Dragon Power Supreme

Quote from nate:

Quote from IsraeliRD:

1) Can we get a 'save project' where it saves the project, the videos etc. so it can load much faster? I just accidentally pressed open instead of append without realising and lost the last 15 minutes of videos appending.

i've been thinking about this. i may wait until after the first non-beta release since it may be best integrated with cancel/resume encoding.

It would be nice to see it earlier Smiley

Also a BSOD on XQ (alpha 10). I suspect it crashed when trying to merge the video and audio mp4s (which are still in the temp dir)
Currently I'm 8 hours into a second attempt and encoding one by one from LQ onwards, so I'll see if IQ/XQ cause a second BSOD.

The oddest thing is that yua says I have 20 minutes of video when I know I got at least 30 minutes, yet none of the footage seems to be missing from the preview.

nate

2013-06-09 09:00:38 am

heh, i bet you that bsod is because i started linking yua with the unsigned 32-bit integer memory address flag. realistically x264 needs more than 1.5 gigs of ram to encode 1080p input. when any 32-bit (like yua) process goes much beyond 1.5 gig without that flag set, the os kills the process. this is actually the same problem with crashes under windows that i solved before by trimming things down. i can no longer do that realistically, so i went a-researching and discovered that with this flag set, 32-bit programs can use up to 3 gigs of ram under 32-bit windows and up to 4 gigs under 64-bit windows. problem solved, i thought. well, not so much if you don't have a lot of ram, apparently. btw, i love how windows detonates instead of something more like software made in the last 15 years would do. truly a toy.

so what are your system specs exactly? i recall you run xp which of course is 32-bit but how much ram does it say you have under my computer -> properties?

btw, i'm not even sure whether i can build a windows 64-bit version of yua. it would certainly be an enormous burden if it's even possible. i already tried all the ways of compromising on quality to get x264 to use less ram (in particular, the keyint and rc-lookahead settings), but those didn't seem to have any effect on memory use. i know they took effect because i saw my custom values in the initial glob of text x264 spews. weird. i'm not happy with telling people encoding 1080p to get more ram, but it may be the best answer.

Quote from IsraeliRD:

The oddest thing is that yua says I have 20 minutes of video when I know I got at least 30 minutes, yet none of the footage seems to be missing from the preview.

sorry, i forgot to mention this before. if you are appending videos with different framerates then the timestamps on them in the preview will not be accurate. if the framerates are identical then the timestamps should theoretically be fairly accurate, down to the second or so.

heh, i bet you that bsod is because i started linking yua with the unsigned 32-bit integer memory address flag. realistically x264 needs more than 1.5 gigs of ram to encode 1080p input. when any 32-bit (like yua) process goes much beyond 1.5 gig without that flag set, the os kills the process. this is actually the same problem with crashes under windows that i solved before by trimming things down. i can no longer do that realistically, so i went a-researching and discovered that with this flag set, 32-bit programs can use up to 3 gigs of ram under 32-bit windows and up to 4 gigs under 64-bit windows. problem solved, i thought. well, not so much if you don't have a lot of ram, apparently. btw, i love how windows detonates instead of something more like software made in the last 15 years would do. truly a toy.

so what are your system specs exactly? i recall you run xp which of course is 32-bit but how much ram does it say you have under my computer -> properties?

btw, i'm not even sure whether i can build a windows 64-bit version of yua. it would certainly be an enormous burden if it's even possible. i already tried all the ways of compromising on quality to get x264 to use less ram (in particular, the keyint and rc-lookahead settings), but those didn't seem to have any effect on memory use. i know they took effect because i saw my custom values in the initial glob of text x264 spews. weird. i'm not happy with telling people encoding 1080p to get more ram, but it may be the best answer.

[quote="IsraeliRD"]
The oddest thing is that yua says I have 20 minutes of video when I know I got at least 30 minutes, yet none of the footage seems to be missing from the preview.[/quote]
sorry, i forgot to mention this before. if you are appending videos with different framerates then the timestamps on them in the preview will not be accurate. if the framerates are identical then the timestamps should theoretically be fairly accurate, down to the second or so.

IsraeliRD

Edit history:

IsraeliRD: 2013-06-09 09:47:51 am

IsraeliRD: 2013-06-09 09:47:09 am

2013-06-09 09:46:29 am

Dragon Power Supreme

Quote from nate:

so what are your system specs exactly? i recall you run xp which of course is 32-bit but how much ram does it say you have under my computer -> properties?

I use Windows XP SP3, Core 2 Duo 2.4GHz, 4GB RAM, GeForce 8800GTS.
I seriously am going to get a new computer. Sometime Sad

IQ is still going (8:20 hours into it, right now 2nd pass and it's halfway through it).

I will try again XQ. I killed the majority of processes so I got 800mbs RAM used without yua. yua hits 1gb for IQ 1st pass, 400MBs for 2nd pass. XQ will be interesting.

Quote from nate:

Quote from IsraeliRD:

The oddest thing is that yua says I have 20 minutes of video when I know I got at least 30 minutes, yet none of the footage seems to be missing from the preview.

sorry, i forgot to mention this before. if you are appending videos with different framerates then the timestamps on them in the preview will not be accurate. if the framerates are identical then the timestamps should theoretically be fairly accurate, down to the second or so.

I thought yua would crash if I tried to encode videos of different framerates? or have I read you wrong?
Framerate is 30fps on all segments. I just don't know why it claims to be 10-15 mins less than what it should be. I'm watching the encoding as it happens and it's not missing anything.

[quote="nate"]so what are your system specs exactly? i recall you run xp which of course is 32-bit but how much ram does it say you have under my computer -> properties?[/quote]
I use Windows XP SP3, Core 2 Duo 2.4GHz, 4GB RAM, GeForce 8800GTS.
I seriously am going to get a new computer. Sometime :(
IQ is still going (8:20 hours into it, right now 2nd pass and it's halfway through it).

I will try again XQ. I killed the majority of processes so I got 800mbs RAM used without yua. yua hits 1gb for IQ 1st pass, 400MBs for 2nd pass. XQ will be interesting.

[quote="nate"][quote="IsraeliRD"]
The oddest thing is that yua says I have 20 minutes of video when I know I got at least 30 minutes, yet none of the footage seems to be missing from the preview.[/quote]
sorry, i forgot to mention this before. if you are appending videos with different framerates then the timestamps on them in the preview will not be accurate. if the framerates are identical then the timestamps should theoretically be fairly accurate, down to the second or so.[/quote]
I thought yua would crash if I tried to encode videos of different framerates? or have I read you wrong?
Framerate is 30fps on all segments. I just don't know why it claims to be 10-15 mins less than what it should be. I'm watching the encoding as it happens and it's not missing anything.

Mystery

2013-06-09 10:17:41 am

Quote from nate:

btw, i love how windows detonates instead of something more like software made in the last 15 years would do. truly a toy.

Probably because they insist on kernel drivers instead of a usermode kernel... oh how many times now I've wished windows didn't use kernel mode drivers. Drivers are buggy (A/V software too( no matter how well engineered they are, and as such will kill the OS once in a while.

nate

2013-06-09 10:37:29 am

i just found the bug. if you encode progressive scan material with a statid, the statid's framerate is wrong, and the ui thinks the whole video is double the framerate. i was sure i had this right before release but apparently not. so alpha 12 will be going up later today with this and some other bugs fixed.

Quote from IsraeliRD:

I thought yua would crash if I tried to encode videos of different framerates? or have I read you wrong?

it *may* crash. it depends on the actual framerates, but not in a way you can predict just by looking at them. i will be addressing this in the future.

Quote from Mystery:

Quote from nate:

btw, i love how windows detonates instead of something more like software made in the last 15 years would do. truly a toy.

Probably because they insist on kernel drivers instead of a usermode kernel... oh how many times now I've wished windows didn't use kernel mode drivers. Drivers are buggy (A/V software too( no matter how well engineered they are, and as such will kill the OS once in a while.

to be fair, os x has its share of bad kernelspace drivers too. the uvc (usb video class) one is a lot of fun. a few months ago i had a reproducible kernel panic with it using shared memory in my userspace program. it killed the system so fast the journal wasn't written for the changes in my latest build and one of my source files was corrupted. lost about two hours of work. it was 1995 again. blew my mind.

i just found the bug. if you encode progressive scan material with a statid, the statid's framerate is wrong, and the ui thinks the whole video is double the framerate. i was sure i had this right before release but apparently not. so alpha 12 will be going up later today with this and some other bugs fixed.

[quote="IsraeliRD"]I thought yua would crash if I tried to encode videos of different framerates? or have I read you wrong?[/quote]
it *may* crash. it depends on the actual framerates, but not in a way you can predict just by looking at them. i will be addressing this in the future.

[quote="Mystery"][quote="nate"]btw, i love how windows detonates instead of something more like software made in the last 15 years would do. truly a toy.[/quote]
Probably because they insist on kernel drivers instead of a usermode kernel... oh how many times now I've wished windows didn't use kernel mode drivers. Drivers are buggy (A/V software too( no matter how well engineered they are, and as such will kill the OS once in a while.[/quote]
to be fair, os x has its share of bad kernelspace drivers too. the uvc (usb video class) one is a lot of fun. a few months ago i had a reproducible kernel panic with it using shared memory in my userspace program. it killed the system so fast the journal wasn't written for the changes in my latest build and one of my source files was corrupted. lost about two hours of work. it was 1995 again. blew my mind.

presjpolk

2013-06-09 01:22:05 pm

HELLO!

Quote from UraniumAnchor:

There's a reason it still says "alpha".

Like I said, I'm patient. Smiley

nate

2013-06-09 02:56:02 pm

alpha 12.

i fixed the progressive scan "ui thinks the framerate is double" bug ird found and also some other hangs/crashes. no one should use alpha 10 or 11 because the double framerate bug meant the lower qualities came out with the wrong framerate. i also added in caching for the statid image so encoding the statid is much faster now.

IsraeliRD

2013-06-09 06:26:34 pm

Dragon Power Supreme

Just checked the videos (LQ-IQ) and the reported time is actually fine, so it was indeed just the ui doing this. The framerate was wrong though (29.797fps) but that's due to the statid. I'm going to run XQ on this comp (yua 12, so ill redo my whole thing) and on my work laptop (win7 SP1 64-bit, core i7, 8gb ram, radeon hd 7690m xt (and intel HD gfx as well)) which I just remembered exists.

One thing that is annoying, is that when my computer decides to standby after a while, yua pauses its encoding and will not resume until I kick back my computer on. Anri 3.3 does however encode regardless. I remember older versions of yua encoding regardless even if the computer is in standby mode but I could be wrong. Can you change the behavior for it?

nate

2013-06-09 06:34:19 pm

wild, i have no idea about that. wonder if x264.exe that anri runs prevents the machine from sleeping or something. that doesn't explain why you're seeing different behavior with yua now though since i haven't changed anything in terms of the process structure since alpha 3 or something.

IsraeliRD

Edit history:

IsraeliRD: 2013-06-09 06:50:27 pm

IsraeliRD: 2013-06-09 06:47:43 pm

IsraeliRD: 2013-06-09 06:47:15 pm

2013-06-09 06:46:47 pm

Dragon Power Supreme

Odd. Maybe that's why it stopped since alpha 3. Couple more bug reports:
- Checking Audio Commentary in Win7 yua alpha 12 has the audio track text appearing, but it's very big and goes off the edges of the UI (you see: UDIO COMMENTARY ON TRACK).
- The auto text resize function (so it makes smaller text for any of the lines if there are too many characters so it fits in) does not work in WinXP, instead the text just overflows and goes off the screen.

nate

2013-06-09 07:30:13 pm

okay well i guess that explains the behavior that person was reporting last week. wonder if that's an xp thing ... seems to be working for me atm under windows 7.

IsraeliRD

Edit history:

IsraeliRD: 2013-06-10 02:03:57 am

IsraeliRD: 2013-06-10 02:02:56 am

2013-06-10 01:59:52 am

Dragon Power Supreme

XQ worked the second time around. Shows up as 29.847fps. The FPS of all videos is wrong, it should be 30fps. yua10 was used in IQ, yua12 for XQ. XQ encode has no StatID.
I suspect the reason why the messed up FPS is caused is due to the EA Games intro which is not 30fps despite being recorded in 30fps. A few months ago I had sent you ThemeParkInc-Segment01a.7z which contains that intro. Can you look into it?

After encoding on Windows 7 (see specs above) I noticed the IQ video was 106MBs smaller than on my computer (WinXP). HQ smaller by 70MBs and the other two were roughly equal. XQ on the other hand was 40MBs smaller on my comp than Win7 (lack of StatID probably caused that).
All Win7 encoded videos were 29.852fps instead of 30.000.

Another question is about the RAM usage. During the encoding of XQ the RAM use just kept going up as the video went on. I started with 800MBs, ended with 1.3GBs. Win7 started on 1.4GBs, ended with 2GBs. No other quality does that. Could you explain why this occurs? Just curious, that's all.

XQ worked the second time around. Shows up as 29.847fps. The FPS of all videos is wrong, it should be 30fps. yua10 was used in IQ, yua12 for XQ. XQ encode has no StatID.
I suspect the reason why the messed up FPS is caused is due to the EA Games intro which is not 30fps despite being recorded in 30fps. A few months ago I had sent you ThemeParkInc-Segment01a.7z which contains that intro. Can you look into it?

After encoding on Windows 7 (see specs above) I noticed the IQ video was 106MBs smaller than on my computer (WinXP). HQ smaller by 70MBs and the other two were roughly equal. XQ on the other hand was 40MBs smaller on my comp than Win7 (lack of StatID probably caused that).
All Win7 encoded videos were 29.852fps instead of 30.000.

Another question is about the RAM usage. During the encoding of XQ the RAM use just kept going up as the video went on. I started with 800MBs, ended with 1.3GBs. Win7 started on 1.4GBs, ended with 2GBs. No other quality does that. Could you explain why this occurs? Just curious, that's all.

Attachment:

yua12results.zip

Onin

2013-06-11 06:46:28 am

Three things:

1. Is Shutdown on finishing intended to shut down your pc, as opposed to just the application? If it is, might want to add the latter as an option and make the former a bit clearer.
2. "Muxing" =/= "Mixing" :3
3. It'd be nice to have an option whether to upscale or downscale segment resolutions. I accidentally recorded a segment at a higher resolution than the rest, and now everything is scaled up to its resolution, instead of it moving in line with the smaller ones. It looks a bit weird.

Mystery

2013-06-11 06:49:50 am

1) AFAIK, shut down computer. I've never heard of any "shut down application when complete" option in any program anyway.

nate

2013-06-11 08:55:11 am

Quote from IsraeliRD:

I suspect the reason why the messed up FPS is caused is due to the EA Games intro which is not 30fps despite being recorded in 30fps. A few months ago I had sent you ThemeParkInc-Segment01a.7z which contains that intro. Can you look into it?

it's more likely yua decided it needed to pad the audio at some point and there was a single interframe delta that ended up nonmonotonic (slightly more or slightly less than the usual) and believe it or not that one delta is enough to skew the average framerate calculation. i'm seeing this a lot recently with screen capture videos. i'm not quite sure what to do about it atm. i've already spent many hours trying to eliminate spurious vfr (i know - sunk cost and all that) but the whole aligned splice thing is just so challenging for me. how do i know when the splice is over? like, if i need to pad the audio by 1.25 video frames, when does that quarter frame come back in? what if you have 100 segments and the audio needs to be padded by 1.25 video frames between each one? if i ignore the .25 then the audio will be 25 frames out of sync by the end, unacceptable.

Quote from IsraeliRD:

Another question is about the RAM usage. During the encoding of XQ the RAM use just kept going up as the video went on. I started with 800MBs, ended with 1.3GBs. Win7 started on 1.4GBs, ended with 2GBs. No other quality does that. Could you explain why this occurs? Just curious, that's all.

the other qualities do it in my experience, it's just that the growth is smaller so it's harder to notice. i'm not sure if you're asking about the usage pattern or the actual absolute numbers. if it's the latter then it's a kind of unintuitive thing about video resolution that's to blame. sometimes people think that 720p video is only a little larger than 480p video, like maybe a third bigger or something. i mean it's the next standard size up after all. but it's actually 3x bigger. (1280x720)/(640x480). it's because both dimensions grow so it's ² growth. and 1080p is over 2x larger than 720p. x264 has to hold a number of frames in memory all at once in order to work (to compare them and to eliminate unnecessary information) so every time you go to a higher resolution the growth is exponential. i would imagine that you would need at least 8 gigs of ram to encode so-called 4k resolution video.

Quote from Onin:

1. Is Shutdown on finishing intended to shut down your pc, as opposed to just the application? If it is, might want to add the latter as an option and make the former a bit clearer.

mystery has it. it's really a shame "computer" is such a long word. "system" isn't much better. and i haven't been able to think of any shorter replacements for shut down that carry the same meaning. "halt" of course is the unix term but hell if anyone knows that, haha.

Quote from Onin:

2. "Muxing" =/= "Mixing" :3

the correct term for what yua does for its last stage is muxing. i think it's short for "multiplexing". "mixing" sounds like a professional audio term to me but i'm not a professional so who knows.

Quote from Onin:

3. It'd be nice to have an option whether to upscale or downscale segment resolutions. I accidentally recorded a segment at a higher resolution than the rest, and now everything is scaled up to its resolution, instead of it moving in line with the smaller ones. It looks a bit weird.

yeah, atm i'm feeling a significant encroachment of "it would be nice" features that actually seem to have some convincing arguments that they ought to be included in the yua ui. like i mean, in this case, how are you supposed to solve the problem without resorting to windows tools or the unix cli? maybe i should have a conversation with my ui guy.

Quote from Onin:

3. It'd be nice to have an option whether to upscale or downscale segment resolutions. I accidentally recorded a segment at a higher resolution than the rest, and now everything is scaled up to its resolution, instead of it moving in line with the smaller ones. It looks a bit weird.

so it actually worked for you!? holy shit. maybe i'll get through this after all.

[quote="IsraeliRD"]I suspect the reason why the messed up FPS is caused is due to the EA Games intro which is not 30fps despite being recorded in 30fps. A few months ago I had sent you ThemeParkInc-Segment01a.7z which contains that intro. Can you look into it?[/quote]
it's more likely yua decided it needed to pad the audio at some point and there was a single interframe delta that ended up nonmonotonic (slightly more or slightly less than the usual) and believe it or not that one delta is enough to skew the average framerate calculation. i'm seeing this a lot recently with screen capture videos. i'm not quite sure what to do about it atm. i've already spent many hours trying to eliminate spurious vfr (i know - sunk cost and all that) but the whole aligned splice thing is just so challenging for me. how do i know when the splice is over? like, if i need to pad the audio by 1.25 video frames, when does that quarter frame come back in? what if you have 100 segments and the audio needs to be padded by 1.25 video frames between each one? if i ignore the .25 then the audio will be 25 frames out of sync by the end, unacceptable.

[quote="IsraeliRD"]Another question is about the RAM usage. During the encoding of XQ the RAM use just kept going up as the video went on. I started with 800MBs, ended with 1.3GBs. Win7 started on 1.4GBs, ended with 2GBs. No other quality does that. Could you explain why this occurs? Just curious, that's all.[/quote]
the other qualities do it in my experience, it's just that the growth is smaller so it's harder to notice. i'm not sure if you're asking about the usage pattern or the actual absolute numbers. if it's the latter then it's a kind of unintuitive thing about video resolution that's to blame. sometimes people think that 720p video is only a little larger than 480p video, like maybe a third bigger or something. i mean it's the next standard size up after all. but it's actually 3x bigger. (1280x720)/(640x480). it's because both dimensions grow so it's [sup]2[/sup] growth. and 1080p is over 2x larger than 720p. x264 has to hold a number of frames in memory all at once in order to work (to compare them and to eliminate unnecessary information) so every time you go to a higher resolution the growth is exponential. i would imagine that you would need at least 8 gigs of ram to encode so-called 4k resolution video.

[quote="Onin"]1. Is Shutdown on finishing intended to shut down your pc, as opposed to just the application? If it is, might want to add the latter as an option and make the former a bit clearer.[/quote]
mystery has it. it's really a shame "computer" is such a long word. "system" isn't much better. and i haven't been able to think of any shorter replacements for shut down that carry the same meaning. "halt" of course is the unix term but hell if anyone knows that, haha.

[quote="Onin"]2. "Muxing" =/= "Mixing" :3[/quote]
the correct term for what yua does for its last stage is muxing. i think it's short for "[u]mu[/u]ltiple[u]xing[/u]". "mixing" sounds like a professional audio term to me but i'm not a professional so who knows.

[quote="Onin"]3. It'd be nice to have an option whether to upscale or downscale segment resolutions. I accidentally recorded a segment at a higher resolution than the rest, and now everything is scaled up to its resolution, instead of it moving in line with the smaller ones. It looks a bit weird.[/quote]
yeah, atm i'm feeling a significant encroachment of "it would be nice" features that actually seem to have some convincing arguments that they ought to be included in the yua ui. like i mean, in this case, how are you supposed to solve the problem without resorting to windows tools or the unix cli? maybe i should have a conversation with my ui guy.

[quote="Onin"]3. It'd be nice to have an option whether to upscale or downscale segment resolutions. I accidentally recorded a segment at a higher resolution than the rest, and now everything is scaled up to its resolution, instead of it moving in line with the smaller ones. It looks a bit weird.[/quote]
so it actually worked for you!? holy shit. maybe i'll get through this after all.

DJS

2013-06-11 09:34:32 am

torch slug since 2006

im sure you said this somewhere, but what does yua do when its examining the video? it takes forever and anri didnt do it ;;;

its especially fun when it finishes examining, but then you do something wrong/crash yua/something else - and yua closes, and when you open it up, it has to examine the video again Cheesy

nate

2013-06-11 09:41:09 am

yeah, i've thought quite a bit about eliminating it for indexed formats (like avi and mp4) or moving it to just before encoding starts. right now it's mainly two things: determining the average monotonic timestamp increase (sort of like the average framerate) and determining the audio level normalization factor. for indexed format files with a valid index i could probably avoid doing the former but the latter would still have to happen before encoding. one problem is right now i don't know how to tell whether a file has a valid index.

a lot of this rough stuff will start to go away as yua moves toward beta. i'm aware of a lot of it but there are just too many other things on my plate right now. maybe i sneak one nice thing in to every major release but that still leaves a lot left to do to make this thing final release quality.

DJS

2013-06-11 09:45:28 am

torch slug since 2006

moving it to right before starting encoding would work for me. the main problem i have with it is, as i said, if i do something wrong that causes it to re-do it. moving it to right before encoding would solve it.

but alright, now i know why it does that, makes me less frustrated !

ballofsnow

2013-06-11 10:55:12 am

Quote from nate:

but the whole aligned splice thing is just so challenging for me. how do i know when the splice is over? like, if i need to pad the audio by 1.25 video frames, when does that quarter frame come back in? what if you have 100 segments and the audio needs to be padded by 1.25 video frames between each one? if i ignore the .25 then the audio will be 25 frames out of sync by the end, unacceptable.

I don't understand this part. Are you limited to padding in intervals of time, i.e. 30 fps = 33.33 ms per frame?

nate

2013-06-11 11:06:09 am

let's say i decode an audio frame that is 1.25 seconds in the future from where i expect it to be, i.e. there is now 1.25 seconds of missing audio. some players will ignore the timestamps in the short term so there will be desync on playback unless i pad the audio exactly 1.25 seconds (of silence). but what if the video framerate is 1 fps? assuming the next video frame has the same timestamp as that audio frame i decoded, the next video frame has to come 1.25 seconds later instead of 2 seconds later, thus vfr. it wouldn't be a problem except that users get nervous when they see 29.92 or something fps instead of 29.97. also there may be idiotic players that treat vfr differently (if they never pay attention to timestamps even in the long term then the sync will slowly drift).

ballofsnow

Edit history:

ballofsnow: 2013-06-11 11:18:22 am

2013-06-11 11:17:57 am

Quote from nate:

it wouldn't be a problem except that users get nervous when they see 29.92 or something fps instead of 29.97.

Pfft.. we're in VFR land now, people will need to get un-nervous. Maybe put a note somewhere in the GUI that the video will be encoded in variable framerate. I'm pretty sure Youtube already does VFR and obviously there is a lot of people using it, so there's some extra comfort.

Quote:

also there may be idiotic players that treat vfr differently (if they never pay attention to timestamps even in the long term then the sync will slowly drift).

I thought it was a given that some players wouldn't handle VFR, and the choice was made to go on anyway. If a media player doesn't work, just use a better one. I mean, if you're really concerned about compatibility, don't do VFR.