Frame Loss in mp4 stream

[Prabhakar Lad]

Hi

On Thu, Sep 11, 2014 at 5:36 PM, Prabhakar Lad
<prabhakar.csengg at gmail.com> wrote:
> Hi,
>
> Thanks for the response.
>
> On Thu, Sep 11, 2014 at 4:09 PM, Thiago Santos <thiagoss at osg.samsung.com> wrote:
>> On 09/11/2014 11:47 AM, Prabhakar Lad wrote:
>>>
> [snip]
>>> 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.
>>
> No the queue is not leaky.
>
>> What is your input that is live? If downstream doesn't consume fast enough
>> it might also cause buffers to be lost.
>>
> Yes the input is live. from the valve it goes to mux and then to filesink.
> by any chance does h264parse/mp4mux/filesink drop frames ?
>
>> 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"
>>
> Ok will try out.
>
>> 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.
>>
> I have tested the live stream is fine. I find this issue only when
> using a rolling buffer of 15 seconds.
>
Forgot to ask another question,

    gst_element_link_many (videosrc,  rlvideoqueue, rlvvalve,
videoparse, videoqueue, mux, filesink, NULL);
    gst_element_link_many (audiosrc,  rlaudioqueue, rlavalve,
audioparse, audioqueue, mux, NULL);


    g_object_set (G_OBJECT (rlvideoqueue), "min-threshold-time",
(guint64)threshold_time, NULL);
    g_object_set (G_OBJECT (rlvideoqueue), "min-threshold-buffers",
(guint64)0, NULL);
    g_object_set (G_OBJECT (rlvideoqueue), "min-threshold-bytes",
(guint64)0, NULL);
    g_object_set (G_OBJECT (rlvideoqueue), "max-size-bytes", (guint64)0, NULL);
    g_object_set (G_OBJECT (rlvideoqueue), "max-size-buffers",
(guint64)0, NULL);
    g_object_set (G_OBJECT (rlvideoqueue), "max-size-time",
(guint64)threshold_time, NULL);

    g_object_set (G_OBJECT (rlaudioqueue), "min-threshold-time",
(guint64)threshold_time, NULL);
    g_object_set (G_OBJECT (rlaudioqueue), "min-threshold-buffers",
(guint64)0, NULL);
    g_object_set (G_OBJECT (rlaudioqueue), "min-threshold-bytes",
(guint64)0, NULL);
    g_object_set (G_OBJECT (rlaudioqueue), "max-size-bytes", (guint64)0, NULL);
    g_object_set (G_OBJECT (rlaudioqueue), "max-size-buffers",
(guint64)0, NULL);
    g_object_set (G_OBJECT (rlaudioqueue), "max-size-time",
(guint64)threshold_time, NULL);

  g_object_set (G_OBJECT (rlvvalve), "drop", (gboolean)TRUE, NULL);
  g_object_set (G_OBJECT (rlavalve), "drop", (gboolean)TRUE, NULL);


Following is the code snippet:-

When on event if I just change the following :
  g_object_set (G_OBJECT (rlvvalve), "drop", (gboolean)FALSE, NULL);
  g_object_set (G_OBJECT (rlavalve), "drop", (gboolean)FALSE, NULL);

The pipeline doesnt write to the file with above, If and only if I set
the following the pipeline writes to the file,
     g_object_set (G_OBJECT (rlvideoqueue), "min-threshold-time",
(guint64)0, NULL);
     g_object_set (G_OBJECT (rlaudioqueue), "min-threshold-time",
(guint64)0, NULL);

Isn’t that weird ?

Thanks,
--Prabhakar