[vlc-devel] Direct3D9 + DXVA direct rendering
remi at remlab.net
Mon Apr 13 18:51:45 CEST 2015
Le lundi 13 avril 2015, 17:17:57 Steve Lhomme a écrit :
> While this is primarily working, when closing VLC I get all sorts of
> crashes with threads using dead pointers. For example the surfaces
> pushed in the display FIFO belong to the decoder. So if the decoder is
> closed, there are some picture_t in the FIFO pointing to invalid data.
Yes. There is currently no way to allocate picture from the decoder. And even
for hardware surfaces, I would expect the video output to keep responsibility
for determining the output target device and thus for allocating surface
> If they belonged to the vout then the decoder wouldn't work if the
> vout not available or reset for some reason.
The picture pool does not change if the decoder output format does not change.
Otherwise, there would be no ways for decoders to retain reference frames.
Also in principles, a picture remains valid as long as it is referenced by the
decoder. If the format changed after the picture was allocated, the picture
can no longer be rendered, but the picture structure is still valid.
> Maybe creating a vlc_object_t for the surface pool on which they would
> both hold a reference could help ?
I don't know what you think vlc_object_t does. vlc_object_t is a small set of
parameters for log messages (vlc_messages.h), and a dictionary of values with
notification callbacks (vlc_variables.h). That is pretty much all there is to
it. You don't need vlc_object_t for reference counting (e.g. input_item_t).
Reference counting a picture pool makes no sense at this point though. The
pool is destroyed when its video output or video conversion filter is
destroyed. Even if the pool were not destroyed, there would be no ways to
allocate pictures from it. So it might as well be destroyed.
The pictures within the pool are reference counted instead. Pictures will in
some corner cases outlive their pool.
More information about the vlc-devel