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

Philip Langdale philipl at overt.org
Wed Mar 22 23:57:57 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.


Although there's an existence proof with mpv that the crystalhd decoder
can be used through the API, it's clearly more fragile than it should
be, so I'm fine with you pushing as is, and I'll see what I can do to
make the decoder do some kind of blocking to smooth this over.


More information about the ffmpeg-devel mailing list