Frame Loss in mp4 stream

[Thiago Santos]

On 09/11/2014 11:47 AM, Prabhakar Lad wrote:
> Hi,
>
> Thanks for the response.
>
> On Thu, Sep 11, 2014 at 3:10 PM, Thiago Santos <thiagoss at osg.samsung.com> wrote:
>> On 09/10/2014 03:29 PM, Prabhakar Lad wrote:
>>> Hi,
>>>
>>> I have the following pipeline:-
>>>     gst_element_link_many (appvideosrc, videoqueue, vvalve, videoparse,
>>> mux, filesink, NULL);
>>>     gst_element_link_many (appaudiosrc, audioqueue, avalve, audioparse,
>>> mux, NULL);
>>>
>>>
>>> initially the vvalve and avalve elements 'drop' property is set to
>>> TRUE, on after an event I set the 'drop' to FALSE and the data is
>>> written to filesink.
>>>
>>> I am observing that the there is a frame loss at this particular event
>>> (when drop is set to false) in the video.
>> Which event is this? Is this a gstreamer event that you are probing?
>>
> It is not a gstreamer event, I am having a global variable set on
> event(key press)
> so when this key press happens the 'valve' is set to drop as FALSE.
>
>> And how are you detecting a frame was lost? Is it the first or one in the
>> middle?
>>
> I am playing the video in VLC player at lower speeds. Its actually the
> middle one.
>>
>>> NOTE:- both appsrc are live
>>>
>>> Any possible reasons why it looses the frames ? any possible solutions
>>> to avoid this would be helpful.
>> What version of gstreamer are you using?
>>
> gstreamer 1.0
>
>> I'd start debugging by adding some debug entries to valve to check if it
>> drops any buffers after setting the drop to false.
>>
> does sudden change in min-threshold-time (set 0) cause this ?
>
> Initially when valve's drop property is set to TRUE the queue
> properties are set to following,
>
> "min-threshold-time=15000000000 min-threshold-buffers=0 min-threshold-bytes=0
> max-size-bytes=0 max-size-buffers=0 max-size-time=15000000000"
>
> And after the event valve's drop property is set to FALSE and queue
> properties are set to following
> "min-threshold-time=0"
Do you have a leaky queue? That could drop buffers if downstream isn't 
consuming fast enough.

What is your input that is live? If downstream doesn't consume fast 
enough it might also cause buffers to be lost.

You can track the buffers in the pipeline using 
GST_DEBUG=GST_SCHEDULING:9 and look at the messages like:

"GST_SCHEDULING 
gstpad.c:3834:gst_pad_chain_data_unchecked:<fakesink0:sink> calling 
chainfunction &gst_base_sink_chain with buffer buffer: 0x7f43fc0250a0, 
pts 0:00:00.000000000, dts 0:00:00.000000000, dur 0:00:00.033333333, 
size 115200, offset 0, offset_end 1, flags 0x40"

This means that a buffer was pushed into fakesink0:sink and you have all 
the details from the buffers (pointer and pts are likely the most 
important for you). So you can check if all buffers that are feed to 
appsrc are actually making it to the muxer and find if there is indeed a 
buffer missing (and what element dropped it).

As you said this is a live stream, it can also be that this frame was 
lost before it even reached gstreamer.

>
> Thanks,
> --Prabhakar
>
>>> Thanks,
>>> --Prabhakar
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>> --
>> Thiago Sousa Santos
>> Senior Multimedia Engineer, Open Source Group
>> Samsung Research America - Silicon Valley
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


-- 
Thiago Sousa Santos
Senior Multimedia Engineer, Open Source Group
Samsung Research America - Silicon Valley