[vlc-devel] Status of Win32 branch nightly

[Marian Ďurkovič]

On Wed, Sep 10, 2008 at 10:30:33AM +0200, Derk-Jan Hartman wrote:
> On 10 sep 2008, at 08:04, Marian Ďurkovič wrote:
> > - we still have crash on AR change
> 
> Did we have a crashlog of this ?
> We should really see if there is not a way to fix this.

Yes, there is - vout shouldn't be destroyed and recreated due to AR change.
What happens now is the following:

Picture pointers before AR change - taken via 
msg_Err( p_vout, "DatePicture %p",p_pic ) in vout_DatePicture():

[00000429] main video output error: DatePicture 0xaf61dcac
[00000429] main video output error: DatePicture 0xaf61d94c
[00000429] main video output error: DatePicture 0xaf61deec
[00000429] main video output error: DatePicture 0xaf61da6c

Picture pointers after AR change:

[00000441] main video output error: DatePicture 0xb4a382ec
[00000441] main video output error: DatePicture 0xb4a3852c
[00000441] main video output error: DatePicture 0xb4a3864c
[00000441] main video output error: DatePicture 0xb4a3840c


In other words, after vout respawn, everything is at different
places in memory.

Now with libmpeg2 0.4.1, the library outputs STATE_INVALID_END 
and STATE_SEQUENCE during AR change, which means VLC doesn't try
to fetch pictures from the old memory range.

With libmpeg2 0.5.1, we only get STATE_SEQUENCE_MODIFIED, which means
VLC wants to display pictures from the old memory range which are now
seriously corrupted - and crashes...

What I've sucessfully tested now is the attached patch to libmpeg2-0.5.1
which disables STATE_SEQUENCE_MODIFIED and restores the previous behaviour.
It keeps all other benefits of libmpeg2-0.5.1, so I think this could be the
way to go for now.

> Since telx only really can decode subs, I kinda like it. The problem  
> is however that is breaks terribly for broadcasters with multiple  
> (undeclared) languages and sometimes for pages with no background that  
> are not subs (Now and later, newstickers etc) which are declared as  
> subs, but are not.

Yep, that's the risk indeed, however it's still better than looking 
for subtitles at page 100 :-)


     With kind regards,

        M.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: head.dif
Type: video/dv
Size: 2099 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080910/a3c77f9e/attachment.dif>