[FFmpeg-devel] [PATCH 11/14] lavfi/vf_paletteuse: convert to framesync2.

Clément Bœsch u at pkh.me
Thu Aug 10 12:41:34 EEST 2017


On Thu, Aug 10, 2017 at 11:33:31AM +0200, Nicolas George wrote:
> Le tridi 23 thermidor, an CCXXV, Clement Boesch a écrit :
> > But unless it's API documented, that's implementation specific. I'd prefer
> > if you keep that as a safe guard. It also has a documentation purpose.
> 
> I will do it if you insist, but before that, let me correct a little
> detail:
> 
> > If the frame is already writable it will be a noop.
> 
> Before it is used for its contents, frames are used for their timestamp.
> The frame could be read-only at the time it is dequeued by
> framesync but have become writable by the time it is ready for
> processing by the filter. And I think it is not that unlikely: a graph
> with split sending to overlay and scale would have that effect.
> 
> Instead of .needs_writable (I am not sure this flag should be relevant
> with the activate callback), I can propose the following solution that
> make the need for a writable explicit:
> 
> 	/**
> 	 * Like ff_framesync2_dualinput_get, but make sure f0 is
> 	 * writable.
> 	 */
> 	ff_framesync2_dualinput_get_writable(fs, &f0, &f1);
> 
> or:
> 
> 	ff_framesync2_dualinput_get(fs, &f0, &f1,
> 	                            FRAMESYNC_MAIN_WRITABLE);
> 
> (whichever people prefer), and probably the same options for the
> individual ff_inlink_consume_frame().
> 

I like ff_framesync2_dualinput_get_writable() better, but both are fine
with me.

Note: if you follow that path, please keep the comment about dithering
above the writable call to that framesync function.

Thanks

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170810/41c769ee/attachment.sig>


More information about the ffmpeg-devel mailing list