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().
Regards,
--
Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
