[gst-devel] Few questions about status of gstreamer

[Stefan Kost]

Maxim Levitsky schrieb:
> Hi,
> 
> I was tinkering with gstreamer lately, and I find it qute nice platform.
> 
> I would like to know where current development is headed, and what to
> expect.
> 
> While the concept of gstreamer is great, the current implementation
> isn't that great, I would like to point at following things:
> 
> - web live streams playback is very bad compared even to other linux
> media players, as a test case visit any web site that offers list of
> live web channels, and you will be able to watch maybe 8% og them or so,
> this is very sad. I know that there are property features, but many
> streams are yet playable in vlc or mplayer.

I don't think its that bad, but please file bugs. Thats the only way to improve
it. Its helpful if you can try to narrow down whats causing the failure, like if
you can cluster the features that cause problems.
> 
> I wish there were a general database of links to such streams that will
> be visited by gstreamer/totem developers as this will encourage them to
> fix support for that.
> Also such database will ease the regression testing.
> ( for example ms switched to asf over rtsp, and I see some streams that
> use it, but gstreamer will just fail as it will think it is a mms stream
> also support for wmv over rtsp isn't in gstreamer, patches are aviable,
> but it doesn't seem that they will be mereged soon. sad. I have no free
> time yet ( might have some in near future ) to do that myself.
> 
> ( note that I am speaking about web sites that offer list of live
> streams, as they provide direct links without fancy media player
> testing, this rules out web page incompatibilities due to sites using
> windows only player controls)
> 
> 
> - gstreamer elements are far from beeng generic:
> look at that for example :
> 
> maxim at maxim-laptop:~$ gst-inspect  xvidenc | grep video
>   Long name:	XviD video encoder
>       video/x-raw-yuv
>       video/x-raw-rgb
>       video/x-raw-rgb
>       video/x-raw-rgb
>       video/x-raw-rgb
>       video/x-raw-rgb
>       video/x-raw-rgb
>       video/x-raw-rgb
>       video/x-xvid
> 
> as you see it supports only 'video/x-xvid' on output, but why, isn't
> xvid output plain mpeg-4 ?
> 
> on the other hand
> 
> maxim at maxim-laptop:~$ gst-inspect  ffmux_mp4 | grep video
>       video/quicktime
>   SINK template: 'video_%d'
>       video/mpeg
>       video/x-divx
>       video/x-h264
> 
> this is just one of may examples.

Again please file bugs. You are right we have issues like this. The sheer amount
of plugins requires quite some effort on maintenance. Of course bug with patches
are even nicer.

> 
> in other words currently muxers are very picky about formats they can
> handle although underlying formats can hold much more codecs
> AVI for example can pretty much hold any codec that have fourcc code. 
> 
> 
> also note that sinks of muxers sometimes are named video_[0-9] and
> sometimes video_[0-9][0-9]
> 
> while it is possible to avoid referencing those names directly, still it
> would be better to have standard naming
> 
Unfortunately this can't be changed in the stable development series :/

> 
> - There are many pipeline stalls.
> it might be no joy to sit for a 4 hours to figure out 
> 'where did I forgot to put that 'queue'
>

Yes thats annoying, but imho its not easy to detect this from within gstreamer.
If you know a way, eternal fame awaits you.

> 
> also without magic 'videorate' that drops frames on demand (right?) it
> is very hard/impossible to create working pipeline, (not to mention that
> you absolutely need queues after each encoder)
>
I can't follow here. Many elements implement qos and they will take messures on
high cpu load like dropping frames. The queues are a nice concept for
multithreading.
> 
> also generally there is no way to copy a raw stream from one container
> to another.
Thats wrong.
> 
> I for example tried to put asf stream (captured into file) ( gstream
> doesn't seem to support seeking in it) to avi, which is possible and is
> done nicely by mencoder.
Of course you can't put an asf into an avi. Both are containers.
Besides seeking in asf works, seeking on mms streams very recently got implemented.
> 
> Gstreamer just stalls. 

Tell us what pipelines you have used and we might be able to help.

> 
> I figured out that the problem was that intially input stream contained
> one big (~  27 KB) chunk of video data, and then audio, but this made
> asfdemux stall, as it can't pull both video and audio data seperatly
> 
> In other words demuxers can easily stall if input stream isn't evenly
> interleaved.

Yes, use big enough queues after the demuxer, or even better use multiqueue.

> 
> 
> Best regards,
> 	Maxim Levitsky
> 
> PS: do you know whenever gstreamer can add an index to avi file?

avimux could take a round of improvements. Not sure about that.

long mail = lots of answers. lets look at the issues one by one
Stefan

> 
> I use this command to record a live asf stream:
> 
> 
>> #source description
>> export SOURCE_PROTOCOL=mmssrc
>> export SOURCE_DEMUXER=asfdemux
>> export SOURCE_AUDIO_CODEC=ffdec_wmav2
>> export SOURCE_VIDEO_CODEC=ffdec_wmv3
>>
>> #destanation description
>> export DEST_PROTOCOL=filesink
>> export DEST_MUXER=avimux
>> export DEST_AUDIO_CODEC=lame
>> export DEST_VIDEO_CODEC=xvidenc
> 
>> gst-launch												\
>>  	$SOURCE_PROTOCOL location=$SOURCE_LOCATION ! queue ! $SOURCE_DEMUXER name=demuxer 		\
>> 													\
>>  	demuxer.   ! queue ! $SOURCE_VIDEO_CODEC ! videorate ! postproc_default ! tee name=raw_video 	\
>> 	demuxer.   ! queue ! $SOURCE_AUDIO_CODEC ! tee name=raw_audio 					\
>> 													\
>> 	raw_video. ! queue leaky=1 ! $DEST_VIDEO_CODEC ! queue ! $DEST_MUXER name=muxer 		\
>> 	raw_audio. ! queue leaky=1 ! $DEST_AUDIO_CODEC ! queue ! muxer. 				\
>> 													\
>>  	raw_video. ! queue ! gconfvideosink 								\
>>  	raw_audio. ! queue ! gconfaudiosink 								\
>> 													\
>> 	muxer.     ! $DEST_PROTOCOL location=$DEST_LOCATION 						\
> 
> It works, but resulting file can be seeking to non key-frames, which
> obliviously make seeking very unpleasant.
> (since muxers are limited to such small number of codecs, can't they
> know which frames are key and which not ?)
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel