aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/h264_cavlc.c
diff options
context:
space:
mode:
authorPhilip Langdale <philipl@overt.org>2015-08-08 14:59:09 -0700
committerPhilip Langdale <philipl@overt.org>2015-08-28 19:11:55 -0700
commit91f1115a0e027074c90bac6e57c2d0f4fe9efe8c (patch)
tree176c26540f84987c9f7f8160b35dcfc4421da371 /libavcodec/h264_cavlc.c
parent628a73f8f3768513fa6152c98d54842cf2ae1aad (diff)
downloadffmpeg-91f1115a0e027074c90bac6e57c2d0f4fe9efe8c.tar.gz
avcodec/vc1dec: Re-order init to avoid initting hwaccel too early
At least for vdpau, the hwaccel init code tries to check the video profile and ensure that there is a matching vdpau profile available. If it can't find a match, it will fail to initialise. In the case of wmv3/vc1, I observed initialisation to fail all the time. It turns out that this is due to the hwaccel being initialised very early in the codec init, before the profile has been extracted and set. Conceptually, it's a simple fix to reorder the init code, but it gets messy really fast because ff_get_format(), which is what implicitly trigger hwaccel init, is called multiple times through various shared init calls from h263, etc. It's incredibly hard to prove to my own satisfaction that it's safe to move the vc1 specific init code ahead of this generic code, but all the vc1 fate tests pass, and I've visually inspected a couple of samples and things seem correct. Signed-off-by: Philip Langdale <philipl@overt.org>
Diffstat (limited to 'libavcodec/h264_cavlc.c')
0 files changed, 0 insertions, 0 deletions