[FFmpeg-devel] [PATCHv2 2/3] ffplay: convert to new decode API

wm4 nfxjfg at googlemail.com
Tue Mar 21 17:05:26 EET 2017


On Tue, 21 Mar 2017 07:34:32 -0700
Philip Langdale <philipl at overt.org> wrote:

> On Mon, 20 Mar 2017 21:51:49 +0100
> Marton Balint <cus at 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.


More information about the ffmpeg-devel mailing list