Data loss of around 1.7 sec at start of every capture

[Stefan Sauer]

On 09/29/2015 02:08 PM, Ashish Kumar Mishra wrote:
> Dear Group Members ,
>
> Our requirement is to create an 5min file for 8hours continuously.
> So currently we are doing an pipeline start & stop after every 5min.
> Below is the details
>
>  A) We have build an Gst application for :-
>         Processor ( TI Netra DM8168)
>         Audio ( Stereo 16bit 44.1KHZ)
>         Video ( DVI 1080p @ 60hz using TFP401A-EP)
>         MUX  (MATROSKA)
>         Overlay ( Time )
>         Filesink as ".avi"
>
>
> B) We are loosing around 1.7sec at the start of every capture. Let me
> explain
>      If we put the pipeline in PLAYING mode at t=0 for total duration
> of 100 sec , the recordded file has below mentioned status :-
>         a) Video from t=0 to t=1.5 sec is not captured in the recorded
> file .
>         b) The recorded file has first frame of video  from t=1.5 sec
> to t=101.5 sec
>
>
> C)  This data loss of initial 1.5sec is observed every time i start &
> stop the engine.
>
> D) The basic flow is :-
>      a) Creating the pipeline with the elements and linking them in
> main thread .
>            gst_bin_add_many(GST_BIN(pipeline), AVIMux, FileSink,NULL);
>            gst_bin_add_many(GST_BIN(pipeline), omx_videosrc,
> clockoverlay, omx_videoEnc,NULL);
>            gst_element_link_many(omx_videosrc,
> clockoverlay,omx_videoEnc, AVIMux, NULL);
>            gst_bin_add(GST_BIN(pipeline), alsaAudSrc);
>            gst_element_link(alsaAudSrc, AVIMux);
>            gst_element_link(AVIMux, FileSink);

You probably want to use timeoverlay instead of clockoverlay to check
the delay of the first frame.
>
>            if (TRUE != gst_pipeline_set_clock(pipeline,
> gst_system_clock_obtain())) {
>                 printf("gst_pipeline_set_clock(GstSystemClock) did not
> work\n");
>                 nRetVal = FAILURE;
>                 goto labelExit;
>            }
>
>
>
>      b) Create an child thread and do the below mentioned activities (
> rough flow ):-
>              GSource *bus_source;
>              GstBus *bus;
>              main_loop_cntxt = g_main_context_new();
>              g_main_context_push_thread_default(main_loop_cntxt);
>              bus = gst_element_get_bus (pipeline); // Pipeline is
> created in parent thread
>              bus_source = gst_bus_create_watch (bus);
>              g_source_set_callback (bus_source, (GSourceFunc)
> gst_bus_async_signal_func, NULL, NULL);
>              g_source_attach (bus_source, main_loop_cntxt);
>              g_source_unref (bus_source);
>              g_signal_connect (G_OBJECT (bus), "message::error",
> (GCallback)error_cb, NULL);
>              g_signal_connect (G_OBJECT (bus), "message::eos",
> (GCallback)eos_cb, NULL);
>              main_loop = g_main_loop_new(main_loop_cntxt, FALSE);
>              gst_element_set_state (pipeline, GST_STATE_PLAYING);
>
>              if (gst_element_get_state (pipeline, NULL, NULL,
> (GST_SECOND * 10)) == GST_STATE_CHANGE_FAILURE){
>                         goto exit_label;
>              }
>              g_main_loop_run (main_loop);
>
>
>
> So could team members please let me know where should we debug and
> probable point of problem.
>
> Thanks ,
> Ashish Kumar Mishra
>
This might be better to be discussed in a bug report.

What I've tried:
gst-launch-1.0 videotestsrc num-buffers=1 ! timeoverlay ! pngenc !
filesink location=/home/ensonic/img1.png
here the buffer timestamp is 0.0.
And
gst-launch-1.0 v4l2src num-buffers=1 ! timeoverlay ! pngenc ! filesink
location=/home/ensonic/img2.png
here the buffer timestamp is ~0.6-0.7 sec (on a laptop).

I would not describe this as loosing frames. It is just that for a live
src, the time of the first buffer is not starting at 0.0

Stefan