[vlc-devel] [Fwd: Re: Re: Issue with PTS/DTS]

[Christophe Démaret]

(sorry, looks like I did sth wrong with thunderbird)

-------- Message original --------
Sujet: 	Re: [vlc-devel] Re: Issue with PTS/DTS
Date: 	Thu, 13 Jul 2006 06:45:05 +0200
De: 	Christophe Démaret <vlc at cdemaret.com>
Pour: 	Derk-Jan Hartman <hartman at videolan.org>
Références: 	<44B41C14.2000001 at cdemaret.com> 
<528CEDBC-E3AD-440E-8206-9836BA268D42 at videolan.org>


Derk-Jan Hartman a écrit :
> Instead of
> 
>     jas_stream_close( p_sys->p_streamJas );
>     /* The block should be released but since we are called again and 
> again on the same packet... */
> //  block_Release( p_sys->p_block );
> 
> 
> try
> 
> block_Release( p_sys->p_block );
> p_sys->p_block = NULL;
> 
> if you are not removing blocks from the queue, it's no wonder they never 
> disappear.

Hmmm thank you DJ, but I had already tried this in the past (hence the 
comment) :-/

I've just added

> msg_Dbg( p_dec, "Before block_Release(), p_sys->p_block = %p.", p_sys->p_block);
> block_Release( p_sys->p_block );
> msg_Dbg( p_dec, "After block_Release().");
> p_sys->p_block = NULL;
> msg_Dbg( p_dec, "Memory has been cleaned.");
> return ret;


to the DecodeBlock() fucntion and the result is:


> main debug: looking for decoder module: 26 candidates
> mj2k debug: Opening MJPEG2000 Decoder based on JasPer
> mj2k debug: Everything is fine, correctly started
> main debug: using decoder module "mj2k"
> main debug: thread 3916 (decoder) created at priority 0 (input/decoder.c:159)
> mj2k debug: New block: p_block: @ 1661758, buffer @ 16617d0, size: 16018, dts: 1058517004, pts: 5
> mj2k debug: The jas_stream_t (@15f77e0) was created based on buffer @16617d0, size=16018.
> mj2k debug: The frame (@15f77e0) was decoded, returned 1606678.
> mj2k debug: Width = 320, Height = 240. Begin of the transfert to the VLC structure.
> main debug: no usable vout present, spawning one
> main debug: window size: 320x240
> main debug: looking for video output module: 5 candidates
> main debug: Registering subpicture channel, ID: 2
> main debug: Registering subpicture channel, ID: 3
> main debug: Registering subpicture channel, ID: 4
> main debug: Registering subpicture channel, ID: 5
> main debug: waiting for thread completion
> wingdi debug: create: 0008057A
> wingdi warning: Created WinGDI window
> wingdi debug: create: 000F0678
> wingdi debug: create: 0007059E
> wingdi debug: GDI depth is 32
> main debug: thread 3896 (GDI Event Thread) created at priority 0 (wingdi.c:296)
> main debug: using video output module "wingdi"
> main debug: waiting for thread completion
> main debug: got 1 direct buffer(s)
> main debug: picture in 320x240 (0,0,320x240), chroma I444, ar 4:3, sar 1:1
> main debug: picture user 320x240 (0,0,320x240), chroma I444, ar 4:3, sar 1:1
> main debug: picture out 320x240 (0,0,320x240), chroma RV32, ar 4:3, sar 1:1
> main debug: looking for chroma module: 9 candidates
> ffmpeg debug: no resampling
> ffmpeg debug: libavcodec initialized (interface 3344640 )
> main debug: using chroma module "ffmpeg"
> main debug: indirect render, mapping render pictures 0-7 to system pictures 1-8
> main debug: thread 3876 (video output) created at priority 1 (video_output/video_output.c:421)
> mj2k debug: New buffer successfully created (@471cbc0), copy from 1606678
> mj2k debug: Entering mj2k_CopyPicture
> mj2k debug: Comp. num. 0, w=320, h=240. Ready to copy.
> mj2k debug: Comp. num. 1, w=320, h=240. Ready to copy.
> mj2k debug: Comp. num. 2, w=320, h=240. Ready to copy.
> mj2k debug: Transfert successful. We're done here, image @471cbc0.
> mj2k debug: Before block_Release(), p_sys->p_block = 01661758.
> mj2k debug: After block_Release().
> mj2k debug: Memory has been cleaned.
> mj2k debug: New block: p_block: @ 1661758, buffer @ 16617d0, size: 16018, dts: 1058517004, pts: 5
> mj2k debug: The jas_stream_t (@15f77e0) was created based on buffer @16617d0, size=16018.
> mj2k debug: The frame (@15f77e0) was decoded, returned 4727f70.
> mj2k debug: Width = 320, Height = 240. Begin of the transfert to the VLC structure.
> mj2k debug: New buffer successfully created (@471d000), copy from 4727f70
> mj2k debug: Entering mj2k_CopyPicture
> mj2k debug: Comp. num. 0, w=320, h=240. Ready to copy.
> mj2k debug: Comp. num. 1, w=320, h=240. Ready to copy.
> mj2k debug: Comp. num. 2, w=320, h=240. Ready to copy.
> mj2k debug: Transfert successful. We're done here, image @471d000.
> mj2k debug: Before block_Release(), p_sys->p_block = 01661758.




... and a beautiful crash.
As you can see, even with the release_Block() (and the =NULL to p_block 
which shouldn't be necessary anyway: it is not present is rawvideo.c, 
cf. lines 297/298 of 0.8.5: "block_Release( p_block ); return p_pic;") 
VLC still calls the function twice with the same address (1661758) in 
p_block (that is in the *pp_block given as parameter) and logically it 
segfaults when trying to work with an already released block, which 
should never happen, should it ? I mst say the haevily multithreaded 
architecture of VLC is hard to understand for me, so maybe I should 
check somewhere elese in the code ? Some kind of "synchronization engine" ?

Thank you for yor help

Christophe


-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html