Re: [FFmpeg-devel] [PATCH v9 02/25] avutil/frame: Prepare AVFrame for subtitle handling

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Hendrik Leppkes
> Sent: Tuesday, October 25, 2022 11:38 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v9 02/25] avutil/frame: Prepare
> AVFrame for subtitle handling
> 
> On Tue, Oct 25, 2022 at 11:14 AM softworkz <ffmpegagent@gmail.com>
> wrote:
> >
> > @@ -712,6 +712,53 @@ typedef struct AVFrame {
> >       * Duration of the frame, in the same units as pts. 0 if
> unknown.
> >       */
> >      int64_t duration;
> > +
> > +    /**
> > +     * Media type of the frame (audio, video, subtitles..)
> > +     *
> > +     * See AVMEDIA_TYPE_xxx
> > +     */
> > +    enum AVMediaType type;
> > +
> > +    /**
> > +     * Number of items in the @ref subtitle_areas array.
> > +     */
> > +    unsigned num_subtitle_areas;
> > +
> > +    /**
> > +     * Array of subtitle areas, may be empty.
> > +     */
> > +    AVSubtitleArea **subtitle_areas;
> > +
> > +    /**
> > +     * Header containing style information for text subtitles.
> > +     */
> > +    AVBufferRef *subtitle_header;
> > +
> > +    /**
> > +     * Indicates that a subtitle frame is a repeated frame for
> arbitrating flow
> > +     * in a filter graph.
> > +     * The field subtitle_timing.start_pts always indicates the
> original presentation
> > +     * time, while the frame's pts field may be different.
> > +     */
> > +    int repeat_sub;
> > +
> > +    struct SubtitleTiming
> > +    {
> > +        /**
> > +         * The display start time, in AV_TIME_BASE.
> > +         *
> > +         * For subtitle frames, AVFrame.pts is populated from the
> packet pts value,
> > +         * which is not always the same as this value.
> > +         */
> > +        int64_t start_pts;
> 
> There is still no explanation here why they are not the same, why
> they
> could not just be the same, and which field a user should look at.
> The cover letter talks about clarity why this is needed is important,
> but then provides none of that.
> 
> "Its required" is not an argument. So please enlighten us once again
> why we absolutely need two timestamps for subtitles, instead of just
> one. As far as I can see, subtitle frames only have one relevant time
> - when its supposed to be shown on the screen. What would the other
> time ever be good for to a user?
> Similarly for the duration, of course. I can even see the
> AVFrame.duration field in this patch snippet just above the additions
> that would seem to fully replace this one.
> 
> - Hendrik

Hi Hendrik,

thanks a lot for your reply.

Probably I should have better advertised the article I had written 
specifically to explain the background of this:

https://github.com/softworkz/SubtitleFilteringDemos/issues/1

I hope it's understandable - please let me know when you have 
questions.


Thanks again,
softworkz
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".