[gst-devel] Few questions about status of gstreamer
Maxim Levitsky
maximlevitsky at gmail.com
Fri Jan 30 13:32:08 CET 2009
On Tue, 2009-01-27 at 00:13 +0200, Stefan Kost wrote:
> 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 will do so when I have more free time,
but a website with plain links, that would reflect current status of
gstreamer would be very nice, also somebody with windows can test same
links there, to weed out dead links
(or a windows in a VM that is)
> >
> > 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.
I will soon, but can't mixers just take anything inside?
Why they have to be picky?
>
> >
> > 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 :/
Nether I need it, even gst-launch supports omitting the sources, but you
say about stable version, so you will change this when you start next
dev version?
>
> >
> > - 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.
The ptoblem is that input seems to send extra frames there (its a mms
stream), so without videorate, output stream still A/V synced, but audio
skips a lot, videorate on the other hand ensures that video frames are
skipped, and now A/V sync is perfect.
> >
> > 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.
gst-launch \
\
mmssrc location="mms://live1.wm.skynews.servecast.net/skynews_wmlz_live300k" ! queue ! asfdemux name=demuxer \
\
demuxer.audio_00 ! queue ! ffmux_asf name=muxer \
\
demuxer.video_00 ! queue ! muxer. \
\
muxer. ! queue ! fakesink -v
also tried avimux, matroskamux, and both even don't have (again...) caps
for wma/wmv.
On the other hand mencoder does the same job perfectly.
I first save the mms stream, and I tried to give saved stream to
gstreamer, and got same results
>
> >
> > 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 ?)
> >
> >
> >
Best regards,
Maxim Levitsky
More information about the gstreamer-devel
mailing list