Re: [Debconf-video] Fwd: Flumotion videomixer
On Mon, Mar 12, 2007 at 01:03:09AM +0100, Holger Levsen wrote:
> Hi,
>
> On Sunday 11 March 2007 23:58, you wrote:
> > 1) It only allows an image to be overlayed, not a 2nd video stream
>
> Actually it does. The example is an image, but you can overlay streams.
>
> But anyway, "show us the code" (this includes us all), otherwise we'll end up
> using the same setup as at debconf6 ;-)
>
> > 2) (assuming your talking about 1 stream for slides and 1 live video
> > stream) For live streaming the mixing should be done at the receiving end,
> > not at the sending end. This allows for displaying the streams in seperate
> > windows, overlayed, or any other way the user would want.
>
> This requires mixers at the users end, which not be there. so, as i can see
> the value in this, I'd say this (streaming two streams instead of one) is
> optional optional :)
>
There is very little value in overlaying the slides on the live video
stream at the server side though. The reason for having a slides and a
video stream is better bandwidth use by using different compression
schemes for either. Slides are fairly static (4 or 5 per minute
maximum), generally CG and preferably displayed at high quality because
they contain vital information to be able to follow the talk. Video is
more dynamic, mostly not CG, image quality is less important here. As to
efficiently use the streaming bandwidth and meet the quality goals, we
need to encode both types of data differently. Overlaying at the server
side implies encoding both types of data in the same way. This won't
result in a better stream quality. So we can just as well not bother
with overlaying in that case.
> > 3) for DVD creation overlaying does not need to be realtime, so we can
> > store both streams and overlay them afterwarts when creating the DVD.
>
> Afterwards means post-processing. We should shape our processes so that we
> dont have post-processing. After DebConf we need to work (or go on vacation,
> or both), but not more work.
>
We already have postprocessing for DVD creation. As long as the
postprocessing is automated, this doesn't seem to pose a problem.
Cheers,
Peter (p2)
--
Goa is a state of mind
Reply to: