[gst-devel] memory leaks with qtdemux

[Albert Costa]

Hi,
in fact I got similar problem. It came not from the format, but from the size of file.
If I use a file which is larger than 2Gb, then the component does not have same behavior as if smaller.
In normal case, qtdemux acts in pull mode, whereas it acts in push mode when file is >2Gb. Reason is that (in short terms), in gstfilesrc code the seekable flag is set to false because the fseek function used returns only signed 32bits length. In case the file is over 2Gb, fseek fails.
I have tried to replace all functions (fseek and other fstat...) by their 64bits equivalent, but still the qtdemux does not work properly.
And I don't know yet why it leaks memory in push mode.

Has anyone already got this kind of problem? Is there a way to handle nice and smooth files that are above the 2Gb limit? Is it expected to be handled in later releases of gstreamer?
Btw, I run under win32.
Regards,
Al.

 

>Hi,
>When I run gst-launch with this command line : gst-launch filesrc
>location=AAA.mov ! qtdemux ! fakesink
>On some file I have a big memory leaks (10Mo /s)
>file type : QuickTime (..mov)
>video codec : dvcp (apple dv-pal)
>audio codec : twos: 16 bit signed big-endian 48kHz
>size : 720x576
>But with another files There are not memory leaks
>NO memory leaks with qtdemix :
>file type : QuickTime (.mov)
>video codec : jpeg(apple photos jpeg)
>no sound
>size : 640x480
>Do you know if the problem becomes from audio stream or video stream
>(dvcp) ?
>Do you know what kind/type of test I should make to localize the bug ?
>Samuel


      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20080207/35364ecd/attachment.htm>