[vlc-devel] Re: latest teletext patch

xxcv xxcv07 at gmail.com
Tue Jan 16 17:05:04 CET 2007

These samples didn't crash with the patch back in 2007/01/09,

telx 20070109 no crash 
telx latest crash 
However as you can see, latest attempted to decode additional Text 
strings from the stream, which may not belong to the current frame.

Derk-Jan Hartman wrote:
> As a matter of fact this would be a bug in the blend filter. You see 
> the subpictures have no boundaries (theoretically). That's because in 
> VLC they are not by definition linked to another picture. The problem 
> here is actually in the blend routine that blends a subpicture into 
> the destination videopicture.
> I'll try and see if I can find the problem.
> DJ
> On 13-jan-2007, at 4:07, Vincent Penne wrote:
>> Thanks for testing.
>> About the crash you mention, it happens in the text renderer module I 
>> believe. In fact I wrote a comment in my module mentionning this 
>> problem already, apparently , the text rendering module doesn't clip 
>> vertically, so if you have a very long text, it's going to crash 
>> because it renders text outside of the picture. I suspect it doesn't 
>> clip horizontaly either by the way so it may also crash if you have a 
>> very long word that doesn't fit on one line.
>> Here, in the example you test, some teletext pages are wrongly 
>> flagged as subtitles, so it makes a long text to render (it's a 
>> complete page of text instead of just few lines of subtitles). It 
>> shouldn't crash if the text renderer was clipping correctly.
>> To trigger that bug with normal subtitle in my module, simply set     
>> p_spu->i_y = 1000; (instead of 10), it will try to display the 
>> subtitles very far up the screen and will crash if the screen is less 
>> than 1000 pixels height.
>> xxcv a écrit :
>>> Great Telx plugin Vincent!
>>> Yes now it works great with has-subtitles.ts
>>> however it now crash with,
>>> http://videoserver.nob.nl/temp/stream-demux-telx-1.dump
>>> http://videoserver.nob.nl/temp/stream-demux-telx-2.dump
>>> below from Dr. Mingw
>>> =============================================================
>>> vlc.exe caused an Access Violation at location 0afb1dd0 in module 
>>> libblend_plugin.dll Writing to location 091d9f58.
>>> Registers:
>>> eax=00000000 ebx=000000ff ecx=091d9e23 edx=0b0c6e50 esi=00000135 
>>> edi=0000002b
>>> eip=0afb1dd0 esp=08c1f638 ebp=08c1fcd0 iopl=0         nv up ei pl zr 
>>> na po nc
>>> cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             
>>> efl=00000246
>>> Call stack:
>>> 0AFB1DD0  libblend_plugin.dll:0AFB1DD0  vlc_entry__0_9_0b
>>> 1002DE81  libvlc.dll:1002DE81  spu_RenderSubpictures  
>>> vout_subpictures.c:811
>>> 1002C3D3  libvlc.dll:1002C3D3  vout_RenderPicture  vout_pictures.c:353
>>> 1002AFBD  libvlc.dll:1002AFBD  RunThread  video_output.c:1052
>>> 77C3A3B0  msvcrt.dll:77C3A3B0  _endthreadex
>>> 7C80B50B  kernel32.dll:7C80B50B  GetModuleFileNameA
>>> =============================================================
>>> And VLC-trunk msg & gdb debug log is in the attached zip file.
>> --This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
>> To unsubscribe, please read http://developers.videolan.org/lists.html
> --This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://developers.videolan.org/lists.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20070117/348a1f8e/attachment.html>

More information about the vlc-devel mailing list