[mythtv] [PATCH] Add streaming output to transcoder

[Geoffrey Hausheer]

On 15 Aug 2003 09:35:43 -0700, "Chris Petersen lists-at-forevermore.net
|mythtv/1.0-Allow|" <o8f8hesx3k0t at sneakemail.com> said:
> > A few random comments:
> > 1) This patch differs from the previous prototype in that mythtrancsode
> > will create/delete the fifos.  If they are already present, mythtranscode
> > will fail.  This seems to ensure the initial sync happens correctly.
> 
> Does this mean that it wouldn't work (if you changed the code so it
> wouldn't break if they're already present) if it tried to write an an
> existing fifo?  I ask because svcd encoding is a two-stage process -
> first video, then audio.  And I don't have enough RAM for mythtranscode
> to hold onto a "raw" audio buffer while I encode video for an hour or
> four.
Correct, it won't work.  first off, having mythtranscode create its own
fifo makes it easier to gaurantee sync. For your problem, there are two
solutions: (1) run mythtranscoder twice, once for audio and once for
video (and add switches to mythtranscode to allow this).  Or better (b)
add a throttling aspect, so that you can do cat audfifo > file.  I like,
option (b), and in your case, it means you could do someting like:
window 1:
mythtranscode ... --sync
window 2:
encode_video vidout > out.m2v
window 3:
encode_audio audout > out.mp2

I.e. you can now process audio and video by two different programs and
let the transcoder sync the data-rates for you such that huge amounts of
ram aren't needed.

Would this work for you, or do you really need to encode the video first,
and then the audio second?  In that case, you could either cat audout >
file (usnig the proposed --sync switch), or I need to request only a
single (audio or video) stream be sent out.

As I said, I like the concept of a '--sync' switch, though I'm not sure
how to implement it yet, but i'll go either way.  I don't think havng
mythtranscode write to a file is useful though, and I'd prefer not to go
that way.

.Geoff