[Ffmpeg-devel] spatial scalability in ffmpeg

Luxman Suthanthirarajah luxman.03
Tue Mar 6 22:13:48 CET 2007


Hi

On 2/26/07, Michael Niedermayer <michaelni at gmx.at> wrote:
>
> Hi
>
> On Mon, Feb 26, 2007 at 06:20:17PM -0500, Luxman Suthanthirarajah wrote:
> > Hi:
> >
> > I am new to the mailing list and ffmpeg. As a final year project at
> Carleton
> > University I have undertaken the task of coding in the ffmpeg
> application on
> > Linux OS.
> >
> > I wish to implement an algorithm of spatial scalability in ffmpeg and
> test
> > its effectiveness when using Wavelet transform. However, I have found
> that
> > ffmpeg has a "spatial scalability" variable in structure snowContext and
>
> > many compose/decompose functions in the snow.c file. I am unsure how the
> > variable is used to produce a scalable bitstream. I put some "av_log"
> > statements in the bitstream.c file but they are not printing. Also, I am
>
> > unaware if there are any configuration setting that need to be selected
> to
> > turn the existing scalability functionality on. I would appreciate any
> > direction on this subject. Thank you.
>
> well if you search for spatial_scalability in the file you will notice
> that
> the variable is always 0 and just stored and read but otherwise unused
> also you can look at /doc/snow.txt which also says its 0
> so no there is no spatial scalability support in snow currently
>
> the reason why your av_log doesnt print is likely due to the debug level
> used in it and the verbosity selected by -v, you should in general look
> at the source code of the functions which doent behave the way you expect
> them to ...
>
> if you want to add spatial scalability support similar to how -lowres
> works in mpeg1/mpeg2/mpeg4 to snow that is surely welcome and should be
> relatively easy in principle one possible encoder side change would be
> * add pointers (to the end of each frame!) which point to the begin of the
>
>   2 chroma planes and reset the ac coder after each plane, that way you
>   should be able to skip decoding of the high frequency coefficients
> during
>   decoding
>
> besides that you simply have to make the decoder work with smaller blocks
> in motion compensation use a smaller frame buffer and skip the high
> frequency
> decoding
>
> another interrestig feature is to have a full sized frame buffer but skip
> the high frequency coeffs if there is not enough cpu time available to
> decode in realtime otherwise
>
> PS: improvements to doc/snow.txt are also very welcome
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Republics decline into democracies and democracies degenerate into
> despotisms. -- Aristotle
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
> Thank you Michael, your suggestions were very helpful. The objective of
the project will be to send video over a wireless connection (therefore,
having limited bandwidth). Hence, I plan to give the encoder the flexibility
of sending whichever quality. I will do this by allowing for an option in
the terminal command for the number of iterations of DWT on the video and a
quality index (how many levels/layers will be sent). Once those parameters
are received from the user, the way in which the I and P type frames is
modified, so that only the selected layers are included.

I will be using the pointers and smaller blocks in the decoder, however I
assume there is no ac coder when using DWT encoding and I am not sure how
the -lowres works.

Just wanted to give you the heads up, in case you had any comments.

Thank you,
Luxman




More information about the ffmpeg-devel mailing list