[XviD-devel] stereo video streams

Luca Piccarreta piccarre at elet.polimi.it
Wed Mar 23 10:20:32 CET 2005


For sure safer but not much more efficient than coding
sequences separately :)
Luca.

----- Original Message ----- 
From: "Dirk Knop" <dknop at stud.uni-goettingen.de>
To: <xvid-devel at xvid.org>
Sent: Wednesday, March 23, 2005 10:08 AM
Subject: Re: [XviD-devel] stereo video streams


> Hi,
>
> wouldn't it be safer and equally efficient to just vertically stack the
> images and strip the images again after decoding? You could use any
> codec with such a solution then.
>
> Cheers
> Koepi
>
> Luca Piccarreta wrote:
>
> >You could think of rectifying images before interlacing them.
> >Rectification is a homography (projection) of both images
> >in such a way that corresponding points on both images
> >share the same y-coord.
> >(I'm assuming that you're talking about a calibrated stereo
> >camera)
> >This *might* give you some improvement in coding efficiency.
> >Luca Piccarreta.
> >
> >----- Original Message ----- 
> >From: "Christoph Lampert" <chl at math.uni-bonn.de>
> >To: <xvid-devel at xvid.org>
> >Sent: Wednesday, March 23, 2005 9:23 AM
> >Subject: Re: [XviD-devel] stereo video streams
> >
> >
> >
> >
> >>Hi,
> >>
> >>
> >>sage weil wrote:
> >>
> >>
> >>
> >>>Hi,
> >>>
> >>>I'm looking for a way to efficiently encode a pair of video streams
> >>>from a stereo camera.  A few obvious possibilities present themselves
> >>>but are not entirely ideal:
> >>>
> >>>- Put frames side by side and encode as usual.  Macroblock searches
> >>>won't find similar blocks from the other camera with a localized
> >>>search...
> >>>
> >>>
> >>This will not make a significant difference to encoding both
> >>independently, you are right.
> >>
> >>
> >>
> >>>- Interleave left and right frames.  If xvid searches more than one
> >>>frame back then this would work reasonably well, but I'm pretty sure
> >>>it doesn't? And if it did the motion prediction would end up way off,
> >>>resulting in suboptimal performance...
> >>>
> >>>
> >>This might indeed work well with codecs that support more than 1
> >>reference frame (e.g. H.264 aka H.26L aka AVC aka MPEG4v10), but XviD is
> >>MPEG4v2 and there it's not possible. I would also strongly advise
> >>against hacking the format to support this, because it would need quite
> >>some new syntax elements and would be completely incompatible, causing
> >>major confusion.
> >>
> >>
> >>
> >>>Does anybody have any thoughts about what might be necessary in terms
> >>>of code changes to make this work well?
> >>>
> >>>
> >>My idea was to interleave left and right row by row and test encoding
> >>with or without interlaced DCT. You can still access them independently
> >>by using a twice as high stride value, and in areas where the
> >>displacement is low, it might be beneficial to
> >>have both views as close to each other as possible.
> >>
> >>
> >>gruel
> >>
> >>_______________________________________________
> >>XviD-devel mailing list
> >>XviD-devel at xvid.org
> >>http://list.xvid.org/mailman/listinfo/xvid-devel
> >>
> >>
> >
> >_______________________________________________
> >XviD-devel mailing list
> >XviD-devel at xvid.org
> >http://list.xvid.org/mailman/listinfo/xvid-devel
> >
> >
> >
>
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel




More information about the XviD-devel mailing list