[vlc-devel] [Fwd: Re: Re: Issue with PTS/DTS]
Christophe Démaret
vlc at cdemaret.com
Mon Jul 17 07:12:50 CEST 2006
(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
More information about the vlc-devel
mailing list