[FFmpeg-devel] Need suggestion for ROTATION

[Michel Bardiaux]

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...

> 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/