On Wed, Nov 15, 2017 at 1:57 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Wed, Nov 15, 2017 at 10:15 PM, Aman Gupta <ffm...@tmm1.net> wrote: > > From: Aman Gupta <a...@tmm1.net> > > > > Previously the codec kept an entire copy of the SPS, and restarted the > VT decoder > > session whenever it changed. This fixed decoding errors in [1], as > > described in 9519983c. On further inspection, that sample features an > SPS change > > from High/4.0 to High/3.2 while moving from one scene to another. > > > > Yesterday I received [2], which contains minor SPS changes where the > > profile and level do not change. These occur frequently and are not > associated with > > scene changes. After 9519983c, the VT decoder session is recreated > unnecessarily when > > these are encountered causing visual glitches. > > > > This commit simplifies the state kept in the VTContext to include just > the first three > > bytes of the SPS, containing the profile and level details. This is > populated initially > > when the VT decoder session is created, and used to detect changes and > force a restart. > > > > This means minor SPS changes are fed directly into the existing decoder, > whereas > > profile/level changes force the decoder session to be recreated with the > new parameters. > > > > The profile and level are not exactly the only things that can change > to force a decoder to be re-created. > How about the frame dimensions, within the same level? > If you know somewhere I can find such a sample, I can try it with VideoToolbox to see if it requires the session to be recreated or not. Aman > > - Hendrik > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
