[vlc-devel] Status of Win32 branch nightly

[Marian Ďurkovič]

On Wed, Sep 10, 2008 at 12:40:49PM +0200, Laurent Aimar wrote:
> On Wed, Sep 10, 2008, Rémi Denis-Courmont wrote:
> > I am not an expert, but I would expect that this is impossible from the
> > video output drivers. Is it not the video codec responsibility to create a
> > new vout when the AR changes anyway?
>  Decoders are responsible for fmt_out modifications and as soon as they do
> (width/height/chroma/rgb masks/ar) they know that the vout will be
> recreated the next time they call pf_vout_buffer_new.

Well, the point here is: I don't think it's necessary to respawn the vout,
i.e. trash all its sturctures etc. When you made AR change from the Qt intf,
there's no such vout respawn - just the active video area changes.
We have mechanism to signal the vout that AR has changed:

p_vout->i_changes |= VOUT_ASPECT_CHANGE;

(we also have VOUT_CROP_CHANGE and VOUT_SET_SIZE).

Thus we don't have to trash everything just to signal new AR
or resize the window. It's the xvideo/directx/.... module responsibility
to react properly to these signals and change the window accordingly.
We only have to kill the vout if the output chain changes - e.g. if
some video filter is inserted or removed.

>  With that knowledge, they MUST release all pictures they are referencing
> (if any) (they probably need to copy them into new vout pictures to avoid
> breaking decodings on AR changes).

Yep. and that's why it worked with libmpeg2-0.4.1 With STATE_INVALID_END
it stopped referencing any old pictures, the decoder was completely
reset and started from zero. With 0.5.1, the previous pictures are still
referenced (and needed for decoding!) thus we might also crash here.


   With kind regards,

     M.