[gst-devel] Few questions about status of gstreamer

[Maxim Levitsky]

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 ?)