diff options
author | Philip Langdale <philipl@overt.org> | 2015-08-08 14:59:09 -0700 |
---|---|---|
committer | Philip Langdale <philipl@overt.org> | 2015-08-28 19:11:55 -0700 |
commit | 91f1115a0e027074c90bac6e57c2d0f4fe9efe8c (patch) | |
tree | 176c26540f84987c9f7f8160b35dcfc4421da371 /libavcodec/apedec.c | |
parent | 628a73f8f3768513fa6152c98d54842cf2ae1aad (diff) | |
download | ffmpeg-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/apedec.c')
0 files changed, 0 insertions, 0 deletions