Lynne: > 12 Sept 2021, 13:31 by d...@lynne.ee: > >> 12 Sept 2021, 05:21 by softwo...@hotmail.com: >> >>> This is the root commit for adding subtitle filtering capabilities. >>> Adding the media type property to AVFrame replaces the previous >>> way of distinction which was based on checking width and height >>> to determine whether a frame is audio or video. >>> >>> Signed-off-by: softworkz <softwo...@hotmail.com> >>> >> >> Why do you need a new allocation function av_frame_get_buffer2 >> when it has the same syntax as av_frame_get_buffer? >> Also, could you please drop all but one of the filter patches >> when sending new versions? You're overspamming the ML >> and it's hard to keep up. >> Finally, why not combine the 2 subtitle overlay filters into one? >> There's no need for explicitness between text and bitmap subs. >> > > Just read why (the media type). Says a lot about the ML overload. > > Could the media type be set as unknown during the deprecation > period by default by the old alloc function for audio and video? > Subtitle allocations can set it to _SUBTITLES. That way, you can > still keep compatibility, as the old users detect AVFrame type based > on the 'format' field, without adding a new alloc function.
The decode API should (when it is ported; haven't looked whether this already happens in this commit) ensure that AVFrame.type is set according to the data contained in the frame. If a user unaware of the decodes (say) video and then wants to utilize said AVFrame for audio, he may do so by resetting the fields corresponding to video and setting the audio related fields; you do not need to call av_frame_unref on it (say you want to keep the metadata and the timing related stuff, so you reset manually). If he then gives this frame to av_frame_get_buffer, it will be inconsistent, i.e. av_frame_get_buffer should error out. And then the user app will be broken. (I of course admit that lots of users will not be affected by this, as they always reset their frames with av_frame_unref. But we have to think of the odd cases, too.) - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
