Comment=
# 3
on bug 99029<=
/a>
from Andy Furniss
Hmm, I haven't tested yet, but if you hit the division by zero=
, I guess there
is something special about thet file (or ffmpeg/something changed since I l=
ast
looked). Before reading your other bug the only way I thought would trigger
that one was to explicitly add -g 0 to the command line.
On speed - I would get rid of the yuv420p, maybe add -g 48 as for some reas=
on
things don't seem quite right with the gop, or you shouldn't hit the divisi=
on
by zero.
Your fix seems to change the intent of that code a little bit - I don't kno=
w if
it makes any difference. That code got added to correct some corner case ra=
te
control cbr issue - ffmpeg switched to using vbr by default so may not show=
it
anyway. I don't recall what rate (maybe it's cqp) you'll get if you don't a=
sk
for anything like your example. There may be a better place to check if gop=
is
0.
-profile:v 77 doesn't quite work properly IIRC (well it doesn't change anyt=
hing
encoding wise but the file will not show as main).
You may get more perf if you force your GPU to high.
I guess this is just a test, but for real world use, using your h/w to
transcode without b-frames is not really an optimum solution and it's up to=
the
firmware team whether b-frames ever work (They don't work on windows either
AFAICT).