GNOME Bugzilla – Bug 584820
Multifdsink is not working on most input sources
Last modified: 2009-06-16 08:58:58 UTC
Please describe the problem: When using the multifdsink plugin, depending on the pipeline's source feed, the pipeline freezes and no data is being written to the file descriptors. Sources known to work: videotestsrc and v4l2src Sources known _not_ to work: filesrc, souphttpsrc and rtspsrc Steps to reproduce: 1. Create a pipeline with multifdsink and add a network socket to the multifdsink 2. Observe that with videotestsrc and v4l2src the streaming works fine 3. Change source to filesrc and observe that the pipeline halts Actual results: Expected results: I can't see any good reasons for the multifdsink not to handle various kinds of input. I've tried to add ffmpegcolorspace and queues, but with no luck Does this happen every time? Yes Other information: I've written a very small http server demo which illustrates the problem. I'll attach it to this bug report.
Created attachment 135937 [details] Tiny http server using multifdsink This is a quick demo program I hacked together that illustrates the problem. - http_server 9000 test will start streaming videotestsrc to port 9000 - http_server 9000 file video_file.ogg will read that video file with filesrc and stream it on port 9000. But it fails.
decodebin has dynamic pads and cannot be linked like that, you need to wait for the pad-added signal before the pads become available. Also mp4 is not a streamable format, you can't share it with clients nor can you encode in it while streaming (it rewrites the headers on EOS) So what exactly is the problem here? What did you expect to happen?
Hi, I wanted to write a HTTP streaming server that could read data from a single HTTP source and distribute it to multiple clients. I can se my demo program was not a good illustration as it didn't use neither dynamic pads or the mpegtsmux (which I used in my real program). After a lot of frustration I got it to work though: I needed to use the mpegtsmux, dynamic pads on demuxer _and_ a ffmpegcolorspace converter between decoder and encoder (the decoded video data was not compatible with x264enc input). That last stepped fooled me to believe something was wrong with the multifdsink. Is there by the way a list of formats (containers) that are streamable in gstreamer? Anyway, this is not a bug in gstreamer.