[gst-devel] Transcoding with gstreamer

[David Given]

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 
code?

[...]
> 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 
stalls.

(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 
tell me...)

-- 
+- 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