On 11/10/17 09:10, Li, Zhong wrote: >> -----Original Message----- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Mark Thompson >> Sent: Tuesday, October 10, 2017 6:36 AM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] [PATCH 2/6] vaapi: Remove H.264 baseline >> profile >> >> On 09/10/17 22:48, Carl Eugen Hoyos wrote: >>> 2017-10-09 13:21 GMT+02:00 wm4 <nfx...@googlemail.com>: >>> >>>> Shouldn't trying to decode baseline video just fall back to sw decoding? >>> >>> Given that software doesn't support the specific features of baseline >>> either, I don't think this helps. >>> I was under the impression the only sane thing to do when reading >>> baseline H.264 is printing a warning and continue as if constraint >>> baseline was detected. >> >> At least with software decode we would know that it has failed - an >> inconvenient property of many hardware decoders is their reluctance to >> report errors usefully or at all. >> >> Hence the warning on using the ALLOW_PROFILE_MISMATCH flag, which >> does allow the attempt to decode baseline profile streams with hardware: >> """ >> If the stream is actually not supported then the behaviour is undefined, and >> may include returning entirely incorrect output while indicating success. >> """ >> >> I think the behaviour we have now with this option to continue if the user >> really wants (and is aware of the possible consequences) is correct. >> > > [Li, Zhong] There advanced features of baseline profile are not > supported：FMO, SAO, and Redundant slices. > So another way is to check a baseline clip has some of these there features > or not (ie, slice_group_number can be check when decoding PPS), > If yes, fall back to sw decoding. Else, set the profile to be constrained > profile.
Unfortunately, you have to examine the whole stream to determine this sort of thing. For a more concrete example in a perhaps more plausible case, consider an H.264 main profile hardware decoder and an H.264 high profile stream. At the start of the stream, we can examine the first packet and observe that all constraints for main profile are met: no scaling matrices, no 8x8 transform, etc. So, we can start using the main profile hardware decoder, and everything works for a while. Then, at some point in the middle of the stream, a new PPS turns up containing scaling matrices and enabling the 8x8 transform. Now what? We can't fall back to software decoding because this isn't a stream boundary - we need to use the reference frames which are currently stored in hardware surfaces. So the output is now going to be broken because we made the wrong choice initially, when it could have worked. Therefore: the profile information in the stream is the only method we should be using to determine profile conformance - trying to infer other values is doomed to disastrous failure in edge cases, so should only be done if the user explicitly requests it (e.g. with the ALLOW_PROFILE_MISMATCH flag). If an encoder declares a higher profile than it actually uses then that is unhelpful but there is little we can do about it. - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
