flvmux strange issue (Gstreamer 1.0.3)

[Guetcho Guetchev]

Hello guys,

Recently I have strange issues with the following pipeline:

appsrc --- x264enc ---capsfilter--- flvmux --- appsink
appsrc --- speex ------capsfilter------|

Basically I want to produce a flv stream (or a file), that contains speex encoded audio plus h264 encoded video.
I was told to use capsfilters when necessary to explicitly set the caps of the elements.


The input data is contained in a file. The video samples are I420 encoded, 640x480, 20 fps; the audio samples are LPCM, 44.1 kHz, 1 channel (mono), 16 bit little-endian.
The timestamps for the video are in seconds - double (8 bytes), as if returned from time() function.
The timestamps for the audio are in ticks - double again, each tick is 1 / rate, where rate = 44.1kHz.

This test case fails to build a .flv file even on linux (Ubuntu 12.04, 32-bit). The target system is ARM-based, unix - derivate.

By some reason I cannot use shared object in my build of Gstreamer. All modules are static .a libraries. Thus automatic elements like playbin cannot be used - I have to explicitly build the pipeline.

Here
        https://github.com/ggetchev/gst_test
                 you can get a sample application along with a sample data.

The issue:
The appsink produces very short samples (96 to 54 bytes long). Either values of TRUE or FALSE on  the "streamable" property makes no difference.
I tried even if the appsrc are seekable. The same result.
When logging with GST_DEBUG="flvmux:5" I get this warning: downstream is not seekable, but streamable=false. Will ignore that and create streamable output instead.
I have no idea how to make an appsink to be seekable. And I am not sure this is the root of the problem.  

Please, can you enlighten me where I do wrong.
Thanks in advance.

Getcho


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Tue, 2012-12-04 at 01:58 +0200, Guetcho Guetchev wrote:

Hi,

> Recently I have strange issues with the following pipeline:
>
> appsrc --- x264enc ---capsfilter--- flvmux --- appsink
> appsrc --- speex ------capsfilter------|
>
> Basically I want to produce a flv stream (or a file), that contains speex encoded audio plus h264 encoded video.
> I was told to use capsfilters when necessary to explicitly set the caps of the elements.
>
>
> The input data is contained in a file. The video samples are I420 encoded, 640x480, 20 fps; the audio samples are LPCM, 44.1 kHz, 1 channel (mono), 16 bit little-endian.
> The timestamps for the video are in seconds - double (8 bytes), as if returned from time() function.
> The timestamps for the audio are in ticks - double again, each tick is 1 / rate, where rate = 44.1kHz.
>
> This test case fails to build a .flv file even on linux (Ubuntu 12.04, 32-bit). The target system is ARM-based, unix - derivate.
>
> By some reason I cannot use shared object in my build of Gstreamer. All modules are static .a libraries. Thus automatic elements like playbin cannot be used - I have to explicitly build the pipeline.
>
> Here
> https://github.com/ggetchev/gst_test
> you can get a sample application along with a sample data.
>
> The issue:
> The appsink produces very short samples (96 to 54 bytes long). Either values of TRUE or FALSE on  the "streamable" property makes no difference.
> I tried even if the appsrc are seekable. The same result.
> When logging with GST_DEBUG="flvmux:5" I get this warning: downstream is not seekable, but streamable=false. Will ignore that and create streamable output instead.
> I have no idea how to make an appsink to be seekable. And I am not sure this is the root of the problem.  

I haven't looked too hard at your code (it's a lot of code, perhaps you
should try to narrow down the issue a bit, e.g. make a small program
that just pushed blocks of audio samples into appsrc ! speex ! flvmux !
appsink), but I noticed this:

 GST_BUFFER_DTS(buf) = tst;

Have you tried making this PTS ? DTS only really makes sense for encoded
data, but you are feeding raw video/audio as I understand it.

Also, you don't really those filter caps after the encoders. The muxer
already advertises that it wants stream-format=avc for h264, so x264enc
should figure out that by itself. The only situation where you might
need a capsfilter there is if you want to select a certain encoding
profile or level.

For speex, the capsfilter after the encoder is never needed. The
rate/channels output will depend on your input.

The more important thing is to set the right raw audio/video caps on the
appsrc elements.

Btw, you can set caps/pointer properties also like this:

 caps = gst_caps_new_simple ("foo/bar", NULL);
 g_object_set (appsrc, "caps", caps, NULL);
 gst_caps_unref (caps);

No need to go the GValue route.

Cheers
 -Tim

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

PS:

You can (perhaps should?) also set element properties like this:

g_object_set (mctx->video_source,
    "format", GST_FORMAT_TIME,
    "max-bytes", (guint64) (10 * w * h * 3 / 2),
    NULL);

Note that max-bytes property is of type guint64 not 'long', and the
format property is an enum type, not an integer type. Those are not
necessarily the same in the type system. I'm not sure if they get
converted to the right type automatically - check for warnings on the
terminal..

Cheers
 -Tim


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel