[FFmpeg-devel] [PATCH v3 1/2] avcodec/codec_par: Add codec properties field to AVCodecParameters

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Andreas Rheinhardt
> Sent: Wednesday, October 6, 2021 12:18 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] avcodec/codec_par: Add
> codec properties field to AVCodecParameters
> 
> Soft Works:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: Wednesday, October 6, 2021 11:30 AM
> >> To: ffmpeg-devel at ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] avcodec/codec_par: Add
> >> codec properties field to AVCodecParameters
> >>
> >> Soft Works:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf
> Of
> >>>> Hendrik Leppkes
> >>>> Sent: Wednesday, October 6, 2021 8:57 AM
> >>>> To: FFmpeg development discussions and patches <ffmpeg-
> >>>> devel at ffmpeg.org>
> >>>> Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] avcodec/codec_par:
> Add
> >>>> codec properties field to AVCodecParameters
> >>>>
> >>>> On Wed, Oct 6, 2021 at 8:45 AM Soft Works

[...]

> >>>
> >>
> >> The defines could be moved to defs.h (while just at it, we could
> also
> >> add properly prefixed alternatives and deprecate the FF_ ones).
> >> The copying that you are adding in
> avcodec_parameters_from_context
> >> is
> >> problematic, as the relevant AVCodecContext field is marked as
> "set
> >> by
> >> libavcodec" for decoding, which means that decoders expect it to
> be
> >> blank initially.
> >
> > Why do you think that decoders would expect it to be blank
> initially?
> >
> > What about the other fields then, like format, profile, level,
> width,
> > height, etc. - these are copied in the same way.
> > Are you saying that decoders expect all other fields to be filled
> but
> > the properties field to be zero?
> >
> 
> Of course not. E.g. the documentation of the dimension explicitly
> says
> so: "May be set by the user before opening the decoder if known e.g.
> from the container. Some decoders will require the dimensions to be
> set
> by the caller. During decoding, the decoder may overwrite those
> values
> as required while parsing the data."

The docs for properties don't say "May be set by the user".


> You completely misunderstood what my concern was about: In the
> scenario
> described above an API user querying the properties field would get
> the
> information that this stream contains CC data; even when it doesn't.

But where does that codec_par data come from?

When it's set by the user he has no reason to be surprised when 
it doesn't match reality.

When it comes from probing, then it DID have CC data during probing
which means that even if it the CC data has stopped to be transmitted
exactly within those few milliseconds between probing and decoding,
it is still likely that it will have CC data again at a future 
point in time.
(even though that's not a realistic scenario at all; practically
tv streams either have always cc or never cc)

Kind regards,
softworkz