chros
1st November 2006, 22:46
I have made a little experiment about this topic.
Question: Is it makes sence to do a cfr (constant framerate) to vfr (variable framerate) conversion? (so we can spare bits)
Of course the source material must have some "still frames".
I have tried with 2 kind of sources. Both of them are trailers with lots of black screens.
- a DVD source (already encoded to anamorphic x264): The Haunting Teaser, 720x480 -> 640x384, length 1:23, 23.976 fps
- a 1080p source: Eragon trailer (http://images.apple.com/movies/fox/eragon/eragon-tlri_h1080p.mov), 1920x816 -> 720p 1280x544, length 1:42, 23.976 fps
I have used megui for the conversion, mp4 (or mkv) for the final container, x264: CE-Quicktime profile for the haunting, HQ-Slower and HQ Insane for Eragon, Constant quality mode: 18.
This conversion require at least 2 pass (1 for the analysis pass, and at least 1 for the encoding)
1. The scripts I have used for The Haunting:
# 1st analysis pass
DirectShowSource("the_haunting-tsr_x720a.mp4", audio=false, fps=23.976)
TFM(mode=0,pp=0,output="tfm.txt")
TDecimate(mode=4,output="stats.txt")
# 2st pass for the 1-pass crf encode
DirectShowSource("the_haunting-tsr_x720a.mp4", audio=false, fps=23.976)
TFM(mode=0,pp=0)
TDecimate(mode=5,hybrid=2,dupthresh=1.0,input="stats.txt",tfmin="tfm.txt",mkvout="timecodes.txt")
LanczosResize(640,384)
And the cfr script is the second without the TFM() and TDecimate() functions.
Results:
cfr-mp4: 1:23 , 6.498.029 B , 1993 frames
vfr.mp4: 1:15 , 6.349.432 B , 1805 frames (vfr, no timecode apllied)
vrf+tc.mp4: 1:23 , 6.354.125 B , 1805 frames (vfr, timecode apllied)
So it looks that at a very compressible clip the advantages are pretty small (comparing the crf and the vrf+tc):
- we can spare 188 frames (7.84 sec)
- and only 143.900 B (140 KB)
But if we suppose this amount of still frames (which would be very optimal, of course) on a 1 hour 30 min movie at 700 MB (after a little calculation):
- the crf bitrate: 958 kbps
- the vrf+tc bitrate: 1058 kbps
So we can spare 100 kbps !
And if we encode the vrf+tc with the crf bitrate we get only: 641 MB !
2. The scripts I have used for Eragon:
# 1st analysis pass
DirectShowSource("eragon-tlri_h1080p.mov", audio=false, fps=23.976)
TFM(mode=0,pp=0,output="tfm.txt")
TDecimate(mode=4,output="stats.txt")
# 2st pass for the 1-pass crf encode
DirectShowSource("eragon-tlri_h1080p.mov", audio=false, fps=23.976)
TFM(mode=0,pp=0)
TDecimate(mode=5,hybrid=2,dupthresh=1.0,input="stats.txt",tfmin="tfm.txt",mkvout="timecodes.txt")
LanczosResize(1280,544)
And the cfr script is the second without the TFM() and TDecimate() functions.
Results for the HQ-insane profile:
cfr-mp4: 1:42 , 45.973.705 B , 2449 frames
vfr.mp4: 1:38 , 45.098.408 B , 2352 frames (vfr, no timecode apllied)
vrf+tc.mp4: 1:23 , 45.099.651 B , 2352 frames (vfr, timecode apllied)
So it looks that at a very compressible clip the advantages are pretty small (comparing the crf and the vrf+tc):
- we can spare 97 frames (4.05 sec)
- and only 874.054 B (854 KB)
But if we suppose this amount of still frames (which would be very optimal, of course) on a 1 hour 30 min movie at DVD-5 size (4479 MB) (after a little calculation):
- the crf bitrate: 6955 kbps
- the vrf+tc bitrate: 7242 kbps
So we can spare 287 kbps !
And if we encode the vrf+tc with the crf bitrate we get only: 4301 MB !
So the bigger the resolution the more bits we can spare.
And for those who are new to this topic (like I was) and don't want to look at the docs, here are a small reference to the used functions and their parameters:
### TFM: TFM is a field matching filter that recovers the original progressive frames from a telecined stream.
### mode: Sets the matching mode or strategy to use.
### - 0 : 2-way match (p/c)
### - 1 : 2-way match + 3rd match on combed (p/c + n) (default)
### pp: Sets the post-processing mode for combed frames.
### - 0 : nothing (don't even look for combed frames)
### - 6 : motion-adaptive cubic interpolation deinterlacing (default)
### output: TFM will create the specified file and output all the matches and combed frame decisions used to it.
### input: If you have used the output option on a previous pass then reuse that info.
### TDecimate: TDecimate is a decimaton filter intended to remove duplicates from a video stream.
### mode: Sets the mode of operation.
### - 4 : Metrics output. No decimation is done, but metrics are calculated allowing for the output.
### (first pass for two pass mkv vfr using mode 5)
### - 5 : 2nd pass of the two pass process (mkv vfr, and requires hybrid=2 and cycleR=1, input and tfmIn file)
### hybrid: Controls how or if video sections (30p) should be dealt with.
### - 2 : vfr via mkv w/ timecodes file output (for modes 3 and 5)
### dupThresh: Sets the threshold for duplicate detection. (default: 1.1)
### tfmIn: Sets the name and path to an output file from TFM. (req. in mode=5)
Any correction, suggestion is welcomed!
And last but not least thanks for Wilbert for the Variable Framerate Video tutorial (http://www.avisynth.org/mediawiki/index.php?title=VariableFrameRateVideo)...
Question: Is it makes sence to do a cfr (constant framerate) to vfr (variable framerate) conversion? (so we can spare bits)
Of course the source material must have some "still frames".
I have tried with 2 kind of sources. Both of them are trailers with lots of black screens.
- a DVD source (already encoded to anamorphic x264): The Haunting Teaser, 720x480 -> 640x384, length 1:23, 23.976 fps
- a 1080p source: Eragon trailer (http://images.apple.com/movies/fox/eragon/eragon-tlri_h1080p.mov), 1920x816 -> 720p 1280x544, length 1:42, 23.976 fps
I have used megui for the conversion, mp4 (or mkv) for the final container, x264: CE-Quicktime profile for the haunting, HQ-Slower and HQ Insane for Eragon, Constant quality mode: 18.
This conversion require at least 2 pass (1 for the analysis pass, and at least 1 for the encoding)
1. The scripts I have used for The Haunting:
# 1st analysis pass
DirectShowSource("the_haunting-tsr_x720a.mp4", audio=false, fps=23.976)
TFM(mode=0,pp=0,output="tfm.txt")
TDecimate(mode=4,output="stats.txt")
# 2st pass for the 1-pass crf encode
DirectShowSource("the_haunting-tsr_x720a.mp4", audio=false, fps=23.976)
TFM(mode=0,pp=0)
TDecimate(mode=5,hybrid=2,dupthresh=1.0,input="stats.txt",tfmin="tfm.txt",mkvout="timecodes.txt")
LanczosResize(640,384)
And the cfr script is the second without the TFM() and TDecimate() functions.
Results:
cfr-mp4: 1:23 , 6.498.029 B , 1993 frames
vfr.mp4: 1:15 , 6.349.432 B , 1805 frames (vfr, no timecode apllied)
vrf+tc.mp4: 1:23 , 6.354.125 B , 1805 frames (vfr, timecode apllied)
So it looks that at a very compressible clip the advantages are pretty small (comparing the crf and the vrf+tc):
- we can spare 188 frames (7.84 sec)
- and only 143.900 B (140 KB)
But if we suppose this amount of still frames (which would be very optimal, of course) on a 1 hour 30 min movie at 700 MB (after a little calculation):
- the crf bitrate: 958 kbps
- the vrf+tc bitrate: 1058 kbps
So we can spare 100 kbps !
And if we encode the vrf+tc with the crf bitrate we get only: 641 MB !
2. The scripts I have used for Eragon:
# 1st analysis pass
DirectShowSource("eragon-tlri_h1080p.mov", audio=false, fps=23.976)
TFM(mode=0,pp=0,output="tfm.txt")
TDecimate(mode=4,output="stats.txt")
# 2st pass for the 1-pass crf encode
DirectShowSource("eragon-tlri_h1080p.mov", audio=false, fps=23.976)
TFM(mode=0,pp=0)
TDecimate(mode=5,hybrid=2,dupthresh=1.0,input="stats.txt",tfmin="tfm.txt",mkvout="timecodes.txt")
LanczosResize(1280,544)
And the cfr script is the second without the TFM() and TDecimate() functions.
Results for the HQ-insane profile:
cfr-mp4: 1:42 , 45.973.705 B , 2449 frames
vfr.mp4: 1:38 , 45.098.408 B , 2352 frames (vfr, no timecode apllied)
vrf+tc.mp4: 1:23 , 45.099.651 B , 2352 frames (vfr, timecode apllied)
So it looks that at a very compressible clip the advantages are pretty small (comparing the crf and the vrf+tc):
- we can spare 97 frames (4.05 sec)
- and only 874.054 B (854 KB)
But if we suppose this amount of still frames (which would be very optimal, of course) on a 1 hour 30 min movie at DVD-5 size (4479 MB) (after a little calculation):
- the crf bitrate: 6955 kbps
- the vrf+tc bitrate: 7242 kbps
So we can spare 287 kbps !
And if we encode the vrf+tc with the crf bitrate we get only: 4301 MB !
So the bigger the resolution the more bits we can spare.
And for those who are new to this topic (like I was) and don't want to look at the docs, here are a small reference to the used functions and their parameters:
### TFM: TFM is a field matching filter that recovers the original progressive frames from a telecined stream.
### mode: Sets the matching mode or strategy to use.
### - 0 : 2-way match (p/c)
### - 1 : 2-way match + 3rd match on combed (p/c + n) (default)
### pp: Sets the post-processing mode for combed frames.
### - 0 : nothing (don't even look for combed frames)
### - 6 : motion-adaptive cubic interpolation deinterlacing (default)
### output: TFM will create the specified file and output all the matches and combed frame decisions used to it.
### input: If you have used the output option on a previous pass then reuse that info.
### TDecimate: TDecimate is a decimaton filter intended to remove duplicates from a video stream.
### mode: Sets the mode of operation.
### - 4 : Metrics output. No decimation is done, but metrics are calculated allowing for the output.
### (first pass for two pass mkv vfr using mode 5)
### - 5 : 2nd pass of the two pass process (mkv vfr, and requires hybrid=2 and cycleR=1, input and tfmIn file)
### hybrid: Controls how or if video sections (30p) should be dealt with.
### - 2 : vfr via mkv w/ timecodes file output (for modes 3 and 5)
### dupThresh: Sets the threshold for duplicate detection. (default: 1.1)
### tfmIn: Sets the name and path to an output file from TFM. (req. in mode=5)
Any correction, suggestion is welcomed!
And last but not least thanks for Wilbert for the Variable Framerate Video tutorial (http://www.avisynth.org/mediawiki/index.php?title=VariableFrameRateVideo)...