| Message ID | 20170926003631.55571-6-ffmpeg@tmm1.net |
|---|---|
| State | Accepted |
| Commit | dad42bc5a134f60164eab2dfb0892b761603e1e1 |
| Headers | show |
On Mon, Sep 25, 2017 at 05:36:28PM -0700, Aman Gupta wrote: > From: Aman Gupta <aman@tmm1.net> > > The only reason videotoolbox wouldn't produce frames is if the data fed > to it was invalid, so returning AVERROR_INVALIDDATA makes sense here. > > Further, it means AVERROR_EXTERNAL can be used in further commits to signal > fatal VideoToolbox errors, letting the user know that they need to fallback to > another decoder. > --- > libavcodec/h264dec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) probably ok thx [...]
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c index 49ebeca6d8..a8263f2e19 100644 --- a/libavcodec/h264dec.c +++ b/libavcodec/h264dec.c @@ -849,7 +849,7 @@ static int output_frame(H264Context *h, AVFrame *dst, H264Picture *srcp) int ret; if (src->format == AV_PIX_FMT_VIDEOTOOLBOX && src->buf[0]->size == 1) - return AVERROR_EXTERNAL; + return AVERROR_INVALIDDATA; ret = av_frame_ref(dst, src); if (ret < 0)
From: Aman Gupta <aman@tmm1.net> The only reason videotoolbox wouldn't produce frames is if the data fed to it was invalid, so returning AVERROR_INVALIDDATA makes sense here. Further, it means AVERROR_EXTERNAL can be used in further commits to signal fatal VideoToolbox errors, letting the user know that they need to fallback to another decoder. --- libavcodec/h264dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)