On Thu, Feb 27, 2020 at 10:41 AM Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Thu, Feb 27, 2020 at 12:35 PM Anton Khirnov <an...@khirnov.net> wrote: > > > > Quoting Hendrik Leppkes (2020-02-27 12:27:09) > > > On Thu, Feb 27, 2020 at 12:18 PM Anton Khirnov <an...@khirnov.net> > wrote: > > > > Why does it need to be within AVFrame? I am still unconvinced that > is a > > > > good idea. What do we gain from storing them in the same struct? > > > > It makes sense for audio and video, because they are similar in many > > > > important aspects (and even then there are people saying that they > > > > should be separate). Subtitles are even more different. > > > > > > > > > > You gain a unified API, which we already have now, intead of a > > > secondary API just for subtitles thats practically the same but > > > accepts different structs. > > > This makes everything a lot easier imho. You can decode whatever input > > > data into an AVFrame, you can filter your AVFrame, still without > > > needing special data paths, and only at the last step after all of > > > that do you need to possibly care when it comes to output. If you're > > > encoding again, you might not even have that. > > > > AFAIU one of the still-open questions for the subtitle redesign is what > > does it mean to decode or encode a subtitle. And one of the options is > > putting the AVPacket->"decoded subtitle" (whatever that is) and "decoded > > subtitle"->AVPacket conversions into a separate library. > > > FFmpeg really doesn't need *more* libraries. > libavio says hi joking aside, i see nothing wrong in having a bit more granular libraries, subtitle handling could be a good example usecase. -- Vittorio _______________________________________________ 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".
