VDA decoding broken

While the plugin is correctly being loaded by VLC and support for VDA is included in libavcodec.a, it is not getting used. Reason is unclear.

added Component::Decoders Severity::normal Type::bug Version::master git labels

changed milestone to %2.1.0 release

assigned to @fkuehne and unassigned @MigrationBot

commit 79a0dc92 Author: Felix Paul Kühne fkuehne@videolan.org Date: Thu Apr 25 19:05:38 2013 +0200

vda: correctly link module against libavcodec (close [#8440](https://code.videolan.org/videolan/vlc/-/issues/8440))

added Status::fixed label

closed

commit 5f9a4c4f Author: Felix Paul Kühne fkuehne@videolan.org Date: Thu Apr 25 19:05:07 2013 +0200

vda: add debug messages (refs [#8440](https://code.videolan.org/videolan/vlc/-/issues/8440))

The latest nightly build vlc-2.1.0-x86_64-20130426-0116 now crashes when attempting to use VDA.

The full crashlog with all the details can be found here: http://pastebin.com/V3MLwyBy

Also I'd like to attach this forum thread as related: http://forum.videolan.org/viewtopic.php?f=12&t=104624

There I mentioned a problem with the acceleration setting in the user interface.

Also setting acceleration method to "VDA" and then reverting it to "default" doesn't actually disable it, this should be fixed too.

VDA is also attempted to be activated when any setting on "Input/codecs" tab is changed. After that you can't turn it off, only complete settings reset helps. This is quite annoying and won't let me set deinterlacing options, for example.

removed Status::fixed label

reopened

I can reproduce the crash. Pretty weird. Must be some configuration issue on the build server.

The settings thing is a known problem with unknown (non-hacky) solution so far.

Crash was traced down to an outdated libav build used for the Nightly Builds.

commit 8fd204df Author: Felix Paul Kühne fkuehne@videolan.org Date: Fri Apr 26 12:09:02 2013 +0200

macosx: improve handling of module lists within the simple preferenences (close [#8440](https://code.videolan.org/videolan/vlc/-/issues/8440))

added Status::fixed label

closed

Indeed, it does not crash anymore with current libav head (1 or 2 days ago).

Still, there seem to be a major memleak, filling up the RAM with video data.

The behaviour I encounter is that the application seems to freeze according to this scenario:

• A couple of frames are late for display

main debug: picture might be displayed late (missing 0 ms)
main debug: picture might be displayed late (missing 10 ms)
main warning: picture is too late to be displayed (missing 49 ms)
main debug: picture might be displayed late (missing 8 ms)

• Video plays back fine for a couple of seconds or a bit longer (depends on the bitrate)
• The picture freezes, yet the sound keeps on going
• I stop the playback
• Right now I can properly quit the application, or...
• I can try to start the video again, then the application becomes irresponsive and has to be quit forcefully

This is indeed most likely caused by the memory leak that [comment:8 dfuhrmann] discovered.

removed Status::fixed label

reopened

closed