Hi,
>If you're in pull mode, you can (and should) pull from the upstream
>element - which might, internally, use some sort of 'file handle', but
>equally, it might not.
Yes my plugin works in pull mode. But even in the reference
plugin(ffmpeg_demux), I saw functions av_input_file_open, av_read_frame
being used. I tried to go inside these functions and saw url_open and
similar functions being used. Is it not as good as getting a file
pointer directly and doing the file operations? What exactly do you mean
when you say it must pull data?
>gst_pad_push() will not generally return immediately. In this
>pipeline, your demuxer is pushing buffers into a queue element. That
>should be very fast usually (it just takes the appropriate locks, then
>adds the buffer to the queue element's internal queue of buffers.
>However, if the queue is full, it'll block until the queue stops being
>full.
>In your case, I don't know why you're seeing increasing time taken for
>pushing on your pad - perhaps your timestamps or wrong, or your sink
>or decoder isn't working correctly?
I checked the timestamp values again and I compared with the timestamp
values of the open source demuxer too. Since my 3gp reader gives time in
milliseconds I multiply it with 1000000 to convert it into nanoseconds
and give it to the sink. So the difference is very minor. Problem is
still the same. _loop function of my parser plugin is taking too much
time.
Currently in my loop function I am doing the following steps:
Seek to video offset.
Allocate video buffer from video source pad
Read from file into the buffer.
Push the buffer.
Same for audio.
I don't understand why _push_pad function time goes to 100s of
millisecond.
Regards,
Rahul
Message: 3
Date: Mon, 19 Jan 2009 10:24:26 -0800
From: Michael Smith <
[hidden email]>
Subject: Re: [gst-devel] 3gp demux plugin working on PC but not on
target
To: Discussion of the development of GStreamer
<
[hidden email]>
Message-ID:
<
[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jan 19, 2009 at 5:59 AM, Rahul Verma <
[hidden email]>
wrote:
>
>>The whole concept is badly broken. Your element should not be poking
>>at the implementation details of its peer - there's no reason to
>>expect that the peer even HAS a "location" property.
>>
>>So, you should stop doing that entirely. I didn't check the actual
>>code to see if there was an obvious bug in the actual implementation,
>>because it really doesn't matter.
>
> Thanks Mike. Your point is valid. But for a 3gp reader, which works in
a
> pull mode, the file operations has to be done by the reader, since it
> knows the parsing logic. If my understanding is correct, then it has
to get
> the file handle. What is the alternative way to get the file handle
then?
If you're in pull mode, you can (and should) pull from the upstream
element - which might, internally, use some sort of 'file handle', but
equally, it might not.
To do this, you use gst_pad_pull_range() on your element's sinkpad.
You MUST NOT directly use any sort of file handle.
>
> my pipeline is
>
> filesrc ! 3gpdemux name=demux demux.! queue ! videodecoder !
> videosink demux.! queue ! audiodecoder ! osssink
>
> Is gst_pad_push a synchronous call and will be blocking? Initially all
is
> well, but as soon as
> rendering starts, gst_push_pad time starts increasing.
gst_pad_push() will not generally return immediately. In this
pipeline, your demuxer is pushing buffers into a queue element. That
should be very fast usually (it just takes the appropriate locks, then
adds the buffer to the queue element's internal queue of buffers.
However, if the queue is full, it'll block until the queue stops being
full.
In your case, I don't know why you're seeing increasing time taken for
pushing on your pad - perhaps your timestamps or wrong, or your sink
or decoder isn't working correctly?
Mike
SASKEN BUSINESS DISCLAIMER
-------------------------
This message may contain confidential, proprietary or legally privileged information. In
case you are not the original intended Recipient of the message, you must not, directly or
indirectly, use, Disclose, distribute, print, or copy any part of this message and you are
requested to delete it and inform the sender. Any views expressed in this message are
those of the individual sender unless otherwise stated. Nothing contained in this message
shall be construed as an offer or acceptance of any offer by Sasken Communication
Technologies Limited ("Sasken") unless sent with that express intent and with due
authority of Sasken. Sasken has taken enough precautions to prevent the spread of
viruses. However the company accepts no liability for any damage caused by any virus
transmitted by this email
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Locked
logs_target1.txt (9K)