On Wed, Dec 18, 2013 at 3:23 PM, Vittorio Giovara
<[email protected]> wrote:
> On Wed, Dec 18, 2013 at 1:25 PM, Anton Khirnov <[email protected]> wrote:
>>
>>> +        } else {
>>> +            av_image_copy_plane(dst->data[plane], dst->linesize[plane],
>>> +                                leftp, 
>>> s->input_views[LEFT]->linesize[plane],
>>> +                                length, lines);
>>> +            av_image_copy_plane(dst->data[plane] + length, 
>>> dst->linesize[plane],
>>> +                                rightp, 
>>> s->input_views[RIGHT]->linesize[plane],
>>> +                                length, lines);
>>> +        }
>>
>> Why not av_image_copy()? It'd be simpler and would make the code easier to
>> generalize e.g. to higher bitdepths.
>
> I don't know about higher bitdepths, but I used av_image_copy_plane()
> because I already had all data for it (like image pitch, and correct
> plane height) and because av_image_copy_plane() doesn't copy all the
> padding which seemed a waste.
>

Well the above reasons are not so strong, but one more reason to use
_copy_plane is that i need to be able to modify the linesize (for top
and bottom) and the starting address of the frame (for sidebyside).
To use av_image_copy() I'd have to copy the original dst_data and
dst_linesizes and modify them according to the format (which would be
the main reason of using av_image_copy in the first place).

>>> +    if (s->format == AV_STEREO3D_FRAMESEQUENCE) {
>>> +        if (s->double_pts == AV_NOPTS_VALUE)
>>> +           s->double_pts = s->input_views[LEFT]->pts;
>>> +
>>> +        for (i = 0; i < 2; i++) {
>>> +            dst = av_frame_clone(s->input_views[i]);
>>
>> No need for clone, just use the input frame directly.
>>
>
> I'm changing pts and adding side data though, so I'd have to add
> needs_writable on the input pad.
> However I'd only need that for this temporal packing so I'd prefer not
> to enable it for the other modes.
>

Actually you can write on the input frame (just not the data buffers),
but after trying this out, I noticed that it interferes with the frame
management: ff_filter_frame() frees the input frame, but the filter
doesn't load the next frame until input_views is  freed and NULL'd. If
I try to free the input frames after ff_filter_frame(), set them to
NULL or just forget about those I get a stack corruption.

Vittorio
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to