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

[Michael Smith]

On Mon, Jan 19, 2009 at 5:59 AM, Rahul Verma <rahul.verma at sasken.com> 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