Few questions about status of gstreamer
Locked
Few questions about status of gstreamer
 
|
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@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@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 ?) ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Few questions about status of gstreamer
|
|
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@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@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 ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Few questions about status of gstreamer
|
|
In reply to this post by Maxim Levitsky
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@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@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 > > > - 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 > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Few questions about status of gstreamer
|
|
In reply to this post by Maxim Levitsky
PS: do you know whenever gstreamer can add an index to avi file? You just have to fire an EOS event to finalize the file and build the index ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Few questions about status of gstreamer
|
|
On Tue, 2009-01-27 at 00:33 +0100, Andoni Morales wrote:
> 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 ?) > > You just have to fire an EOS event to finalize the file and build the > index > Is there a way to do so with gst-launch? (I guess no) I write an app using this pipeline someday. Best regards, Maxim Levitsky ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Re: Few questions about status of gstreamer
|
|
In reply to this post by Stefan Sauer
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. 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@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@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. 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 :/ 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. 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 ------------------------------------------------------------------------------ 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |