meguIV: The Official Akiba-Online DVD Encoder (v1.0.1.1)
- Thread starter Rollyco
- Start date
-
Akiba-Online is sponsored by FileJoker.
FileJoker is a required filehost for all new posts and content replies in the Direct Downloads subforums.
Failure to include FileJoker links for Direct Download posts will result in deletion of your posts or worse.
For more information see this thread.
@akiballion https://github.com/dubhater/vapoursynth-adjust
You could write that you edited the message.
Last edited:
Sorry, I fixed the first error and immediately got another one, didn't want to spam the thread.
Turned out I was missing some dependencies. Got the script working now, but still need to find out how to output video.
Anyway, thanks for your help.
Turned out I was missing some dependencies. Got the script working now, but still need to find out how to output video.
Anyway, thanks for your help.
Something like this:
Code:
vspipe --y4m script.vpy - | ffmpeg -hide_banner -i pipe: -c:v libx264 -preset veryslow -tune film -crf 18 -x264-params ref=9:bframes=9:no-fast-pskip=1 output.mkv
Last edited:
Ok, got everything working now. Anyway, this is my final script. The aim is to get the same quality output as meGUI. I tried to keep it simple, but I'm wondering if I'm missing anything essential.
import vapoursynth as vs
import havsfunc as haf
core = vs.get_core()
clip = core.ffms2.Source(source='source.mpg')
clip = haf.QTGMC(clip, Preset='Very Slow', Sharpness=1.0, TFF=True)
clip = core.resize.Spline36(clip, 640, 480)
clip = core.std.Crop(clip, 0, 0, 2, 0)
clip.set_output()
import havsfunc as haf
core = vs.get_core()
clip = core.ffms2.Source(source='source.mpg')
clip = haf.QTGMC(clip, Preset='Very Slow', Sharpness=1.0, TFF=True)
clip = core.resize.Spline36(clip, 640, 480)
clip = core.std.Crop(clip, 0, 0, 2, 0)
clip.set_output()
Last edited:
It's not needed.
Deprecated.
For mpeg2 and mpeg1 can't always use ffms2 or even lsmas, there may be problems with indexing, the video may lag, and sometimes incorrect frames will be displayed. First you need to use d2v, if you get the wrong FPS, lags, then you need ffms2 with "fpsnum=30000, fpsden=1001".
Crop is done before resizing.
I hate to ask this again, but Im stumped over the SAR and DAR stuff. I have since moved away from the win10 environment using MeguiIVit and my custom Megui setup. My goal is to get this setup in Linux, 100% manual and command line, as free and open source as possible, but got stuck needing something that was Windows only (cant recall what it was atm). Im creating this 100% manual/scripted setup in a win10 vm first, then once I have it working and understand everything, I'm going to try getting it setup in Linux again. I've got all the tools I need, but I'm having trouble with SAR and DAR again.
If I understood SamKook's explanation before, the best way to do SAR and DAR is to set SAR within x264 encoding settings and to set DAR in the container. Im pretty sure I got it working in MeguIVit, with gui settings I dont recall that were unintuitive, but I no longer have that setup to look back on and Im going command line now. The source is 720x480 with 16:9 aspect ratio and output container will be mkv. As far as I understand, that means I should set the x264 --sar parameter to 853/480 and when muxing video and audio together with mkvtoolnix, set the video stream DAR to 1:1. However, my result is a square picture rather than widescreen, as if it's displaying video using 1:1 DAR rather than the SAR setting.
If I do it the easier, but not ideal way (by not setting --sar in x264 and setting DAR in mkvtoolinx to 16:9), the result is widescreen and looks correct.
Can anyone explain what Im missing and doing wrong?
If I understood SamKook's explanation before, the best way to do SAR and DAR is to set SAR within x264 encoding settings and to set DAR in the container. Im pretty sure I got it working in MeguIVit, with gui settings I dont recall that were unintuitive, but I no longer have that setup to look back on and Im going command line now. The source is 720x480 with 16:9 aspect ratio and output container will be mkv. As far as I understand, that means I should set the x264 --sar parameter to 853/480 and when muxing video and audio together with mkvtoolnix, set the video stream DAR to 1:1. However, my result is a square picture rather than widescreen, as if it's displaying video using 1:1 DAR rather than the SAR setting.
If I do it the easier, but not ideal way (by not setting --sar in x264 and setting DAR in mkvtoolinx to 16:9), the result is widescreen and looks correct.
Can anyone explain what Im missing and doing wrong?
What you're doing wrong is also setting the DAR in the container. All you need to do is set up the SAR in x264 and you'll get a normal widescreen video.
What's happening here is the video is first set to 16:9 and then resized to square(1:1) by the container.
If you do set both, you want them to be the same or the one in the container correcting slightly the one from the video source if you can't set that one up as precisely as you want but that's not an issue with x264.
What's happening here is the video is first set to 16:9 and then resized to square(1:1) by the container.
If you do set both, you want them to be the same or the one in the container correcting slightly the one from the video source if you can't set that one up as precisely as you want but that's not an issue with x264.
Oh ok, so you only set one or the other. I thought what you were saying in the posts about this was that the ideal way was to set sar in x264 and set dar in container literally to 1:1. If I set sar and do not touch dar, my output.mkv has a 2.665(1279/480) dar for some reason and the picture is displayed extra wide. If I open this mkv in mkvtoolnix and change dar to 853/480, it displays properly. But Im still kind of confused because you said all you need to do is set sar in x264. But Im having to set both. Is it more proper to say the sar and dar should match?
If it would help to figure out where that 2.665 extra wide dar is coming from (this may be causing part of my confusion), the source is mkv with mpg2 video with a dar of 16/9. My x264 commandline is simply "--sar 853/480 --output "output.mkv" "MyScript.avs"". My script is basic:
Where is my output.mkv getting 2.665(1279/480) extra wide aspect ratio from? From what I understand now, something is setting the output.mkv's dar to that crazy number. Must be x264, but why?
If it would help to figure out where that 2.665 extra wide dar is coming from (this may be causing part of my confusion), the source is mkv with mpg2 video with a dar of 16/9. My x264 commandline is simply "--sar 853/480 --output "output.mkv" "MyScript.avs"". My script is basic:
Where is my output.mkv getting 2.665(1279/480) extra wide aspect ratio from? From what I understand now, something is setting the output.mkv's dar to that crazy number. Must be x264, but why?
SAR and DAR are pretty much the same thing, only difference is if you set it with x264, the few players that ignore the container DAR will still display it properly. If you set both, it will be resized twice by most players.
The most likely cause of your issue is that you're writing the sar value wrong. If you take a look at the full x264 help, this is the line about sar
So you need to use a ":" instead of the "/"
The most likely cause of your issue is that you're writing the sar value wrong. If you take a look at the full x264 help, this is the line about sar
Code:
--sar width:height Specify Sample Aspect RatioSo you need to use a ":" instead of the "/"
I tried both and got the same result, so x264 must accept either format. After you said sar and dar are pretty much the same thing and thinking over how my test encodes are coming out, I concluded it 100% has to be x264 creating the mkv with that dar and by opening the output with mkvtoolnix and setting dar manually I was just manually after the fact overriding what x264 did. So it had to be the sar value of the x264 command. Most info I came across online said to use width / height for sar, so I didnt think much about it at first. But I just kept reading and saw someone being told to use 32:27. I tried that and it worked. The output.mkv had 16/9 dar set by only setting that x264 sar value to 32:27. So that's the ideal aspect ratio setup done correctly, right?
However I do not understand why that's the correct value, because most sources say to use width over height (or specifically state 853/480) and I recall using 32:27 in the past when I used the mp4 container. And that was the PAR value for the mp4 container and I read that mkv and mp4 use different values. You mentioned this stuff too. This is so confusing. Storing pixels in a non-square shape on DVD was a dumb ass idea. Not only does it cause all these conversion complexities (it had to be known that displays have square pixels even back then), but I would also consider stretching each pixel a built-in quality loss inherent in the format.
However I do not understand why that's the correct value, because most sources say to use width over height (or specifically state 853/480) and I recall using 32:27 in the past when I used the mp4 container. And that was the PAR value for the mp4 container and I read that mkv and mp4 use different values. You mentioned this stuff too. This is so confusing. Storing pixels in a non-square shape on DVD was a dumb ass idea. Not only does it cause all these conversion complexities (it had to be known that displays have square pixels even back then), but I would also consider stretching each pixel a built-in quality loss inherent in the format.
Ok, just did a bunch of tests because I was getting the same result as you but my old encodes are actually correct and it's my bad, I looked too fast at my things and remembered it wrong.
SAR is the same as PAR, not DAR. The x264 help was confusing on that one, probably talking about the width and height of the pixel I would assume, not the video.
32:27 is the same as the desired new width/the old width. So if you divide 853.3333333333333333333333 by 720, you'll get the same result as if you divide 32 by 27. People use 32:27 because 853(480 x 16 / 9) is not the exact number.
In my scripts, I use NewWidth:OldWidth instead of 32:27 because I often crop the video to remove black bars which can change the aspect ratio a bit and using 853:720 will round up to the same thing as 32:27 so there's no ill effect, at least at DVD resolution.
And yeah, it always get confusing when talking about aspect ratio. Part of why I made scripts to calculate all that stuff because I keep forgetting about it, lol. I kept second guessing myself when I wrote the calculations for the cropped videos as well as one or two times after I was done.
I'm assuming they had a reason for setting a fixed resolution for DVDs but if I ever knew it, I forgot.
SAR is the same as PAR, not DAR. The x264 help was confusing on that one, probably talking about the width and height of the pixel I would assume, not the video.
32:27 is the same as the desired new width/the old width. So if you divide 853.3333333333333333333333 by 720, you'll get the same result as if you divide 32 by 27. People use 32:27 because 853(480 x 16 / 9) is not the exact number.
In my scripts, I use NewWidth:OldWidth instead of 32:27 because I often crop the video to remove black bars which can change the aspect ratio a bit and using 853:720 will round up to the same thing as 32:27 so there's no ill effect, at least at DVD resolution.
And yeah, it always get confusing when talking about aspect ratio. Part of why I made scripts to calculate all that stuff because I keep forgetting about it, lol. I kept second guessing myself when I wrote the calculations for the cropped videos as well as one or two times after I was done.
I'm assuming they had a reason for setting a fixed resolution for DVDs but if I ever knew it, I forgot.
I'm curious, how do you guys ensure proper A/V sync? Ideally, I'd just be muxing two streams from the same source together, but it's showing to be more difficult than I thought.
This is assuming the original AC3 file from the DVD has a delay of 0ms. When converting to AAC, it seems all AAC encoders have a slight delay by design. Some programs are supposed to handle it automatically, but I can't seem to get it just right.
For MKVToolnix, it cuts off the AAC encoder delay (-44ms) but also adds a positive delay of 20ms that wasn't in the original.
Muxing with FFmpeg gives a negative delay of -44ms, but MKVs with negative delay flags can be problematic and some programs (eg. Aegisub) won't open them at all.
Delaycut offers to remove encoder delays, but it can't handle AAC/M4A streams.
I'm also curious how MeguIV handled it, since it was never a problem there at all and the files in Mediainfo always showed no delay.
This is assuming the original AC3 file from the DVD has a delay of 0ms. When converting to AAC, it seems all AAC encoders have a slight delay by design. Some programs are supposed to handle it automatically, but I can't seem to get it just right.
For MKVToolnix, it cuts off the AAC encoder delay (-44ms) but also adds a positive delay of 20ms that wasn't in the original.
Muxing with FFmpeg gives a negative delay of -44ms, but MKVs with negative delay flags can be problematic and some programs (eg. Aegisub) won't open them at all.
Delaycut offers to remove encoder delays, but it can't handle AAC/M4A streams.
I'm also curious how MeguIV handled it, since it was never a problem there at all and the files in Mediainfo always showed no delay.
Only manually check everything and do the necessary manipulations. Problems can be not only with synchronization.
If you use a proper video decoder that's frame accurate when encoding the video part, there's usually no issues with audio delay as long as you fix the delay manually if it's not 0ms for the AC3.
If you use some kind of directshow source, which is not frame accurate but many software use anyway because it will read anything, there's a high chance that you're gonna have issues with audio delays which can even get worse as the video progress which becomes a giant pain to fix cause you have to cut and fix the audio in many parts.
To avoid the negative delay issues you have and for better compatibility with bad video players, it's better to fix the audio delay when encoding rather than when muxing it but your encoding software has to support it.
If you use some kind of directshow source, which is not frame accurate but many software use anyway because it will read anything, there's a high chance that you're gonna have issues with audio delays which can even get worse as the video progress which becomes a giant pain to fix cause you have to cut and fix the audio in many parts.
To avoid the negative delay issues you have and for better compatibility with bad video players, it's better to fix the audio delay when encoding rather than when muxing it but your encoding software has to support it.
That's the thing, the delay isn't from the AC3 source, but it's added when converting the audio track to AAC (the encoder delay is something like 43ms for Fraunhofer AAC and 44ms for QAAC). FFmpeg compensates this by making the audio start before the video (negative delay), but that leads to the compatibility issues mentioned. The best would be not to have delay flags at all in this case to prevent any player issues, but I'm not sure how to do that while maintaining source accurate sync.
I'm using FFmpeg in this case for both encoding & muxing, so it should be frame accurate in any case.
I'm using FFmpeg in this case for both encoding & muxing, so it should be frame accurate in any case.
Yeah, ffmpeg should be frame accurate so I'm not sure what the issue is here, I think I've only ever used it for lossless encoding and never to mux something I've encoded with it so never ran into that issue.
You'd probably have better luck asking on an encoding forum like doom9.
My only other suggestion would to try a different version, maybe it's a bug or some new/old unwanted behavior.
And my only other other suggestion(thought of something else after I typed the last sentence
) would be to try on a few different sources to see if the same thing happens or try a different method to process your source if any. A corrupted source will cause audio delay too so that might be a reason. If it forces an audio delay like that, then there's most likely a reason why it's forced to, otherwise it should stay synced.
You'd probably have better luck asking on an encoding forum like doom9.
My only other suggestion would to try a different version, maybe it's a bug or some new/old unwanted behavior.
And my only other other suggestion(thought of something else after I typed the last sentence
) would be to try on a few different sources to see if the same thing happens or try a different method to process your source if any. A corrupted source will cause audio delay too so that might be a reason. If it forces an audio delay like that, then there's most likely a reason why it's forced to, otherwise it should stay synced.
Did a couple of tests, demuxing the audio from the M4A container and then muxing the raw AAC stream with the video seems to result in perfect sync without delay, but I'm still not sure why it happens in the first place and if this is the right way to do it.
Edit: The 20ms delay happens with all sources when muxing MP4 & M4A streams together & seems to stem from the way MKVToolNix handles encoder delays.
Edit: The 20ms delay happens with all sources when muxing MP4 & M4A streams together & seems to stem from the way MKVToolNix handles encoder delays.
Found a fix, it's pretty stupid but w/e.
So what works is
1.) Muxing with FFmpeg first -> this creates a file with negative audio delay, but source-accurate sync.
2.) Throwing the MKV into MKVToolNix, removing the FFmpeg metadata and muxing again.
The negative delay is gone, MediaInfo now reports 0ms. There also won't be any dropped frames in the beginning or programs refusing to open the file.
Also, muxing the M4a or raw AAC stream both introduce a slight audio shift compared to the source. 20ms might seem low, but consider that lip sync already goes bad at 22ms, and delays as low as 10ms can be perceivable to some people!
It's probably OCD territory at this point and, depending on the source, might not matter at all. It's not perceivable with anime or any stuff without lots of dialogue really, but just throwing this out there anyway.
Worth reading up on. While it was specifically written for QAAC, it applies to other AAC encoders as well:
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
So what works is
1.) Muxing with FFmpeg first -> this creates a file with negative audio delay, but source-accurate sync.
2.) Throwing the MKV into MKVToolNix, removing the FFmpeg metadata and muxing again.
The negative delay is gone, MediaInfo now reports 0ms. There also won't be any dropped frames in the beginning or programs refusing to open the file.
Also, muxing the M4a or raw AAC stream both introduce a slight audio shift compared to the source. 20ms might seem low, but consider that lip sync already goes bad at 22ms, and delays as low as 10ms can be perceivable to some people!
It's probably OCD territory at this point and, depending on the source, might not matter at all. It's not perceivable with anime or any stuff without lots of dialogue really, but just throwing this out there anyway.
Worth reading up on. While it was specifically written for QAAC, it applies to other AAC encoders as well:
https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html
Is there still a working version of the encoder available? I tried many different encoders but I have lots of problems with De-interlacing, no matter what i do it looks bad. is there a real one click solution ?
?