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

[Rahul Verma]

Hi,

Sorry for the late response, but was busy with other experiments with gstreamer.
Have a few more points to discuss.  

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

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?

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

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

Thanks again Mike. I went through the implementation of the frame drop logic 
in gstbasesink.c It is as you said, depending on Timestamp, duration and jitter.
I am still facing some AV Sync issues inspite of giving correct timestamp to the
video frames. Upon profiling i saw that the Jitter value keeps on increasing, forcing
the frames to be dropped. I also profiled the loop function of my demux and was surprised
to see that gst_pad_push was taking time in range or 150 ms, specially for audio. Since
pad_push is taking time, it increases the jitter and causes the frame drop.

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.

rahul
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20090119/0e731f49/attachment.htm>