AppSink vs FileSink question

[Andrey Nechypurenko-2]

Hi Folks,

In my application I want to capture the output of the encoding
pipeline for further processing. So my assumption was that using
appsink would give me the same byte stream as the one stored in file
with filesink. To be more concrete, I have the following pipeline:

  pipeline =
    GST_PIPELINE(gst_parse_launch
                 ("videotestsrc ! "
                  "video/x-raw-yuv,width=640,height=480,framerate=30/1 ! "
                  "x264enc ! "
                  "matroskamux ! "
                  "appsink name=mysink",
                  NULL));

then, after setting up the callback I just write the buffer into file:

  GstElement *mysink = gst_bin_get_by_name(GST_BIN(this->pipeline), "mysink");
  g_object_set(G_OBJECT(mysink), "emit-signals", TRUE, "sync", FALSE, NULL);
  g_signal_connect(mysink, "new-buffer", G_CALLBACK (on_new_buffer), NULL);

static void
on_new_buffer(GstElement *element, void *data)
{
  GstBuffer *buffer = gst_app_sink_pull_buffer(GST_APP_SINK(element));
  fwrite(GST_BUFFER_DATA(buffer), GST_BUFFER_SIZE(buffer), 1, f);
  gst_buffer_unref(buffer);
}

To my surprise, the content of the file is not recognized as matroska
container. The header (the beginning of the file) is indeed totally
different from what I get if I execute the following command line:

gst-launch videotestsrc !
video/x-raw-yuv,width=640,height=480,framerate=30/1 ! x264enc !
matroskamux ! filesink location=test.mka

So my question is - am I right assuming that my application with
appsink should produce correct mka file similar to the command line
with filesink?

If not, I would appreciate any suggestion or hints on how the pipeline
should looks like to playback what is recorded by appsink in the
scenario mentioned above.


Thank you very much!
Andrey.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Thiago Sousa Santos-2]

On Sun, Jul 4, 2010 at 11:42 AM, Andrey Nechypurenko <[hidden email]> wrote:

Hi Folks,

In my application I want to capture the output of the encoding
pipeline for further processing. So my assumption was that using
appsink would give me the same byte stream as the one stored in file
with filesink. To be more concrete, I have the following pipeline:

 pipeline =
   GST_PIPELINE(gst_parse_launch
                ("videotestsrc ! "
                 "video/x-raw-yuv,width=640,height=480,framerate=30/1 ! "
                 "x264enc ! "
                 "matroskamux ! "
                 "appsink name=mysink",
                 NULL));

then, after setting up the callback I just write the buffer into file:

 GstElement *mysink = gst_bin_get_by_name(GST_BIN(this->pipeline), "mysink");
 g_object_set(G_OBJECT(mysink), "emit-signals", TRUE, "sync", FALSE, NULL);
 g_signal_connect(mysink, "new-buffer", G_CALLBACK (on_new_buffer), NULL);

static void
on_new_buffer(GstElement *element, void *data)
{
 GstBuffer *buffer = gst_app_sink_pull_buffer(GST_APP_SINK(element));
 fwrite(GST_BUFFER_DATA(buffer), GST_BUFFER_SIZE(buffer), 1, f);
 gst_buffer_unref(buffer);
}

To my surprise, the content of the file is not recognized as matroska
container. The header (the beginning of the file) is indeed totally
different from what I get if I execute the following command line:

gst-launch videotestsrc !
video/x-raw-yuv,width=640,height=480,framerate=30/1 ! x264enc !
matroskamux ! filesink location=test.mka

So my question is - am I right assuming that my application with
appsink should produce correct mka file similar to the command line
with filesink?

The problem here is that muxers usually have to seek back to rewrite some values it didn't know from the start to properly finish the file. Appsink doesn't provide a way to notify about this and filesink obviously handles it.

Checkout this bug for further info:

https://bugzilla.gnome.org/show_bug.cgi?id=570619

 

If not, I would appreciate any suggestion or hints on how the pipeline
should looks like to playback what is recorded by appsink in the
scenario mentioned above.


Thank you very much!
Andrey.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
Thiago Sousa Santos

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Andrey Nechypurenko-2]

>> So my question is - am I right assuming that my application with
>> appsink should produce correct mka file similar to the command line
>> with filesink?
>
> The problem here is that muxers usually have to seek back to rewrite some
> values it didn't know from the start to properly finish the file. Appsink
> doesn't provide a way to notify about this and filesink obviously handles
> it.
> Checkout this bug for further info:
> https://bugzilla.gnome.org/show_bug.cgi?id=570619

Thanks! I'll check it out.

Andrey.

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel