LoRd_MuldeR & LigH: Wow, you guys are on fire today!
LoRd_MuldeR: I'll log the fflush() issue. Side: I already have an issue logged where some of the -help is written to stderr instead of stdout.
LigH: I have a suggestion for your app!
You could support a wider range of inputs by doing this:
- If the input is AVI or AVS, write an intermediary AVS script that loads the input file via AVISource
- If the input is another type, write an intermediary AVS script that loads the input via DirectShowSource
- You could use Don's command-line guide for DGMPGDec to handle MPEG formats if it's available on the system.
After writing these intermediary files you can open them with the windows AVIFile APIs and check the rate/scale of the video stream to make sure it's valid and if not automatically apply something like ConvertFPS with the nearest allowed rate/scale. You could also check the width and height and apply AddBorders and/or a resize if necessary, then finally pass this AVS file to the encoder. If you want to get really fancy you could add ConvertToYV12 to the AVS script and get the picture in a known format through the AVIFile interfaces, then apply a routine to determine a crop window to remove borders, checking various frames throughout the file. I think you can also get PCM samples easily this way so you could write a WAV file then pass it through an audio encoder and hook up mkvmerge to bring everything together.
buzzqw: I sent you an e-mail, I'd love to see AutoMKV support this!
LoRd_MuldeR & Dark Shikari: Thanks for the comparison vid, and for keeping the conversation on track! I haven't had time to thoroughly investigate it yet but x264's new psy does seem impressive
I did notice that the clip is rather low motion and x264's settings were quite extreme - e.g. 16 refs, 15 consecutive b's, ~20s IDR interval, so I'm wondering if this is somewhat special case. Anyway, I'll look into it further
I think we also have that clip so I can recreate it with more comparable settings.