<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - VCE VAAPI segfault using ffmpeg" href="https://bugs.freedesktop.org/show_bug.cgi?id=99029#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - VCE VAAPI segfault using ffmpeg" href="https://bugs.freedesktop.org/show_bug.cgi?id=99029">bug 99029</a> from <a class="email" href="mailto:adf.lists@gmail.com" title="Andy Furniss <adf.lists@gmail.com>"> Andy Furniss</a> <pre>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 last 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 reason things don't seem quite right with the gop, or you shouldn't hit the division by zero. Your fix seems to change the intent of that code a little bit - I don't know if it makes any difference. That code got added to correct some corner case rate 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 ask 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 anything 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).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>