[FFmpeg-devel] [PATCH 2/2] ffmpeg: Don't clear input pict_type if force_key_frames is source

[Michael Niedermayer]

On Fri, Dec 11, 2015 at 02:23:56PM -0600, Will Kelleher wrote:
> On 12/11, Michael Niedermayer wrote:
> > On Fri, Dec 11, 2015 at 09:47:29AM -0600, Will Kelleher wrote:
> > > The current behavior doesn't forward non-IDR I-frames to the encoder.
> > 
> > would this not turn every I-type non keyframe into a key frame
> > effectively?
> > and if so, is that intended ?
> > 
> 
> Depending on how the codec implementation handles it, maybe.
> 
> I need a way to make the encoder aware of non-IDR I-frames.  I can't really
> tell if the original intent of the `force_key_frames = source` setting is to
> force only IDR, or to generally force intra coding of the frame.
> 
> With this change, I'm able to differentiate between I-frames and IDR frames
> using the key_frame member, which seems to only be set for IDR frames.  So key
> frames are (pict_type == AV_PICTURE_TYPE_I && key_frame) and normal I-frames are
> just (pict_type == AV_PICTURE_TYPE_I).
> 
> If you think this will cause problems with other codecs, do you have any
> advice for an alternate implementation?

well, whatever implementation is choosen. The fields should be
interpreted the same way by all encoders.
also things should be clean and sane
and any unavoidable changes to the API should be clearly documented
(even if the current API is not well documented, anything that requires
 applications to be changed or recommands them to be changed should be
 clearly documented in APIChanges)



> 
> Also, can you provide some context for why pict_type is being used instead of
> key_frame?  Does key_frame need to be valid for some other functionality?

iam not sure but possibly this originates from a time when all i
frames where key frames in practice

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151211/3984be29/attachment.sig>