On Sat, Jul 31, 2021 at 02:40:11PM +0200, Hendrik Leppkes wrote: > On Sat, Jul 31, 2021 at 11:41 AM Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > Theres also the 2nd situation where all the information the parser > > extracts is already known to the lib user and going over the whole > > bitstream is wasting cpu cycles. This can be a situation where for > > example all input files where just a moment ago created by FFmpeg > > and we assume these would then be as compliant as redoing the parsing > > would make them > > > > This is however not necessarily the case, because we only have one > keyframe field and there are quite varying definitions of what a > container would consider a keyframe for their own purposes. > This is the entire reason this patch was created in the first place, > because different containers have different keyframe semantics, and a > single field in AVPacket cannot cleanly represent it. >
agree on all this and thats why i was pushing a bit toward improving the API. > A container therefore determining for its own definition of keyframe > how to mark them is the only reliable way currently. Does it not feel ugly to you that some data can be set by the user through the API and is used, some can be set and is ignored and re-parsed for some container-codec combinations and some cannot be set at all ? What we have is quite inconsistent. I am trying to push a bit towards improving this. Iam not insisting on it. One thing iam suggesting is to extend the API to at least be able to represent all information. If all information can be represented then that allows moving the "parser" out of the muxer and also naturally allows passing information on from user or demuxer or encoder and also allows judging if we are missing something or already have all data. I may be missing something but to me this just seems cleaner than ignoring the user settings completely, reparsing and then whats the next step ? we replace the parser system but do we leave this inside the muxer or move it back out ? If we move it back out its a odd moving around of the code, if its left in the muxer under a new API then its IMHO a bit unwieldy, sometimes redundant and hard to interact with. Iam clearly not understanding something here of the grand plan ... thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein
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".
