On Thu, Jul 15, 2021 at 05:55:51PM -0300, James Almer wrote: > On 7/15/2021 5:23 PM, Michael Niedermayer wrote: > > On Wed, Jul 14, 2021 at 11:33:59AM -0300, James Almer wrote: > > > It will be used to allow parsers to be more liberal when tagging packets > > > as > > > keyframes. > > > > > > Signed-off-by: James Almer <jamr...@gmail.com> > > > --- > > > libavcodec/avcodec.h | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > > > index 8b97895aeb..8e3d888266 100644 > > > --- a/libavcodec/avcodec.h > > > +++ b/libavcodec/avcodec.h > > > @@ -2809,6 +2809,7 @@ typedef struct AVCodecParserContext { > > > #define PARSER_FLAG_ONCE 0x0002 > > > /// Set if the parser has a valid file offset > > > #define PARSER_FLAG_FETCHED_OFFSET 0x0004 > > > +#define PARSER_FLAG_USE_KEYFRAME_HEURISTICS 0x0008 > > > #define PARSER_FLAG_USE_CODEC_TS 0x1000 > > > > This doesnt "feel" like the best solution to me > > > > dont you think it would be better to export all information ? > > The AVParser API is going to be removed at some point for something better > that works on packets rather than raw buffers, so ideally we should not > expand it too much, and leave more complex implementations for later.
Iam not sure i follow your logic here do you suggest to block setting lets call it "advanced keyframe" related work across the codebase ? (that includes muxers and so on ? Iam not saying thats a good or bad idea. Just trying to understand Because to me it seems if the awnser is no to the question above then this is not just about "Adding a flag is the simplest way to fix this" but its adding codec specific code in muxers probably to extract the exta information, and iam not sure that at this point its not easier to have the parser export this information And when the parser API is then replaced by "something better" the interface changes less. If this heuristic flag is added then i assume it needs to be removed and reimplemented with the API change. I very likely am missing something But i certainly do not suggest or ask for more work to be done. Rather the opposit, i was wondering if its not less work overall to export the information properly ... thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".