FFMPEG encoding for Adobe Encore CS6 video buffer underflows

[n0M3n]

I'm trying to encode with ffmpeg bluray compliant h264 files to use with adobe encore cs6. Encore reads the m2ts file correctly and says no transcoding needed, but when I try to build the bdmv folder I get "video buffer underflows. total bitrate is too high near time..."

"%execpath%" -hide_banner -c:v h264_cuvid -hwaccel_output_format cuda -i "%~1" -c:v h264_nvenc -preset medium -profile:v high -level:v 4.1 -b:v 25M -maxrate:v 38M -bufsize:v 30M -bf 3 -bt 1.0 -rc vbr -qmin 0 -qmax 69 -refs:v 4 -rc-lookahead 24 -flags +cgop -coder:v cabac -g 24 -keyint_min 1 -r 24000/1001 -bluray-compat 1 "%~p1%~n1.m2ts"

Using libx264 makes no difference. Instead same settings using x264.exe generates a perfectly working file (for encore).

Any help appreciated.

Solution:

I've found the solution...

[poisondeathray]

Use libx264 and try elementary file output, instead of transport stream. "%~p1%~n1.h264"

Unrelated to that error message, but you should to set the SAR for Encore compatibility as well or it can give you other error messages e.g -vf setsar=sar=1/1 for 1:1 , or --sar 1:1 in x264.exe if this was 1920x1080

[n0M3n]

hi, thank you for ur reply.
I already tried elementary stream, 100% not a muxing related issue.
as I said libx264 doesn't solve the issue. sar 1/1 is default value for decoded 1080p footage.
the only thing that I tried that worked with ffmpeg is setting 15mbit bitrate or lower.

as I said, it works flawlessly with x264.exe only.

[poisondeathray]

So use x264.exe , because it's known to work and is reliable.

Try removing -bt 1 ; if the --vbv-maxrate and --vbv-bufsize is passed correctly to libx264, then it shouldn't be required and might cause a buffer underrun

You can post a ffmpeg bug report in the meantime

[n0M3n]

bufsize @1080p must be 30M for bluray. whatever parameter I set I always get this error using ffmpeg, no matter the encoder. I wanted to try make it work just cause h264_nvenc is 2x faster than my amd 3700x and "we" are currently publishing more blurays recently.

I dunno what data I could attach to a bug report. Do you know any program to analyse buffer over time?

[poisondeathray]

For ffmpeg bug reports, you need the full -report , there are instructions on the bug tracker as to what to include in bug report
https://trac.ffmpeg.org/wiki/TracGuide

There are professional buffer analyzers with visualization, such as Elecard Buffer Analyzer , neuron2 used to offer vbvchecker (used to require a license not sure of current status), and a free one used to be vbv.pl

[n0M3n]

thank you for your help. gonna try

[n0M3n]

I've found the solution. I was using -g 24 while my stream is 23.976 and apparently encore doesn't like keyframes placed with a span greater than 1 second (for chapter placement and seeking probably).
And using -bluray-compat 1 won't change default key interval (250), and I think it should.

current command is:
"%execpath%" -hide_banner -y -c:v h264_cuvid -hwaccel_output_format cuda -i "%~1" -c:v h264_nvenc -preset medium -profile:v high -level:v 4.1 -rc cbr -b:v 28M -maxrate:v 28M -bufsize:v 30M -bf 3 -refs:v 3 -rc-lookahead 20 -no-scenecut 1 -coder:v cabac -g 23 -r 24000/1001 -bluray-compat 1 -an "%~p1%~n1.m2ts"

Gonna put a foreach ffprobe pass and some vars to automate it.
I've seen I can render 2 1080p streams simultaneously @12x speed each (on pcie4 nvme) with an rtx2070.

Soo.. GJ to me. Hope it helps

[poisondeathray]

-bluray-compat should not change or force the max keyframe interval, because there are 2 sec GOP variations of BD, other framerates, resolution and i/p . For example a L4.0 1920x1080p23.976 can use a 48 lenght GOP if the maxrate is 24000 with 1 slice , and this is "official" as per the BD specs. There is no way to know which variation the user is going to use

Your explanation doesn't make complete sense, since --keyint 24 works with x264.exe and encore (retail BD's with 23.976 authored using other software use a max keyframe interval of 24 as well.)

Other issues with ffmpeg libx264 or nvenc are chapter points - you would need to use qpfile to specify exact frames - it's not supported by ffmpeg libx264 implementation, only x264.exe , so there can sometimes be problems with the BD navigation

Also, the quality is quite low for nvenc h264 - so it's typically never used for BD

[n0M3n]

sure is not as good, but the difference is pretty neglectable if source is not film with really noticeable grain.
aaaaaaaaand I don't get paid enough, especially in a period with skyrocketing bills.