[FFmpeg-devel] Need suggestion for ROTATION

[Tilak Adhya]

On Thu, 22 Nov 2007 Michel Bardiaux wrote :
>Tilak Adhya a ?crit :
> >
> > Hi Micheal,
> >
>Please dont top-post.
>
> > Thanks for the reply.
> > Yes, I meant yuv420P. But in the ffmpeg code-base
> > it is really difficult to get the point, where to
> > add the code. We thought to add the rotation specific
> > code in the do_video_out() function of ffmpeg.c. Is it
> > a right place to add code ?
>
>The logical place would be where the re-scaler is called, maybe its
>there. Other logical places would be as a vhook (but (1) that API is
>being depercated (2) I dont know that it supports size change); and the
>replacement for vhhok now in development. Read the archives about vhook.
>
>Note that if your rotation *replaces* the rescaling, it must act as if a
>-s was specified on the output side. So your best strategy would be to
>remove the -s option on output, and see which variable that affects, and
>   remove that variable, etc... letting the compiler errors guide you.
>
>If you have to keep both -s on output and a rotation...

I am not using the rescaling. I am simply trying to rotate a frame by
degree(say). And the good news is that, I have been able to rotate the frame by 90 degree in the Y plane, but not able to do the same in the U and V plane. Actually, it is the YUV420P and I've confused about the no
of U and V. strlen(AVPicture->data[0]) represents the product of height and width but I don't get any relation for the U and V components.

Again in the rotated picture I am getting only the 80% of the picture,
I mean some portion has been truncated. Not getting any idea to proceed.

Could you please help me out...

Regards
litak
width. 


>
> > And for this rotation purpose, we need to rearrange the
> > byte sequence of data[0], then the height and width
> > will both be changed. So we need a new picture. This is
> > my idea. Is it correct ?
>
>Yes. But when using planar pixel formats, you must act on data[1] and
>data[2] as well.
>
> >
> > Can you tell me some good link such that I can make good
> > knowledge in YUVxyzP kind of stuff.
>
>No *good* link. Google and weep :-)
>
> >
> > Awaiting for your reply...
> >
> > Regards
> > litak
> >
> >
> > On Thu, 22 Nov 2007 Michel Bardiaux wrote :
> >> Tilak Adhya a ?crit :
> >>> Hi All,
> >>>
> >>> I am new to this list. I am trying to add one feature to the
> >>> ffmpeg code base regarding the rotation. FFmpeg does not have
> >>> any support for frame level rotation. My requirement is to
> >>> rotate(90, 180, 270 degrees ) a movie, before streaming.
> >>>
> >>> Now, first we thought that, we would create a new AVPicture
> >>> with the new data and linesize fields and rearrange the data[0],
> >>> data[1] and data[2] pointers for the rotated movie. But while
> >>> doing this, we faced lot of problems regarding the modification
> >>> of data and height and width fields.
> >>> So we decided to first convert this YUV format to RGB format
> >>> using img_convert() fuction and then rotate the picture in the
> >>> RGB level and then again convert it to the YUV format. But in
> >>> this procedure the main concerns are how to rotate a picture in
> >>> RGB format and how much feasible this approach is. Actually in
> >>> a 15fps movie the extra operations will be two image conversions
> >>> (YUV -> RGB and RGB -> YUV) and rotation in the RGB plane for each
> >>> frame.
> >>>
> >>> Now my question is, which procedure we will take to rotate a movie
> >>> and what is the concept of rotation in the YUV plane for a movie.
> >>> Need your suggestion in this regard...
> >>>
> >> First of all, dont use "YUV", there are too many different meanings.
> >> ITIYM yuv420p, the most common format lavc decodes to.
> >>
> >> Now, for YUV420P, you rotate the bytes in the Y plane (data[0]) just as
> >> if they were a sequence of greytone bytes. Then the same for the U and V
> >> planes, except they are 2x2 times smaller.
> >>
> >> For YUV444P, the same except the 3 planes have the same size.
> >>
> >> For YUV422P, you have a problem: U and V are averages on the line, and
> >> after rotation the lines would become columns, and the averages would
> >> have to be on different pixels. So you will have to go through YUV444P,
> >> but that is lighter than going through RGB.
> >>
> >> Short version: if you can rotate greytone, you can rotate YUVxyzP.
> >>
>
>--
>Michel Bardiaux
>R&D Director
>T +32 [0] 2 790 29 41
>F +32 [0] 2 790 29 02
>E mailto:mbardiaux at mediaxim.be
>
>Mediaxim NV/SA
>Vorstlaan 191 Boulevard du Souverain
>Brussel 1160 Bruxelles
>http://www.mediaxim.com/
>_______________________________________________
>ffmpeg-devel mailing list
>ffmpeg-devel at mplayerhq.hu
>http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel


*--
tilak