How to encode screencasts in x264 (with vfr?)

[Evaldas]

Hi,

I'm very new to this H.264 thing. I have a bunch of screencast tutorial videos (captured desktop screen; slides; command-line editing) which I would like to encode in H.264/MP4. The videos are encoded with TSCC (TechSmith Screen Capture) codec, 15 fps avi. Right now in AviSynth script I have 2 lines:
DirectShowSource("file.avi", audio=false)
ConvertToYV12()

As for x264, I use the lossless option:
x264.exe --qp 0 -o output.mp4 input.avs

As I said, I'm new to this, so I guess "lossless" is not the most optimal mode :) (as I don't know which other options would be better). I chose "lossless" because it was at the top of the x264 help screen, and I wanted high/highest quality.

Today I found out that the videos can also be encoded in variable frame rate (vfr) mode. So I am thinking that vfr could be very beneficial to screen captured videos. I tried searching doom9 forum, but found nothing substantial. So, can x264 encode in vfr mode? What command-line options should be added? Or the AviSynth script should be changed?

Thank you

[Dark Shikari]

vfr is a property of the source, not an encoding mode.

[roozhou]

Why did you write an avs that actually does nothing but messes up with timestamps?
When you are dealing with vfr source, forget avisynth script.
Encode your avi directlyx264.exe --qp 0 -o output.mp4 input.aviand you get a perfect vfr output.
If your x264.exe is unable to decode the avi using built-in decoders, try this (http://forum.doom9.org/showthread.php?t=141441).

[sneaker_ger]

How do you get vfr output from a cfr avi file using x264? (Without inputting a timecode file)
You don't?!

[roozhou]

How do you get vfr output from a cfr avi file using x264? (Without inputting a timecode file)
You don't?!
Why do you assume AVI to be cfr? AVIs can be vfr by inserting 0-byte chunks, and this is very common in screen capture when the capture application cannot get enough CPU cycles.

[Dark Shikari]

Why do you assume AVI to be cfr? AVIs can be vfr by inserting 0-byte chunks, and this is very common in screen capture when the capture application cannot get enough CPU cycles.Coding skip frames in such a case costs practically zero bits.

[roozhou]

Coding skip frames in such a case costs practically zero bits.
It wastes both time and bits to encode such frames but you get nothing from them. I think developers are always happy with 1% compression or performance improvement, so why should we ignore this?

And another question about vfr: since the official x264 build is still using a linear scenecut threshold based on frame count, adding skipped frames will affect frame type decisions. So will it be good or bad to change it to pts-based?

[Evaldas]

I managed to run the source video through DeDup AviSynth filter (it dropped about 90% of frames) and produced time code file, which is, I think is mkv compatible (# timecode format v2).

How do I merge timecodes to the mp4 file? Should it be done at encoder (x264) level or with muxer, e.g. mp4box?

[roozhou]

I managed to run the source video through DeDup AviSynth filter (it dropped about 90% of frames) and produced time code file, which is, I think is mkv compatible (# timecode format v2).

How do I merge timecodes to the mp4 file? Should it be done at encoder (x264) level or with muxer, e.g. mp4box?
Always do it at encoder level. Assuming a cfr video during encoding messes up with ratecontrol.

[sneaker_ger]

Why do you assume AVI to be cfr?

Because the thread starter asked whether it would be possible to "also" encode in vfr mode, which implies he's using cfr right now.

Different question:
Is x264cli able to create vfr mkv or mp4 out of avi files with 0-byte chunks?

[Chikuzen]

Is x264cli able to create vfr mkv or mp4 out of avi files with 0-byte chunks?

x264cli can do it with --demuxer ffms/lavf.

[Evaldas]

Is there a way to keep the rgb or at least yuv 422 colorspace in x264 output file? If i'm feeding x264 with rgb colorspace or add a switch "--vf resize:csp=rgb", the resulting file always has yuv 420.

I'm using x264 windows binary r1913.

[nm]

Is there a way to keep the rgb or at least yuv 422 colorspace in x264 output file?

Nope. Currently x264 only supports YUV 4:2:0 encoding.

[Lenchik]

How i've done Hi444PP 10bit VFR mkv
Source: YV24 or RGB screencapture done with virtualdub.

Source framerate was not completely constant, thus to sync with audio:
audiodubex(FFVideoSource(source=source, fpsnum=30000, fpsden=1000, threads=1), FFAudioSource(source=source))

To make some still video parts made of one frame multiplied i used ReMapFrames (http://forum.doom9.org/showthread.php?p=1644971#post1644971).
RemapFrames(filename="capture_RemapFrames.txt")

As i wanted VFR and Hi444PP in the resulting mkv Decomb521VFR and TIVTC (TFM + TDecimate) vfr making instructions couldn't help me. First of all because they don't support YV24. And as a second note i didn't find the way to erase really big parts of duplicated frames.
DeDup using idea was more intersting but probably had same problem with YV24 (didn't test actually).
I have found ExactDeDup (http://tasvideos.org/forum/viewtopic.php?p=358390#358390), with YV24 support and DeDup ability to remove big blocks of duplicated frames.

I used it in two passes. First one to linearly "walk" through whole source:
#ExactDeDup 1pass
ExactDedup(firstpass = true, maxdupcount=80000, keeplastframe=false, dupinfo="dup.txt", times="ExactDedup_times.txt")
maxdupcount - maximum size of block with duplicated frames that wil be removed except first frame in block.
times - timecodes file for muxing with mkvmerge from mkvtoolnix to get VFR mkv file.
This first pass can be done either by "Run video analysis pass" of VirtualDub, or from commandline with avs2pipemod (http://csbarn.blogspot.ru/2012/09/avs2pipemod-17.html):
avs2pipemod.exe -benchmark capture.avs

In second pass i commented out first pass line of avisynth script and wrote second pass code:
#ExactDeDup 1pass
#ExactDedup(firstpass = true, maxdupcount=80000, keeplastframe=false, dupinfo="dup.txt", times="ExactDedup_times.txt")

#ExactDeDup 2pass
ExactDedup(firstpass=false, dupinfo="dup.txt")
As a result i've got avs source without duplicates. It had 16 thousand frames (compare with over 300 thousands of source frames).

While encoding in x264 i have found that using --tcfile-in option is breaking many resulting frames (tested on 2145 JEEB build, and 2358 and 2377 komisar builds). Solution is to mux timecodes in mkvmerge only.
This is how i sent video to x264:
"%avs2pipemod_path%" -rawvideo "%source1%" | "%x264-10bit_64_path%" --demuxer raw --input-depth 8
--input-res 1280x960 --input-csp i444 --profile high444 --level 4.1 --preset veryslow --scenecut 80 --sar 1:1
--colormatrix bt709 --transfer bt709 --colorprim bt709 --crf 19 --min-keyint 1 --vbv-maxrate 50000
--vbv-bufsize 62500 --output-csp "i444" --frames 16080 --log-file
"%source_path%%source_filename1%-log_type2.txt" --output "%coded_video1%" - 2>
"%source_path%%source_filename1%-log.txt"

Next step was encoding sound to HE-AAC and muxing it with video and timecodes inside mkv file. It was an easy part.

Bottom line
Pros. One of the good features of that VFR is its small encoding time. I don't know yet about size compared to CFR encode (it is encoding right now.
Now to the cons. Bad support by players (or splitters+decoders - no matter from user side). MPC-HC 1.6.8 (without internal LAVFilters) defaults have some sound pauses while seeking and sometimes desync after seeking. LAVSplitter (internal for newest MPC-HC or external) read wrong size and even not start playing. AVSplitter (with potplayer) read wrong size but is OK with sound while seeking.