[FFmpeg-devel] [PATCH v20 02/20] avutil/frame: Prepare AVFrame\n for subtitle handling

Soft Works softworkz at hotmail.com
Sun Dec 12 02:49:23 EET 2021



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Daniel
> Cantarín
> Sent: Sunday, December 12, 2021 12:39 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v20 02/20] avutil/frame: Prepare AVFrame\n
> for subtitle handling
> 
>  > One of the important points to understand is that - in case of subtitles,
>  > the AVFrame IS NOT the subtitle event. The subtitle event is actually
>  > a different and separate entity. (...)
> 
> 
> Wouldn't it qualify then as a different abstraction?
> 
> I mean: instead of avframe.subtitle_property, perhaps something in the
> lines of avframe.some_property_used_for_linked_abstractions, which in
> turn lets you access some proper Subtitle abstraction instance.
> 
> That way, devs would not need to defend AVFrame, and Subtitle could
> have whatever properties needed.
> 
> I see there's AVSubtitle, as you mention:
> https://ffmpeg.org/doxygen/trunk/structAVSubtitle.html
> 
> Isn't it less socially problematic to just link an instance of AVSubtitle,
> instead of adding a subtitle timing property to AVFrame?
> IIUC, that AVSubtitle instance could live in filter context, and be linked
> by the filter doing the heartbeat frames.

That was my initial approach actually: attach an AVSubtitle as BufferRef
to AVFrame. It still appears to me the logically most valid approach
as subtitle events (AVSubtitle) are not copied, just referenced and it
is quite clear which properties are owned by which entity.
Modeling it this way reflects what's actually happening and easier to 
understand. 

Yet that approach has been talked down so strongly that there was no chance to
further defend it.


>  > (...)
>  > Considering the relation between AVFrame and subtitle event as laid out
>  > above, it should be apparent that there's no guarantee for a certain
>  > kind of relation between the subtitle_pts and the frame's pts who
>  > is carrying it. Such relation _can_ exist, but doesn't necessarily.
>  > It can easily be possible that the frame pts is just increased by 1
>  > on subsequent frames. The time_base may change from filter to filter
>  > and can be oriented on the transport of the subtitle events which
>  > might have nothing to do with the subtitle display time at all.
> 
> This confuses me.
> I understand the difference between filler frame pts and subtitle pts.
> That's ok.
> But if transport timebase changes, I understand subtitle pts also changes.

10s are always 10s, not matter what the time_base is.


I may respond to the other parts tomorrow.

Kind regards,
softworkz


More information about the ffmpeg-devel mailing list