Could not close resource error when using gnomevfssrc with ftp

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Could not close resource error when using gnomevfssrc with ftp

Tiago Katcipis
Im having some trouble using gnomevfssrc and ftp, what troubles me is the error, a simple Could not open would make me understand that i did something wrong or something is wrong with the server.... but this error msg "Could not close"... i simply cant find anything about it, I'm not quite sure if this is something wrong on the ftp server i am using here or if it is a problem with gnomevfs or gstreamer.

The test is simple:

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! decodebin ! pulsesink

The output is:
(gst-launch-0.10:2735): GLib-WARNING **: g_set_prgname() called multiple times
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = audio/x-wav
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:sink: caps = audio/x-wav
ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close resource.
Additional debug info:
gstgnomevfssrc.c(889): gst_gnome_vfs_src_stop (): /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0:
Could not close vfs handle: Operation cancelled
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = NULL
Freeing pipeline ...

Even the wav file header is being read, but on the prerolling this odd error happens. The same url that generates this error works just fine on wget (the file gets downloaded and i can hear it perfectly).

can someone help me? I'm not very used to ftp...maybe I'm missing something.

best regards,
Katcipis

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Could not close resource error when using gnomevfssrc with ftp

Tiago Katcipis
now i got some interesting results, testing with a pipeline like this:

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! filesink location="test.wav"

im able to get the file and play it locally.

even if i run:
gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! audio/x-raw-int,signed=true,channels=1,rate=8000,width=16,endianness=1234 ! pulsesink

it works(and i hear a lot of noise :-)).

But if i run:

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! audio/x-raw-int,signed=true,channels=1,rate=8000,width=16,endianness=1234 ! audioparse ! pulsesink

or

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! wavparse ! pulsesink

or

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! decodebin ! pulsesink

it gives the same error:

ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close resource.

it seems that every time i try to parse the file to get its type and play it, it fails, but if i only play it raw or download it.... works fine.

any toughts?



On Fri, Apr 16, 2010 at 11:42 AM, Tiago Katcipis <[hidden email]> wrote:
Im having some trouble using gnomevfssrc and ftp, what troubles me is the error, a simple Could not open would make me understand that i did something wrong or something is wrong with the server.... but this error msg "Could not close"... i simply cant find anything about it, I'm not quite sure if this is something wrong on the ftp server i am using here or if it is a problem with gnomevfs or gstreamer.

The test is simple:

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! decodebin ! pulsesink

The output is:
(gst-launch-0.10:2735): GLib-WARNING **: g_set_prgname() called multiple times
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = audio/x-wav
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:sink: caps = audio/x-wav
ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close resource.
Additional debug info:
gstgnomevfssrc.c(889): gst_gnome_vfs_src_stop (): /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0:
Could not close vfs handle: Operation cancelled
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = NULL
Freeing pipeline ...

Even the wav file header is being read, but on the prerolling this odd error happens. The same url that generates this error works just fine on wget (the file gets downloaded and i can hear it perfectly).

can someone help me? I'm not very used to ftp...maybe I'm missing something.

best regards,
Katcipis


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Could not close resource error when using gnomevfssrc with ftp

Tiago Katcipis
trying to solve my problem i found another one :-).

using a public ftp i run this:
gst-launch -v gnomevfssrc location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 ! queue ! decodebin ! fakesink

and it works ok, the ftp is really slow...it takes a good time before it starts to download and decode....but works

even if i try:
gst-launch -v gnomevfssrc location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 ! queue ! decodebin ! alsasink

i can hear the music (it takes a while to go from paused to playing, something like 20-30 seconds....but if you wait it wil happen).

But if i take the queue element out:
gst-launch -v gnomevfssrc location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 ! decodebin ! fakesink

the pipe stays blocked for ever (on both cases)... is this behavior expected? have anyone faced something like that? is a good policy to always put a queue after a gnomevfssrc?

if someone have other ftp server to test this i would appreciate.

best regards,
Katcipis


On Fri, Apr 16, 2010 at 2:03 PM, Tiago Katcipis <[hidden email]> wrote:
now i got some interesting results, testing with a pipeline like this:

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! filesink location="test.wav"

im able to get the file and play it locally.

even if i run:
gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! audio/x-raw-int,signed=true,channels=1,rate=8000,width=16,endianness=1234 ! pulsesink

it works(and i hear a lot of noise :-)).

But if i run:

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! audio/x-raw-int,signed=true,channels=1,rate=8000,width=16,endianness=1234 ! audioparse ! pulsesink

or

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! wavparse ! pulsesink

or


gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! decodebin ! pulsesink

it gives the same error:


ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close resource.

it seems that every time i try to parse the file to get its type and play it, it fails, but if i only play it raw or download it.... works fine.

any toughts?



On Fri, Apr 16, 2010 at 11:42 AM, Tiago Katcipis <[hidden email]> wrote:
Im having some trouble using gnomevfssrc and ftp, what troubles me is the error, a simple Could not open would make me understand that i did something wrong or something is wrong with the server.... but this error msg "Could not close"... i simply cant find anything about it, I'm not quite sure if this is something wrong on the ftp server i am using here or if it is a problem with gnomevfs or gstreamer.

The test is simple:

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! decodebin ! pulsesink

The output is:
(gst-launch-0.10:2735): GLib-WARNING **: g_set_prgname() called multiple times
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = audio/x-wav
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:sink: caps = audio/x-wav
ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close resource.
Additional debug info:
gstgnomevfssrc.c(889): gst_gnome_vfs_src_stop (): /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0:
Could not close vfs handle: Operation cancelled
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = NULL
Freeing pipeline ...

Even the wav file header is being read, but on the prerolling this odd error happens. The same url that generates this error works just fine on wget (the file gets downloaded and i can hear it perfectly).

can someone help me? I'm not very used to ftp...maybe I'm missing something.

best regards,
Katcipis



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Could not close resource error when using gnomevfssrc with ftp

Tiago Katcipis
well it seems that is the same problem, i resolved to let the pipeline "blocked" for a long time...and after something like 23min it happens the same thing (Could not close resource.).

i run a full debugged launch and attached the part where the error occurs (after 23 minutes).

gst-launch -v gnomevfssrc location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 ! decodebin ! fakesink --gst-debug=5 2> no_queue.log
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = audio/x-wav
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close resource.
Additional debug info:
gstgnomevfssrc.c(889): gst_gnome_vfs_src_stop (): /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0:
Could not close vfs handle: Operation cancelled
Setting pipeline to NULL ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = NULL
Freeing pipeline ...

any hints if this is normal and i have to always use a queue after using a vfs src element? maybe a bug on gnomevfssrc regarding an specific behaviour of the ftp server?

On Mon, Apr 19, 2010 at 10:35 PM, Tiago Katcipis <[hidden email]> wrote:
trying to solve my problem i found another one :-).

using a public ftp i run this:
gst-launch -v gnomevfssrc location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 ! queue ! decodebin ! fakesink

and it works ok, the ftp is really slow...it takes a good time before it starts to download and decode....but works

even if i try:
gst-launch -v gnomevfssrc location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 ! queue ! decodebin ! alsasink

i can hear the music (it takes a while to go from paused to playing, something like 20-30 seconds....but if you wait it wil happen).

But if i take the queue element out:
gst-launch -v gnomevfssrc location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 ! decodebin ! fakesink

the pipe stays blocked for ever (on both cases)... is this behavior expected? have anyone faced something like that? is a good policy to always put a queue after a gnomevfssrc?

if someone have other ftp server to test this i would appreciate.

best regards,
Katcipis



On Fri, Apr 16, 2010 at 2:03 PM, Tiago Katcipis <[hidden email]> wrote:
now i got some interesting results, testing with a pipeline like this:

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! filesink location="test.wav"

im able to get the file and play it locally.

even if i run:
gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! audio/x-raw-int,signed=true,channels=1,rate=8000,width=16,endianness=1234 ! pulsesink

it works(and i hear a lot of noise :-)).

But if i run:

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! audio/x-raw-int,signed=true,channels=1,rate=8000,width=16,endianness=1234 ! audioparse ! pulsesink

or

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! wavparse ! pulsesink

or


gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! decodebin ! pulsesink

it gives the same error:


ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close resource.

it seems that every time i try to parse the file to get its type and play it, it fails, but if i only play it raw or download it.... works fine.

any toughts?



On Fri, Apr 16, 2010 at 11:42 AM, Tiago Katcipis <[hidden email]> wrote:
Im having some trouble using gnomevfssrc and ftp, what troubles me is the error, a simple Could not open would make me understand that i did something wrong or something is wrong with the server.... but this error msg "Could not close"... i simply cant find anything about it, I'm not quite sure if this is something wrong on the ftp server i am using here or if it is a problem with gnomevfs or gstreamer.

The test is simple:

gst-launch gnomevfssrc location="ftp://user:[hidden email]:/myfile.wav" ! decodebin ! pulsesink

The output is:
(gst-launch-0.10:2735): GLib-WARNING **: g_set_prgname() called multiple times
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = audio/x-wav
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:sink: caps = audio/x-wav
ERROR: from element /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0: Could not close resource.
Additional debug info:
gstgnomevfssrc.c(889): gst_gnome_vfs_src_stop (): /GstPipeline:pipeline0/GstGnomeVFSSrc:gnomevfssrc0:
Could not close vfs handle: Operation cancelled
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:src: caps = NULL
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0.GstPad:sink: caps = NULL
/GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind.GstPad:src: caps = NULL
Freeing pipeline ...

Even the wav file header is being read, but on the prerolling this odd error happens. The same url that generates this error works just fine on wget (the file gets downloaded and i can hear it perfectly).

can someone help me? I'm not very used to ftp...maybe I'm missing something.

best regards,
Katcipis




------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

log.txt (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Could not close resource error when using gnomevfssrc with ftp

Tim-Philipp Müller-2
In reply to this post by Tiago Katcipis
On Mon, 2010-04-19 at 22:35 -0300, Tiago Katcipis wrote:

> using a public ftp i run this:
> gst-launch -v gnomevfssrc
> location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 !
> queue ! decodebin ! fakesink
>
> and it works ok, the ftp is really slow...it takes a good time before
> it starts to download and decode....but works
>
> even if i try:
> gst-launch -v gnomevfssrc
> location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 !
> queue ! decodebin ! alsasink
>
> i can hear the music (it takes a while to go from paused to playing,
> something like 20-30 seconds....but if you wait it wil happen).
>
> But if i take the queue element out:
> gst-launch -v gnomevfssrc
> location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 !
> decodebin ! fakesink
>
> the pipe stays blocked for ever (on both cases)... is this behavior
> expected? have anyone faced something like that? is a good policy to
> always put a queue after a gnomevfssrc?

If there's no queue between the source and the decoder/parser, then
gnomevfssrc may be activated in pull mode if gnomevfssrc thinks it can
seek in the resource it opened. I don't think this ever worked
particularly well. "ftp" should probably be in the blacklist of
protocols that shouldn't operate in pull mode, like http is already.

But in any case, you should really use giosrc instead. gnomevfs and
hence gnomevfssrc are deprecated.

Cheers
 -Tim



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Could not close resource error when using gnomevfssrc with ftp

Tiago Katcipis


On Tue, Apr 20, 2010 at 6:54 AM, Tim-Philipp Müller <[hidden email]> wrote:
On Mon, 2010-04-19 at 22:35 -0300, Tiago Katcipis wrote:

> using a public ftp i run this:
> gst-launch -v gnomevfssrc
> location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 !
> queue ! decodebin ! fakesink
>
> and it works ok, the ftp is really slow...it takes a good time before
> it starts to download and decode....but works
>
> even if i try:
> gst-launch -v gnomevfssrc
> location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 !
> queue ! decodebin ! alsasink
>
> i can hear the music (it takes a while to go from paused to playing,
> something like 20-30 seconds....but if you wait it wil happen).
>
> But if i take the queue element out:
> gst-launch -v gnomevfssrc
> location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 !
> decodebin ! fakesink
>
> the pipe stays blocked for ever (on both cases)... is this behavior
> expected? have anyone faced something like that? is a good policy to
> always put a queue after a gnomevfssrc?

If there's no queue between the source and the decoder/parser, then
gnomevfssrc may be activated in pull mode if gnomevfssrc thinks it can
seek in the resource it opened. I don't think this ever worked
particularly well. "ftp" should probably be in the blacklist of
protocols that shouldn't operate in pull mode, like http is already.

now it makes sense, thanks for the help Tim. I was thinking on something related to that, put i didn't realized the pull mode thing.
 

But in any case, you should really use giosrc instead. gnomevfs and
hence gnomevfssrc are deprecated.

we are trying, but we had some issues installing gio support on our development machines (i remember that was something about the daemons, it simply didn't worked), and gnomevfs support was quite easy to install and almost all the time it works :-), but i had lost so much time with gnomevfs that now i see why we really should put some effort on moving to GIO.
 

Cheers
 -Tim

Best regards,
Katcipis
 



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Could not close resource error when using gnomevfssrc with ftp

Kulecz, Walter (JSC-SK)[WYLE INTEG. SCI. & ENG.]
In reply to this post by Tim-Philipp Müller-2
What is the proper source to use for a "netcam" that produces an MJPEG stream?

http://x.y.z.n/video.cgi delivers a MJPEG image stream.

This works in Firefox with NoScript blocking x.y.z.n by default, so its not
using any client side code in the browser.


I've tried the following:

gst-launch giosrc location=http://192.168.1.100/video.cgi ! xvimagesink

Which gives:

(gst-launch-0.10:3359): GLib-WARNING **: g_set_prgname() called multiple times
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 227460 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...


AND:
gst-launch playbin2 uri=http://192.168.1.100/video.cgi ! queue ! jpegdec ! xvimagesink

Which gives:

(gst-launch-0.10:3375): GLib-WARNING **: g_set_prgname() called multiple times
WARNING: erroneous pipeline: could not link playbin20 to queue0
Ubuntu910:~/gst-learn$ gst-launch playbin2 uri=http://192.168.1.100/video.cgi ! xvimagesink
(gst-launch-0.10:3395): GLib-WARNING **: g_set_prgname() called multiple times
WARNING: erroneous pipeline: could not link playbin20 to xvimagesink0



Ubuntu 9.10 uses gstreamer-0.10.25.
This is a low priority for me, but if I knew it worked it could be useful for me as
a video source to experiment with gstreamer on Windows XP.

________________________________________
From: Tim-Philipp Müller [[hidden email]]
Sent: Tuesday, April 20, 2010 4:54 AM
To: [hidden email]
Subject: Re: [gst-devel] Could not close resource error when using gnomevfssrc with ftp
----------------- stuff deleted ------------------------------------------

> But if i take the queue element out:
> gst-launch -v gnomevfssrc
> location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 !
> decodebin ! fakesink
>
> the pipe stays blocked for ever (on both cases)... is this behavior
> expected? have anyone faced something like that? is a good policy to
> always put a queue after a gnomevfssrc?

If there's no queue between the source and the decoder/parser, then
gnomevfssrc may be activated in pull mode if gnomevfssrc thinks it can
seek in the resource it opened. I don't think this ever worked
particularly well. "ftp" should probably be in the blacklist of
protocols that shouldn't operate in pull mode, like http is already.

But in any case, you should really use giosrc instead. gnomevfs and
hence gnomevfssrc are deprecated.

Cheers
 -Tim
------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: source for http mjpeg streams (was: Could not close resource error when using gnomevfssrc with ftp)

Tim-Philipp Müller-2
On Wed, 2010-04-21 at 14:31 -0500, Kulecz, Walter (JSC-SK)[WYLE INTEG.
SCI. & ENG.] wrote:

> What is the proper source to use for a "netcam" that produces an MJPEG stream?

Any source that supports the http:// protocol. souphttpsrc is currently
our prefered http source.

Also, please don't hijack other threads - start your own thread for new
question.


> gst-launch giosrc location=http://192.168.1.100/video.cgi ! xvimagesink

The camera delivers encoded video data, I don't know why you think you
can pipe it into xvimagesink like that. The pipeline should probably
error out though.


> gst-launch playbin2 uri=http://192.168.1.100/video.cgi ! queue ! jpegdec ! xvimagesink
>
> Which gives:
>
> (gst-launch-0.10:3375): GLib-WARNING **: g_set_prgname() called multiple times
> WARNING: erroneous pipeline: could not link playbin20 to queue0
> Ubuntu910:~/gst-learn$ gst-launch playbin2 uri=http://192.168.1.100/video.cgi ! xvimagesink
> (gst-launch-0.10:3395): GLib-WARNING **: g_set_prgname() called multiple times
> WARNING: erroneous pipeline: could not link playbin20 to xvimagesink0

Well, this pipeline is just wrong. You can't link playbin2 to anything
(as the error message says). Maybe you meant to use uridecodebin
instead.


> Ubuntu 9.10 uses gstreamer-0.10.25.
> This is a low priority for me, but if I knew it worked it could be useful for me as
> a video source to experiment with gstreamer on Windows XP.

 gst-launch-0.10 playbin2 uri=http://1.2.3.4/foo.cgi 

should work.

Cheers
 -Tim



------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: source for http mjpeg streams (was: Could not close resource error when using gnomevfssrc with ftp)

Kulecz, Walter (JSC-SK)[WYLE INTEG. SCI. & ENG.]
Sorry, I thought it was germaine because I was playing with giosrc element you mentioned
and was getting the same

GLib-WARNING **: g_set_prgname() called multiple times

error messages.


Thanks for a correct answer

gst-launch souphttpsrc location=http://x.y.z.n/video.cgi ! jpegdec ! xvimagesink

Works very well.


But

gst-launch playbin2 uri=http://x.y.z.n/video.cgi 

Throws the GLib-WARNING **: g_set_prgname() called multiple times error
and hangs after a lot of buffering at the setting pipeline to PLAYING stage.


________________________________________
From: Tim-Philipp Müller [[hidden email]]
Sent: Wednesday, April 21, 2010 2:53 PM
To: [hidden email]
Subject: Re: [gst-devel] source for http mjpeg streams (was: Could not close resource error when using gnomevfssrc with ftp)

On Wed, 2010-04-21 at 14:31 -0500, Kulecz, Walter (JSC-SK)[WYLE INTEG.
SCI. & ENG.] wrote:

> What is the proper source to use for a "netcam" that produces an MJPEG stream?

Any source that supports the http:// protocol. souphttpsrc is currently
our prefered http source.

Also, please don't hijack other threads - start your own thread for new
question.


> gst-launch giosrc location=http://192.168.1.100/video.cgi ! xvimagesink

The camera delivers encoded video data, I don't know why you think you
can pipe it into xvimagesink like that. The pipeline should probably
error out though.


> gst-launch playbin2 uri=http://192.168.1.100/video.cgi ! queue ! jpegdec ! xvimagesink
>
> Which gives:
>
> (gst-launch-0.10:3375): GLib-WARNING **: g_set_prgname() called multiple times
> WARNING: erroneous pipeline: could not link playbin20 to queue0
> Ubuntu910:~/gst-learn$ gst-launch playbin2 uri=http://192.168.1.100/video.cgi ! xvimagesink
> (gst-launch-0.10:3395): GLib-WARNING **: g_set_prgname() called multiple times
> WARNING: erroneous pipeline: could not link playbin20 to xvimagesink0

Well, this pipeline is just wrong. You can't link playbin2 to anything
(as the error message says). Maybe you meant to use uridecodebin
instead.


> Ubuntu 9.10 uses gstreamer-0.10.25.
> This is a low priority for me, but if I knew it worked it could be useful for me as
> a video source to experiment with gstreamer on Windows XP.

 gst-launch-0.10 playbin2 uri=http://1.2.3.4/foo.cgi

should work.

Cheers
 -Tim



------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: source for http mjpeg streams (was: Could not close resource error when using gnomevfssrc with ftp)

Kulecz, Walter (JSC-SK)[WYLE INTEG. SCI. & ENG.]
I tried using this pipeline on gstreamer for windows XP, with what seemed to be the correct modifications
but it didn't work.

gst-launch-0.10 souphttpsrc location=http://x.y.z.n/video.cgi ! jpegdec  ! dshowvideosink

gives:
could not link jpegdec0 to dshowvideosink0

Adding ffmpegcolorspace between the jpegdec and dshowvideosink makes it look like its going to work
as pipeline goes to PAUSED but PREROLLING fails with libsoup status code 4.

I have the GStreamerWinBuild-0.10.5.1 installed and working with msys, at least I could compaile the HelloWorld gstreamer sample program and play back an ogg audio file.   I couldn't get the beta to work, but I see there is a 10.6 RC01 WinBuilds, but I don't have time to try installing it right now.

Am I doing something wrong, or is WinBuild-10.5.1 broke for this?


________________________________________
From: Kulecz, Walter (JSC-SK)[WYLE INTEG. SCI. & ENG.] [[hidden email]]
Sent: Wednesday, April 21, 2010 3:19 PM
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] source for http mjpeg streams (was: Could not close resource error when using gnomevfssrc with ftp)

Thanks for a correct answer

gst-launch souphttpsrc location=http://x.y.z.n/video.cgi ! jpegdec ! xvimagesink

Works very well.
------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Could not close resource error when using gnomevfssrc with ftp

Kapil Agrawal
In reply to this post by Kulecz, Walter (JSC-SK)[WYLE INTEG. SCI. & ENG.]
try using playbin2, or
gst-launch souphttpsrc ! decodebin ! xvimagesink  ?

best luck
-kapil

On Thu, Apr 22, 2010 at 1:01 AM, Kulecz, Walter (JSC-SK)[WYLE INTEG. SCI. & ENG.] <[hidden email]> wrote:
What is the proper source to use for a "netcam" that produces an MJPEG stream?

http://x.y.z.n/video.cgi delivers a MJPEG image stream.

This works in Firefox with NoScript blocking x.y.z.n by default, so its not
using any client side code in the browser.


I've tried the following:

gst-launch giosrc location=http://192.168.1.100/video.cgi ! xvimagesink

Which gives:

(gst-launch-0.10:3359): GLib-WARNING **: g_set_prgname() called multiple times
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 227460 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...


AND:
gst-launch playbin2 uri=http://192.168.1.100/video.cgi ! queue ! jpegdec ! xvimagesink

Which gives:

(gst-launch-0.10:3375): GLib-WARNING **: g_set_prgname() called multiple times
WARNING: erroneous pipeline: could not link playbin20 to queue0
Ubuntu910:~/gst-learn$ gst-launch playbin2 uri=http://192.168.1.100/video.cgi ! xvimagesink
(gst-launch-0.10:3395): GLib-WARNING **: g_set_prgname() called multiple times
WARNING: erroneous pipeline: could not link playbin20 to xvimagesink0



Ubuntu 9.10 uses gstreamer-0.10.25.
This is a low priority for me, but if I knew it worked it could be useful for me as
a video source to experiment with gstreamer on Windows XP.

________________________________________
From: Tim-Philipp Müller [[hidden email]]
Sent: Tuesday, April 20, 2010 4:54 AM
To: [hidden email]
Subject: Re: [gst-devel] Could not close resource error when using gnomevfssrc with ftp
----------------- stuff deleted ------------------------------------------

> But if i take the queue element out:
> gst-launch -v gnomevfssrc
> location=ftp://194.44.214.3/pub/music/Collection/ArtofNoise.mp3 !
> decodebin ! fakesink
>
> the pipe stays blocked for ever (on both cases)... is this behavior
> expected? have anyone faced something like that? is a good policy to
> always put a queue after a gnomevfssrc?

If there's no queue between the source and the decoder/parser, then
gnomevfssrc may be activated in pull mode if gnomevfssrc thinks it can
seek in the resource it opened. I don't think this ever worked
particularly well. "ftp" should probably be in the blacklist of
protocols that shouldn't operate in pull mode, like http is already.

But in any case, you should really use giosrc instead. gnomevfs and
hence gnomevfssrc are deprecated.

Cheers
 -Tim
------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel



--
http://www.linkedin.com/in/kapilagrawal

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: source for http mjpeg streams (was: Could not close resource error when using gnomevfssrc with ftp)

Wes Miller
Administrator
In reply to this post by Kulecz, Walter (JSC-SK)[WYLE INTEG. SCI. & ENG.]
> I tried using this pipeline on gstreamer for windows XP, with what seemed to be the correct
> modifications but it didn't work.

Try adding an ffmpegcolorspace element to your pipeline between jpegdec and dshowvideosink.  This adjusts the colors in the stream coming out of jpegdec.

You may also want a multipartdemux after souphttpsrc to strip out any audio component from your camera.


gst-launch-0.10 souphttpsrc location=http://x.y.z.n/video.cgi ! multipartdemux ! jpegdec ! ffmpegcolorspace ! dshowvideosink



------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: source for http mjpeg streams (was: Could not close resource error when using gnomevfssrc with ftp)

Kulecz, Walter (JSC-SK)[WYLE INTEG. SCI. & ENG.]
Thanks, I though I mentioned that I had tried inserting ffmpegcolorspace between the jpegdec and dshowvideosink, but it didn't work either.

Adding the multipartdemux gets me a nice clean failure: "Could not demultiplex stream" "Boundry not found in multipart header".

This happens right after PREROLLING is displayed.

As I said,
souphttpsrc location=http://x.y.z.n/video.cgi ! jpegdec ! xvimagesink
works wonderfully on Ubuntu (tried it on 8.04, 9.10 & 10.04Beta)

Perhaps the WinBuilds-10.5.1 are just not usable for this.


I've also tried a "Creative WebCam Pro" with:

gst-launch-0.10 dshowvideosrc device-name="Creative WebCam Pro" ! jpegdec ! ffmpegcolorspace ! dshowvideosink

But this locks up the msys terminal after opening a window that displays/grabs the pixels underneath and is movable but doesn't close until I kill the msys terminal.

I see there is a WinBuilds10.6RC1 but I can't seem to download them -- starts, but then never seems to get any data.



________________________________________
From: Wesley J. Miller [[hidden email]]
Sent: Thursday, April 22, 2010 8:59 AM
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] source for http mjpeg streams (was: Could not close resource error when using gnomevfssrc with ftp)

> I tried using this pipeline on gstreamer for windows XP, with what seemed to be the correct
> modifications but it didn't work.

Try adding an ffmpegcolorspace element to your pipeline between jpegdec and dshowvideosink.  This adjusts the colors in the stream coming out of jpegdec.

You may also want a multipartdemux after souphttpsrc to strip out any audio component from your camera.


gst-launch-0.10 souphttpsrc location=http://x.y.z.n/video.cgi ! multipartdemux ! jpegdec ! ffmpegcolorspace ! dshowvideosink
------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel