those all sound excellent and not difficult to implement.
I am proud of my former apprentice.
SDA Forum
alpha 3. first post.
i internalized audio: decoding, resampling/conversion, and encoding. this is the first step toward synchronization. already some input may be encoded with correct or at least better sync than with alpha 2. but again, until i finish synchronization (probably alpha 4), success will be more coincidental than anything.
i also fixed the non-mod-4 width bug (thanks presjpolk). apparently i don't know how to round up to mod 4.
i internalized audio: decoding, resampling/conversion, and encoding. this is the first step toward synchronization. already some input may be encoded with correct or at least better sync than with alpha 2. but again, until i finish synchronization (probably alpha 4), success will be more coincidental than anything.
i also fixed the non-mod-4 width bug (thanks presjpolk). apparently i don't know how to round up to mod 4.
I'm trying to feed a3 a high res 62 second LAGS RGB video but XQ is crashing. Started off by creating for myself a fraps video at 1920 x 1200 @ 30 fps, converting to LAGS RGB while cropping a bunch of smaller res versions.
Yua loads and examines video.
I can use the slider to seek around, no issues there.
I used defaults of Prog, D1, F1, 3D. No statid, no downmix.
Input: 1920 x 1200p @ 30fps; 5.08 GB; Lagarith RGB.
LQ only: Success. CPU maxed out. 384 x 240 final resolution.
MQ only: Success. CPU maxed out. 384 x 240 final resolution.
HQ only: Success. CPU maxed out. 768 x 480 final resolution.
IQ only: Success. CPU maxed out. 1228 x 768 final resolution.
XQ only: About 5 seconds in Yua crashes...
Input: 1920 x 1080p @ 30fps; 4.60 GB; Lagarith RGB.
XQ only: About 5 seconds in Yua crashes...
Input: 1280 x 720p @ 30fps; 2.06 GB; Lagarith RGB.
XQ only: Success.
Other notes:
Can you somehow make Yua run in low priority mode automatically? It's defaulting to normal.
Yua loads and examines video.
I can use the slider to seek around, no issues there.
I used defaults of Prog, D1, F1, 3D. No statid, no downmix.
Input: 1920 x 1200p @ 30fps; 5.08 GB; Lagarith RGB.
LQ only: Success. CPU maxed out. 384 x 240 final resolution.
MQ only: Success. CPU maxed out. 384 x 240 final resolution.
HQ only: Success. CPU maxed out. 768 x 480 final resolution.
IQ only: Success. CPU maxed out. 1228 x 768 final resolution.
XQ only: About 5 seconds in Yua crashes...
Input: 1920 x 1080p @ 30fps; 4.60 GB; Lagarith RGB.
XQ only: About 5 seconds in Yua crashes...
Input: 1280 x 720p @ 30fps; 2.06 GB; Lagarith RGB.
XQ only: Success.
Other notes:
Can you somehow make Yua run in low priority mode automatically? It's defaulting to normal.
Fucking Weeaboo
http://www.prnwatch.com/prio.html
You guys can use this to set any program to run at any priority level and have it remember that priority level every time it's run. Free to use.
You guys can use this to set any program to run at any priority level and have it remember that priority level every time it's run. Free to use.
Quote from nate:
cool, crashes. can you throw me that video?
5 GB for 60 seconds is a lot, so I kept cutting it down while still being able to get Yua to crash. I'm uploading a 5 second video, about 370 MB, will take about a half hour to upload. Will edit post. -- eh it's getting late here, here's the link, you may want to wait 45 minutes or so from this post's time before attempting to download.
What's funny is if I cut it down further to 3.33 seconds (usving vdub to do cutting), XQ works.
Edit history:
ballofsnow: 2013-02-26 11:03:13 am
ballofsnow: 2013-02-26 11:03:01 am
ballofsnow: 2013-02-26 11:02:47 am
Ok, I got it to crash.
Input: That 5 second video above of 1920 x 1200p @ 30fps Lagarith RGB.
XQ only.
Statid:
Line 1: a
Line 2: b
Line 3: c
SDA logo ticked.
Same test again as above, but IQ/HQ/MQ/LQ only = no crash.
Input: That 5 second video above of 1920 x 1200p @ 30fps Lagarith RGB.
XQ only.
Statid:
Line 1: a
Line 2: b
Line 3: c
SDA logo ticked.
Same test again as above, but IQ/HQ/MQ/LQ only = no crash.
think i may have gotten it. i always forget that ffmpeg wants you to use their unique data structures. apparently they overread/overwrite by a large number of bytes in some cases. it's not 16-byte alignment like you think. it's something else. anyway, i posted a new build, so please check it out. thanks.
Any plans to support avs files as input?
I just tried for the first time the Pismo File Mount + AVFS combo, pointed out by blizz recently and it seems to work in Yua. Very cool actually.
So why would XQ crash? My XQ 720p test worked, so I guess it's more about output resolution? Output file size? Could I crop down the 1920x1200 by 16 pixels at a time and find some seemingly arbitrary point where it stops crashing? Weird problem.
I just tried for the first time the Pismo File Mount + AVFS combo, pointed out by blizz recently and it seems to work in Yua. Very cool actually.
So why would XQ crash? My XQ 720p test worked, so I guess it's more about output resolution? Output file size? Could I crop down the 1920x1200 by 16 pixels at a time and find some seemingly arbitrary point where it stops crashing? Weird problem.
no plans to support .avs since that would mean porting avisynth in its entirety. they should have used lua or something. well, the world was a different place 10 years ago, too.
cool about that avfs thing. i guess it does its job really well since ffmpeg can't tell it's not an avi file. could be a good substitute for supporting avisynth in yua for windows users who also want to use yua's gui for some reason.
i got the beginning of synchronization done last night. writing the audio to a .ts file now since it supports adts headers which the aac encoder generates and timestamps. still need to do video, writing to an mp4 file hopefully instead of raw h.264. plan right now is still simply to copy the timestamps from the input where possible and to reconstruct missing ones (every other "frame" in the case of interlaced input). still haven't figured out exactly how i'm going to do this yet though since for example the output audio frame size is different from the input size.
then, theoretically, the output will be in sync if the input is in sync. can also allow users to correct constant desync by simply adding or subtracting the amount converted into the streams' timebases.
well, i don't know why it's crashing now, but yesterday i pretty much isolated it initially to not using ffmpeg AVFrames with libswscale. as you know, with low-level programming you have to allocate memory yourself. and that memory is of a particular length, and the starting address is divisible by a particular number ("alignment"). ffmpeg uses a lot of special facilities of the cpu and algorithms that require aligned reads and sometimes also aligned write. this means not only does the starting address have to be mod whatever (usually 16, i'm assuming because sse2 is 128-bit) but the total length of the allocation also has to be mod whatever or else it will overwrite, and then you are already dead (especially under windows, the last remaining intel 32-bit platform, where overallocation is not the norm). there are some checks made for alignment but none for length as far as i can tell, probably because the c language doesn't provide that functionality at runtime. now "luckily" if you always use AVFrames and use ffmpeg's functions to allocate their buffers and so on, you don't tend to run into this. or at least that's what i thought until yesterday. something else is going on maybe.
yeah. as to why it's 1920x1200. it's disturbing because 1920 is mod 16 == 0 and 1200 is mod 16 == 0. so the "stride" (line size, how much to read/write for each line of picture data) is the same as the width and the height shouldn't cause a problem either. but this is ffmpeg so it does. good look googling, asking for help. you have to figure it out yourself. so that's where i am right now. it's probably a stupid mistake i made elsewhere when i was rewriting video encoding, nothing to do with ffmpeg now. but then again maybe not. just have to go line by line. and it's a lot harder of course when i can't reproduce it.
cool about that avfs thing. i guess it does its job really well since ffmpeg can't tell it's not an avi file. could be a good substitute for supporting avisynth in yua for windows users who also want to use yua's gui for some reason.
i got the beginning of synchronization done last night. writing the audio to a .ts file now since it supports adts headers which the aac encoder generates and timestamps. still need to do video, writing to an mp4 file hopefully instead of raw h.264. plan right now is still simply to copy the timestamps from the input where possible and to reconstruct missing ones (every other "frame" in the case of interlaced input). still haven't figured out exactly how i'm going to do this yet though since for example the output audio frame size is different from the input size.
then, theoretically, the output will be in sync if the input is in sync. can also allow users to correct constant desync by simply adding or subtracting the amount converted into the streams' timebases.
well, i don't know why it's crashing now, but yesterday i pretty much isolated it initially to not using ffmpeg AVFrames with libswscale. as you know, with low-level programming you have to allocate memory yourself. and that memory is of a particular length, and the starting address is divisible by a particular number ("alignment"). ffmpeg uses a lot of special facilities of the cpu and algorithms that require aligned reads and sometimes also aligned write. this means not only does the starting address have to be mod whatever (usually 16, i'm assuming because sse2 is 128-bit) but the total length of the allocation also has to be mod whatever or else it will overwrite, and then you are already dead (especially under windows, the last remaining intel 32-bit platform, where overallocation is not the norm). there are some checks made for alignment but none for length as far as i can tell, probably because the c language doesn't provide that functionality at runtime. now "luckily" if you always use AVFrames and use ffmpeg's functions to allocate their buffers and so on, you don't tend to run into this. or at least that's what i thought until yesterday. something else is going on maybe.
yeah. as to why it's 1920x1200. it's disturbing because 1920 is mod 16 == 0 and 1200 is mod 16 == 0. so the "stride" (line size, how much to read/write for each line of picture data) is the same as the width and the height shouldn't cause a problem either. but this is ffmpeg so it does. good look googling, asking for help. you have to figure it out yourself. so that's where i am right now. it's probably a stupid mistake i made elsewhere when i was rewriting video encoding, nothing to do with ffmpeg now. but then again maybe not. just have to go line by line. and it's a lot harder of course when i can't reproduce it.
Edit history:
ballofsnow: 2013-02-27 10:43:49 am
ballofsnow: 2013-02-27 10:43:14 am
ballofsnow: 2013-02-27 10:40:08 am
ballofsnow: 2013-02-27 10:39:34 am
ballofsnow: 2013-02-27 10:37:23 am
Quote from nate:
cool about that avfs thing. i guess it does its job really well since ffmpeg can't tell it's not an avi file. could be a good substitute for supporting avisynth in yua for windows users who also want to use yua's gui for some reason.
During my testing with Yua and Pismo+AVFS, I noticed by memory usage going up and up. There's a memory leak somewhere in that combination, at least on my OS (Win8), and maybe only when it crashes. Yua by itself is fine though, which is what you care about..
Quote from nate:
yeah. as to why it's 1920x1200. it's disturbing because 1920 is mod 16 == 0 and 1200 is mod 16 == 0. so the "stride" (line size, how much to read/write for each line of picture data) is the same as the width and the height shouldn't cause a problem either. but this is ffmpeg so it does. good look googling, asking for help. you have to figure it out yourself. so that's where i am right now. it's probably a stupid mistake i made elsewhere when i was rewriting video encoding, nothing to do with ffmpeg now. but then again maybe not. just have to go line by line. and it's a lot harder of course when i can't reproduce it.
Loading the 1920x1200 or 1920x1080 encodes all the other qualities, just not XQ at native res. So I guess it's able to read the file just fine, just not able to write XQ.
So I mentioned the cropping thing before and am actually doing that now, trying to find the breaking point. Will update soon...
edit1-
AVFS 1920x1200, crop(176,176,0,0) -> 1744x1024 = crash
AVI -> 1744x1024 = crash
AVFS 1920x1200, crop(192,192,0,0) -> 1728x1008 = no crash
AVI -> 1728x1008 = crash!!
Argh. Could the codec be the issue?
Mediainfo of avfs:
Code:
General Complete name : D:\Yua\heaven.avs\heaven.avi Format : AVI Format/Info : Audio Video Interleave File size : 998 MiB Duration : 5s 0ms Overall bit rate : 1 674 Mbps Video ID : 0 Format : RGBA Codec ID : 0x00000000 Codec ID/Info : Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples Duration : 5s 0ms Bit rate : 1 672 Mbps Width : 1 728 pixels Height : 1 008 pixels Display aspect ratio : 1.714 Frame rate : 30.000 fps Bit depth : 8 bits Bits/(Pixel*Frame) : 32.000 Stream size : 997 MiB (100%) Audio ID : 1 Format : PCM Format settings, Endianness : Little Format settings, Sign : Signed Codec ID : 1 Duration : 5s 0ms Bit rate mode : Constant Bit rate : 1 536 Kbps Channel(s) : 2 channels Sampling rate : 48.0 KHz Bit depth : 16 bits Stream size : 938 KiB (0%) Alignment : Aligned on interleaves Interleave, duration : 37 ms (1.11 video frame) Interleave, preload duration : 533 ms
do you mean the output codec? before tonight sometime i'll make another build that logs that x264 encoder failure so you can tell if it's that that's causing it. seems incredible that it could be a bug in x264. it's more likely to be something that involves ffmpeg. but unfortunately ffmpeg is all over both decoding and encoding.
HELLO!
Minor suggestion: give an option to start an encode on a timer. I broke down and did the encode today, which I can afford to do only because it's my second last day on the job and I'm not able to start any new long-term projects, heh.
Anyway, encode done. Seemed to work alright actually. Great!
Anyway, encode done. Seemed to work alright actually. Great!
The attached file may be useful for sync tests. I grabbed the mp4 from here and made an avi version. It's 40 seconds, so just make a new self-appended file when you want to do longer tests.
