Naturally i did a minor screwup... in the patch i forgot to add 
#include "file.h"
to packagedispatcher.C

I hope this makes a patch complete and acceptable?

bye
andraz


On sre, 2006-05-31 at 14:17 +0200, Andraz Tori wrote:
> On tor, 2006-05-30 at 23:09 -0700, Heroine Virtual Ltd. wrote:
> > Personally think instead of adding new PackagingEngines specifically for 
> > OGG into
> > packagedispatcher.C, the OGG specific packaging should somehow be done in
> > FileOGG and PackageDispatcher should be calling File functions.
> 
> You are right, that was ugly... I've rethought the design and am
> attaching the new one. 
> 
> I've put specific OGG packeting engine inside fileogg.C, and general one
> inside packagingengine.C, and use of packeting engine is decided in File
> class ... which makes it completely transparent to the
> PackageDispatcher.
> 
> This adds the files packagingengine.C and .h which implement default
> packaging engine.
> 
> Other packaging engines can now be written without touching
> PackageDispatcher... All what is needed is specific implementation of
> PackagingEngine class and adding a conditional to the file.C
> new_packaging_engine() function.
> 
> > A lot of the OGG specific code in packagedispatcher.C is dependant on 
> > the fact that FileOGG
> > can't do multiplexing yet.  Instead of supporting multiplexing in 
> > FileOGG, it's encoding the
> > audio first and then direct copying audio using OGG specific methods in 
> > packagedispatcher.C.
> 
> I've now put the PackagingEngineOGG code into fileogg.C since it
> obviously does nto belong to where it was...
> 
> Actually FileOGG can do multiplexing and PackagingEngineOGG uses all the
> multiplexing functions FileOGG offers.
> But there has to be manual handling of packets to fix them up so
> different theora streams can form one single stream without reencoding -
> basically what needs to be done is fixing the references to
> keyframes ... when this is done, packets are directly fed to FileOGG
> muxer which muxes them in flush_ogg().
> 
> This manual fixing cannot be avoided due to theora desing...
> 
> 
> >  > No more you are left with multiple files that you have to mux yourself.
> > 
> > If that's all you want, renderfarm should just ignore the audio setting
> >  and render the video normally. If audio is checked, the renderfarm
> >  should go back and render audio locally into the final output with
> >  direct copied video chunks.
> 
> Well what I want is solution that works "out of the box", that means
> that user should just not care how black magick of packet distribution
> and muxing is done or need to do multiple actions to get the final file.
> What this solution offers to him is that he simply demands just one
> rendering job, which is done in distributed way and only one single file
> is presented to the user at the end.
> 
> 
> bye
> andraz


_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to