[gst-devel] Few questions about status of gstreamer

[Maxim Levitsky]

On Wed, 2009-01-21 at 00:29 +0200, Maxim Levitsky wrote:
> 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 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.
> 
> 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
> 
> 
> - 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'
> 
> 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)
> 
> also generally there is no way to copy a raw stream from one container
> to another.
> 
> 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.
> 
> Gstreamer just stalls. 
> 
> 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.
> 
> 
> 
> 
> Best regards,
> 	Maxim Levitsky
> 
> PS: do you know whenever gstreamer can add an index to avi file?
> 
> 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 ?)
> 
> 
> 

Hi,

What do you think?

Maxim Levitsky