flvmux strange issue (Gstreamer 1.0.3)

[Tim-Philipp Müller]

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