[gst-devel] Transcoding with gstreamer
dg at cowlark.com
Mon Nov 29 02:59:05 CET 2004
On Saturday 27 November 2004 21:21, you wrote:
> The gst-launch parser isn't supposed to be robust really. It's a
> developer's tool, not an end user solution. If you think they're easily
> fixable, sure, submit them, but I don't thin too many of us are dying to
> make gst-launch the best tool of the world. ;).
What *is* the recommended way of constructing pipelines, then? XML files?
(gst-editor seems to be fairly unstable IME.) Building them manually out of
> OK, that's very unrelated to the above. Yes, I know why. Your muxer and
> demuxer run in the same thread, while separated by other threads in the
> middle. This will hang. It's a bad pipeline. Like I said, gst-launch is
> not an end-user solution. We don't check for all possible mistakes.
> We're a building box, and I can build lego houses that will collapse
> instantly with no problem. You see the point?
Indeed, except that I still don't know what shape the bricks are and now and
again it would be handy to have it return EBLOCKUPSIDEDOWN. (To badly
overextend a metaphor.)
As far as I understand it, then, I need a seperate thread if the data rate's
going to change. I can't run the mux and the demux in the same thread because
they won't be running in lockstep. Right? And is there any reason why you put
the mux in the main thread, rather than the demux?
...oh, and I hate to mention it, but your pipeline still doesn't work. It just
(Is any of this documented anywhere? The only reason I'm hassling people here
is because I couldn't find anything online; if I should be RTFMing, please
+- David Given --McQ-+ "Est brilgum: toui slimici
| dg at cowlark.com | In uabo tererotitant
| (dg at tao-group.com) | Brogoui sunt macresculi
+- www.cowlark.com --+ Momi rasti strugitant." --- Anonymous
More information about the gstreamer-devel