[FFmpeg-devel] [PATCH 1/3] avcodec: add an AVCodecContext field to signal types of packet, frame, and coded stream side data to export

[James Almer]

On 2/3/2020 10:23 PM, Carl Eugen Hoyos wrote:
> Am Di., 4. Feb. 2020 um 02:20 Uhr schrieb James Almer <jamrial at gmail.com>:
>>
>> On 2/3/2020 10:03 PM, Carl Eugen Hoyos wrote:
>>> Am So., 2. Feb. 2020 um 23:31 Uhr schrieb James Almer <jamrial at gmail.com>:
>>>
>>>> -{"export_mvs", "export motion vectors through frame side data", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_EXPORT_MVS}, INT_MIN, INT_MAX, V|D, "flags2"},
>>>> +{"export_mvs", "export motion vectors through frame side data (Deprecated, see export_side_data)", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_EXPORT_MVS}, INT_MIN, INT_MAX, V|D, "flags2"},
>>>
>>> Is there a technical reason why this functionality has to be updated
>>> every few years?
> 
>> I was suggested to move the flag from flags2 to the new field, as it was
>> a better fit for it.
> 
> In my understanding (not being a native speaker) this sentence implies
> that there (already) is another "field" that is more suitable for the
> feature, I believe this is not the case.

What i tried to say is that the new field i'm introducing,
export_side_data, is a more adequate place for the export_mvs
flag/functionality than the generic flags2 field.

> 
>> It doesn't "have" to, but i guess based on your concern that this flag
>> had the bad luck of having been moved around before?
> 
> Correct.
> 
> In addition, I wonder how this - relatively simple - patch can block another
> one. I suggest the blocked patch gets committed first, then we discuss if
> this repeated movement of options makes any sense.

Sure, i can do that.

> 
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>