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
> Soft Works
> Sent: Tuesday, October 25, 2022 11:59 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
> 
> 
> 
> > -----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

@Hendrik - did that answer your question?

You are also welcome to contact me directly for discussing details
or going through specific examples; or just to ping me for logging
on to IRC for chat.

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".