Doom10 Forum: Digital Video Discussion

Doesn't x264 compensate for VFR?

There're a few of redundant options you're using on x264 and mkvmerge that you don't really need to.

Here's a version without them for vanilla x264 and another for those who use JEEB's patched builds.

Disclaimer: Haven't tried these scripts (not on Windows atm) so I don't know if I made any mistakes for now, but you should get the gist of it.

By looking at it with your eyes, I'd say.

In Aegisub, the bar with the frame/time information turns blue.

Using ffms and Avisynth and the included ffms.avsi, FFInfo prints subtitles to the video showing frame number, frame type, cfr time and vfr time.
Using AvsP or VirtualDub, look for the begin/end frames and take note of their vfr time.

Lol, not spam this time.

Seems to be not for denoising at all, the difference between the shots is minimal, both visually and filesize-wise.

I'll try it on some grainy sources later today.

You'll probably need ffms with libswscale support compiled into x264 for colorspace conversion to work

From --tune film:
--deblock -1:-1 --psy-rd <unset>:0.15

This tells you that the developers of x264 consider these settings good for keeping details. If you need more, just raise these values. Use deblock -2:-2, use higher psy-trellis, etc.

There's also --tune grain, which settings should tell you that random spatial-only(?) details are also kept:
--aq-strength 0.5 --no-dct-decimate --deadzone-inter 6 --deadzone-intra 6 --deblock -2:-2 --ipratio 1.1 --pbratio 1.1 --psy-rd <unset>:0.25 --qcomp 0.8

As you can see, it's still using AQ. It's also using lower --deblock and higher psy-trellis than "film". The other settings I presume are meant more for grain-like details. If you use a patched build like JEEB's, you can also use --fgo (film grain optimization) to keep more grain.

Even if you don't use the --tunes, you can certainly learn more from them than random experimenting on settings which will probably do more harm than good.

Wavi comes with a silence.exe which should be what you want.

In Unix I googled this script:
NrChannels=2
 SampleRate=48000
 NrSeconds=1
 # above parameters can be changed as appropriate
 ffmpeg -ar $SampleRate -acodec pcm_s16le -f s16le -ac $NrChannels \
    -i <(dd if=/dev/zero bs=$(($SampleRate * $NrChannels * 2)) count=$NrSeconds) \
    silence.wav

If you want a certain filesize, use 2-pass.

what that result mean?

What it means is that you don't really need to set --threads or --thread-input, because x264 itself detects those automatically.

There is, MeGUI has a graphical tool for chapter making, iirc. No idea if it outputs XML or OGM.

This is not a question of egos. It's a question of neuron2 doing a shitty job as a moderator, turning the experience of being a member in Doom9 shit if he somehow finds some bone to grind with you or if you rub him the wrong way.

I don't know if this is exact, but what I feel about neuron2 is that if you somehow disagree with him, and are pretty resolute about your arguments, he isn't the slightest bit open-minded enough to accept that it is, in fact, your opinion and that he should respect it, and if it's an opinion about something of his own, he'll protect his property furiously. A 5-year old does that, not a grown man.

One is a spatial denoiser, the other is a spatio-temporal denoiser. You can't tell if one is better than the other because they apply to different cases.

AnimeIVTC uses TDecimate, iirc.

If x264 doesn't know the number of frames it can't tell the ETA. Create some kind of script that reads the first line from avs2yuv output and then inputs the number of frames to a "--frames" option in x264.

For example, first tell avs2yuv to only output 1 frame (-frames 1), then read the one line of text that gets output to stdout.
avs2yuv output:
script.avs: 720x480, 24000/1001 fps, 9001 frames
"(\d+) frames" in regex, I guess.
Then put that number of frames into --frames 9001 in x264.