[FFmpeg-devel] FFMPEG support for x265 vbv-end and vbv-end-fr-adj

[Tom Vaughan]

Michael - Sorry I missed your response on 5/15. I led the x265 project from 2013 to 2018, and I helped to define this feature, but I can't speak for the x265 development team today. I could put you directly in touch with the x265 developers at Multicoreware to work this out. I will also encourage them to respond to this thread directly on the FFMPEG-devel mailing list.

Speaking as an end-user, I don't think we require frame-accurate precision. The vbv-end-fr-adj value specifies the point at which the vbv-end logic is activated. vbv-end-fr-adj is a value between 0 and 1, but should always be less than 1. Multiply vbv-end-fr-adj by 100 to get the % of the transcoding job in time where the vbv-end feature needs to be triggered. A flag that is passed from FFMPEG to x265 at this point would work. I'm aware of the challenges of frame-rate accuracy when transcoding. I would say that a "best effort" from FFMPEG to trigger the signal at the right point is good enough. Non-decodable frames should count as if they were decodable, to not throw off the time calculation.

As an example, if someone is chunking the encoding of a video title into 300 second chunks, and they want the vbv-end enforcement to start 15 seconds before the end of the chunk encode, they would use vbv-end-fr-adj 0.95. When x265 gets to the last 5% of the encode (last 15 seconds), vbv-end logic would be activated. 1 or 2 frames inaccuracy won't matter.

Thanks,
Tom

On 5/15/24, 5:59 AM, "ffmpeg-devel on behalf of Michael Niedermayer" <ffmpeg-devel-bounces at ffmpeg.org <mailto:ffmpeg-devel-bounces at ffmpeg.org> on behalf of michael at niedermayer.cc <mailto:michael at niedermayer.cc>> wrote:


On Wed, May 01, 2024 at 09:10:51PM +0000, Tom Vaughan wrote:
> When I attempt to pass vbv-end and vbv-end-fr-adj parameters to x265, FFMPEG fails.
> 
> x265 [error]: vbv-end-fr-adj cannot be enabled when total number of frames is unknown
> 
> x265 needs to know how many frames it is encoding so that it knows when the vbv-end logic needs to kick in. In this case it would be after 96% of the source video is encoded. Despite specifying a duration of 30 seconds ( -t 30 ) on both input and output (using a 60 second source video), x265 does not know the total number of frames (but FFMPEG surely does).
> 
> ffmpeg -i test_uhdsdr_1min.mov -t 30 -an -sn -dn -c:v libx265 -b:v 12000k -maxrate 8M -bufsize 18M -x265-params vbv-init=0.9:vbv-end=0.9:vbv-end-fr-adj=.96:rc-lookahead=48:qg-size=32:scenecut=0:no-open-gop=1:frame-threads=0:repeat-headers=1:nr-inter=400:nr-intra=100:psy-rd=0:cbqpoffs=0:crqpoffs=3 -t 30 test_uhdsdr_96.mp4


you can specify total_frames along with vbv-end-fr


there is in general not a 1:1 correspondance between duration and the number of frames
the frame rate may vary, there may be skiped frames or damaged frames that
where lost and so on.


in case of some 2 pass mode it should be possible to get the exact number of frames
in the 2nd pass.
Otherwise my gut feelng is that a time based instead of a frame number based
threshold would have been easier to work with


if you are thinking that the total frame number should be set automatically
and not by hand. I agree, its just not easy to do that in all cases.
It could maybe be done in specific cases but in the general case
it would need 2 passes to be reliable.


thx


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB


Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.