[FFmpeg-devel] [PATCH] avcodec: Add AVClass to AVCodecParameters

[Michael Niedermayer]

On Tue, May 17, 2016 at 07:08:42PM +0200, Michael Niedermayer wrote:
> On Tue, May 17, 2016 at 12:26:18PM -0400, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Tue, May 17, 2016 at 11:18 AM, Michael Niedermayer <
> > michael at niedermayer.cc> wrote:
> > 
> > > AVCodecContext contains all the fields that AVCodecParameters has.
> > > Examples are width, height, bitrate, profile, sample_rate, channels
> > >
> > > In AVCodecContext these fields are accessible through AVOptions
> > > in AVCodecParameters these fields are not accessible through AVOptions
> > > and your code will crash mysteriously if you try to access them that
> > > way
> > >
> > > This is a inconsistency that was not there before
> > 
> > 
> > So, at the risk of going semi-offtopic, let me take a different angle at
> > this problem.
> > 
> > AVCodecParameter is supposed to be an intermediate layer that removes the
> > need for lavf to access lavc structs like AVCodecContext, right?
> > 
> > So, I worked (a long long time ago) on this software called GStreamer, and
> > specifically, one of the plugins I worked on early on was gst-ffmpeg. I
> > loved working on it because it practically added so many codecs to the
> > player which were previously unsupported. Yay! Now, the API back then was
> > horrible. You had an AVCodecContext (no AVOptions) and there were
> > approximately 100 million fields that could be set. Most were undocumented,
> > and it was totally unclear which needed to be set. For example, to play a
> > WMA file, you might have to set block_align, but for other audio codecs,
> > you do not [1].
> > 
> > For video, sometimes you would have to set extradata (e.g. for SVQ3), but
> > other times, you would not. Huffyuv required bits_per_sample, but h264 did
> > not.
> > 
> > So how do you write generic user-facing code where the demuxer and decoder
> > actually are separate entities and merely interact over a serialized
> > communication channel? You can't serialize AVCodecContext. I mean, you
> > could, but that's a terrible idea. And nothing documented which fields were
> > required to be set and which weren't.
> > 
> 
> > I was hoping that AVCodecParameters would solve this. Ideally, it would be
> > a dictionary of fields that are to be shared between demuxer and decoder
> > (or codec and muxer). But I think it has sort of strayed off of that intent
> > and is just a flat minimized AVCodecContext as it existed in 2003.
> > 
> > Can we fix this? I think AVOptions would be ideally suited to fix this.
> > AVClass maybe helps also. But if introspection suggests I can set
> > block_align on the h264 decoder, or width on an audio decoder, or who knows
> > what. Then I don't think AVOptions or AVClass in AVCodecParameters helps at
> > all. It just creates a minimized AVCodecContext from 2003 that will slowly
> > become the current AVCodecContext, which is not all that useful for people
> > that don't use ffmpeg.exe...
> 
> I hadnt thought about this but
> AVOption can do this wth the current AVCodecParameters to a large
> extend not 100% though currently
> it has flags that allow options to be marked as for different things
> like audio, video, encoders, decoders or anything else
> so your example of block_align for h264 and width on an audio decoder
> can be resolved by AVOption as long as it knows which flags apply

> A full solution is possible
> one could for example simply set a different AVClass&AVOption list on
> the  AVCodecParameters struct depending on what codec it is so that
> only the fields actually supported would be listed in the first place.
> Something would need to generate that list though from some master
> list.

actually nothing is needed to generate the lists at run time
an example would be libavfilter/vsrc_testsrc.c
which uses the same private struct for multiple different filters
and has AVOption lists that are matched to each filter
the same could be done with AVCodecContext, AVFormatContext,
AVCodecParameters and others to get a list of supported parameters
which exactly matches the used codec / demuxer / muxer / ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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/20160517/f44fe995/attachment.sig>