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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
