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

Michael Smith msmith at xiph.org
Tue Jan 13 19:06:56 CET 2009

On Tue, Jan 13, 2009 at 3:43 AM, Rahul Verma <rahul.verma at sasken.com> wrote:
> Hi,
>>Really, this doesn't help too much. You'll need to attach a debugger
>>and see where things are going wrong. It could be that one of the
>>libraries gstreamer uses was compiled wrongly, so things are going
>>wrong "randomly", or it could be a bug in your plugin - we can't
>>guess. You might also find running it on a PC using a tool like
>>valgrind helpful - it might show you something you're doing wrong that
>>just luckily doesn't cause a crash on the PC, but does on your target
> Finally I was able to get Audio and Video working on target using my 3gp
> demux. As you pointed out correctly, bug was in my code. I was trying to
> access the file location from filesrc element using the following code, and
> it caused the crash.
>         fileSrcPeerPad = gst_pad_get_peer(filter->sinkPad);
>         if(NULL == fileSrcPeerPad)
>         {
>                 GST_DEBUG("gone.. no src peer pad. ");
>         }
>         //extract the file src element here and get the filename, fd and uri
>         fileSrcPeerElement = gst_pad_get_parent_element(fileSrcPeerPad);
>         element_class = GST_ELEMENT_CLASS(fileSrcPeerElement);
>         object_class = G_OBJECT_CLASS(element_class);
>         //try to extract the location from this GObject.
>         g_object_get(object_class, "location", &fileLocation, NULL);
> and after that do the file operations. Surprisingly, this piece of code
> worked
> on PC.
> Can you help me in finding the error in the code??

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.

> Also, now I have some AV Sync issues. Till now I have not implemented any AV
> Sync
> logic in my Demux or Sink. I am passing the video buffers decoded to the
> sink, but it
> seems that video frames are dropped by the framework and after that I see
> continuous
> breaks. Does the pipeline implement the frame drop logic? If yes what logic
> does it follow
> for frame drops? can you guide me to the piece of code in the framework for
> a better
> understanding.

Your demuxer should not implement any sync logic - it should timestamp
the buffers it outputs, but nothing more than that.

The sink is responsible for all synchronisation - but in general, you
shouldn't need to implement anything special. The base classes
(GstBaseSink, or subclasses like GstBaseVideoSink) should implement
everything for you - you just need to specify that it's a synchronised

Frame dropping is also generally done by the sink base classes, if the
buffers arrive too late. Frame dropping SHOULD also be implemented in
decoders (particularly video decoders) in response to QoS messages
from the sinks. The documentation goes into more detail about how this
works (can't remember precisely where, probably the design docs).


More information about the gstreamer-devel mailing list