[gst-devel] 3gp demux plugin working on PC but not on target

[Michael Smith]

On Tue, Jan 20, 2009 at 5:43 AM, Rahul Verma <rahul.verma at sasken.com> wrote:
> 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?

ffmpeg_demux should not be used as a reference plugin for anything.
It's not a good example to use at all. Don't use it for any
comparisons; the ffmpeg demuxers are known to work poorly (and in many
cases not work at all).

 I don't actually know what it does internally - I haven't looked -
but a gstreamer demuxer plugin can't act on a file directly, because
it doesn't even know if there IS a file involved at all.

By "it must pull data" I mean that to get data from the upstream
element (in pull mode), you must use gst_pad_pull_range().



>
>>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.

I don't know either. Sorry, I can only give general suggestions, since
you're not writing an open source plugin. Looking at the debug output
(GST_DEBUG) might help you.

Mike