On Tue, Jan 28, 2014 at 4:29 PM, Vittorio Giovara
<[email protected]> wrote:
> On Tue, Jan 28, 2014 at 3:29 PM, Vittorio Giovara
> <[email protected]> wrote:
>>
>> Technically frames are interlaced, but they should not be treated as
>> such because content is progressive, so it's quite difficult to
>> signal. I'd be tempted to mark them as progressive for simplicity, but
>> that wouldn't help applications.
>>
>> Maybe a new field could be introduced (like the one you propose) which
>> is *not* bitmask-compatible with AV_FRAME_INTERLACED; I'm not sure
>> it's worth/necessary to also keep the field information of the current
>> frame (tff/bff).
>
> Actually, upon further study on IRC, what lavc decoders provide is
> complete frames, not fields, and psf frames should be treated as
> progressive. So I think the best solution for this is to add a new
> value, like AV_FRAME_PROGRESSIVE_PSF which is bitmask-compatible with
> AV_FRAME_PROGRESSIVE and convert the various == checks in & checks.
>
> However right now no lavc decoder provides this additional
> information, and I'd avoid adding unused values to the API. So I'll
> just change the checks for forward compatibility and add the flag
> if/when a patch implementing that is complete.
>
> Would something like that be okay?

sound reasonable to me (as far as I understand it).
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to