[FFmpeg-devel] [PATCH 2/2] avformat/movenc: parse h264 packets to build Sync Sample and Recovery Point tables

[Michael Niedermayer]

On Sat, Jul 31, 2021 at 02:40:11PM +0200, Hendrik Leppkes wrote:
> On Sat, Jul 31, 2021 at 11:41 AM Michael Niedermayer
> <michael at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210731/c5633186/attachment.sig>