cfr output means that each frame is displaced a constant time.
For example: 40ms for 25fps content.
For cfr content, a decoder simply reads the frame rate flag and then it knows how long to display each frame.
So by simply changing, the frame rate flag of a cfr stream you change the display time for each frame.
With vfr you got the video stream and for each frame in it, a time for how long it should be displayed (or until when it should be displayed, but that is basically the same).
For example: frame 0-9 10ms (~100fps), frame 10-19 40ms (~25fps),.....
So if you change the frame count or rate, you need to adjust the time codes accordingly.
(The above 20 frames have an average display time of 24.5ms which would be in average ~40,81fps.
If you now want to scale this to 50 fps, you would have to add frames in some parts and adjust the time codes for each part and maybe remove time codes and frames in other sections. And this gets more and more complicated if you think about what you can do to streams.)
Which is not way trivial!
When handling vfr content, you got:
a. the frames
b. the time codes
as long as you don't change the frame count, you can simply filter the frames and add the time codes back in.
If you want to have cfr output, you normally tell the decoder to output a specific frame rate and the decoder will then (use the time codes and simply add or remove frames to hit your desired frame rate).
If you apply stuff that changes the frame rate or frame count (like deinterlacing, frame rate interpolation) you either have to:
a. adjust the time codes to match the output (Hybrid can't do that, and I haven't ever seen someone properly doing this, so this is no option.)
b. or decode to cfr
Problem is, if your source filter changes cfr content to vfr content, you would need to have the time codes to add them back after the filtering or convert to cfr using those time codes. If you don't have them, then you will get async output.
So unless bestsource adds support for cfr output, one would have to analyse the index file to see whether it contains the time stamps (which I assume) and then add a way to handle them. :/
Also keep in mind, that basically all filters assume the input is cfr.
So unless Vapoursynth and all the (temporal) filters properly take vfr into account, you either stick with vfr (and don't do frame interpolation&co) or you decode to cfr.
Cu Selur
Ps.: Yes, stuff like interlaced or mixed vfr content is simply 'evil' and in my mind a production mistake for which someone should get impaled by a stick.
For example: 40ms for 25fps content.
For cfr content, a decoder simply reads the frame rate flag and then it knows how long to display each frame.
So by simply changing, the frame rate flag of a cfr stream you change the display time for each frame.
With vfr you got the video stream and for each frame in it, a time for how long it should be displayed (or until when it should be displayed, but that is basically the same).
For example: frame 0-9 10ms (~100fps), frame 10-19 40ms (~25fps),.....
So if you change the frame count or rate, you need to adjust the time codes accordingly.
(The above 20 frames have an average display time of 24.5ms which would be in average ~40,81fps.
If you now want to scale this to 50 fps, you would have to add frames in some parts and adjust the time codes for each part and maybe remove time codes and frames in other sections. And this gets more and more complicated if you think about what you can do to streams.)
Which is not way trivial!
When handling vfr content, you got:
a. the frames
b. the time codes
as long as you don't change the frame count, you can simply filter the frames and add the time codes back in.
If you want to have cfr output, you normally tell the decoder to output a specific frame rate and the decoder will then (use the time codes and simply add or remove frames to hit your desired frame rate).
If you apply stuff that changes the frame rate or frame count (like deinterlacing, frame rate interpolation) you either have to:
a. adjust the time codes to match the output (Hybrid can't do that, and I haven't ever seen someone properly doing this, so this is no option.)
b. or decode to cfr
Problem is, if your source filter changes cfr content to vfr content, you would need to have the time codes to add them back after the filtering or convert to cfr using those time codes. If you don't have them, then you will get async output.
So unless bestsource adds support for cfr output, one would have to analyse the index file to see whether it contains the time stamps (which I assume) and then add a way to handle them. :/
Also keep in mind, that basically all filters assume the input is cfr.
So unless Vapoursynth and all the (temporal) filters properly take vfr into account, you either stick with vfr (and don't do frame interpolation&co) or you decode to cfr.
Quote:also in Hybrid there are filters that are able to do that by add/removing frames.which all assume the source if cfr
Cu Selur
Ps.: Yes, stuff like interlaced or mixed vfr content is simply 'evil' and in my mind a production mistake for which someone should get impaled by a stick.