On Tue, 21 Mar 2017 07:34:32 -0700 Philip Langdale <phil...@overt.org> wrote:
> On Mon, 20 Mar 2017 21:51:49 +0100 > Marton Balint <c...@passwd.hu> wrote: > > > Since subtitles are not yet supported with the new API, > > CODEC_CAP_DELAY subtitle codecs (only libzvbi so far) may loose the > > last few buffered frames in the end of the stream. > > > > The impact of this is so limited, it seemded better to accept it than > > losing the simplification benefits of the new API. > > Tried this v2 patch out and it's still stalling on the crystalhd input. > I also learned, disturbingly, that mpv will fail if I turn on debug > messages, so clearly there's serious timing sensitivity even there. I > can look into blocking on the output side, but I've been very scared of > doing this before, because I've had cases where it deadlocks; "sure I > submitted 250 frames to the hardware - but I'm sure as hell not getting > anything back...". I'd much rather yield to the application to decide > when to give up, but if the API doesn't support that, then so be it. Well, we _could_ add an async mode to the API to deal with such cases, but of course it would still need either a notification mechanism (which the hardware's decode API would have to provide), or evil polling. Though both of these mechanisms could be used to emulate a sync API, so this wouldn't actually give too much. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
