Expose more enums

[wiggin15]

I'm interested in getting and setting attributes of av.VideoStream, av.VideoCodecContext and av.VideoFrame that are defined as enums, such as AVColorSpace, AVColorRange, AVColorPrimaries, AVPixelFormat.

For example:

import av
container = av.open("foo.mp4", "w")
vid_stream = container.add_stream("h264", 30)
vid_stream.color_primaries = 2   # 2?

We already expose av.video.frame.PictureType which is one enum that can be set as an attribute of av.VideoFrame. Please consider exposing the enums mentioned above.

Here is a list of all enums defined in pyav as cdef enum, please consider exposing enums that users may want to get/set:

AVCodecID
AVDiscard
AVPacketSideDataType
AVFrameSideDataType
AVSubtitleType
AVMediaType
AVPictureType
AVPixelFormat
AVRounding
AVColorSpace
AVColorRange
AVColorPrimaries
AVColorTransferCharacteristic
AVPixFmtFlags
AVOptionType
AVClassCategory
AVSampleFormat

[WyattBlue]

I don't understand why putting all enums in the library would be a benefit when library users can just define enums for themselves. It would just bloat the library size to all the enums and their string names. I would rather consider it on a case by case basis.

Defining enums as a library user example:

from enum import IntEnum

class ColorPrimaries(IntEnum):
    reserved0 = 0
    bt709 = 1
    unspecified = 2
    reserved = 3
    bt470m = 4
    bt470bg = 5
    smpte170m = 6
    smpte240m = 7
    film = 8
    bt2020 = 9
    
vid_stream.color_primaries = ColorPrimaries.unspecified.value

[wiggin15]

Hi. Thanks for replying! The enum you provided is what I'm asking PyAV code to provide.

I would rather consider it on a case by case basis.

As mentioned I'm asking specifically for: AVColorSpace, AVColorRange, AVColorPrimaries, AVPixelFormat.
I listed the other enums to take into consideration.

IMHO these enum definitions belong in PyAV code and not in users' code, for several reasons:

1. These enums are defined by ffmpeg. As a library that provides binding for ffmpeg, it makes sense for PyAV to expose them, just as ffmpeg exposes them to C code.
2. Putting these enums in user code is contrary to the DRY principle. It is more error prone, and it will bloat users' code base. These enums can change from version to version, and duplicating them across dependencies may cause problems and confusions.
3. Most importantly, these enums are directly related to class fields already exposed by PyAV - fields that are defined as enums in the C structures, but defined as "int"s by PyAV.

In C code, users can do:

frame->color_primaries = AVCOL_PRI_BT709

so it makes sense that in PyAV it will be something like:

frame.color_primaries = ColorPrimaries.BT709

and not:

frame.color_primaries = 1

In the same way ffmpeg defines these fields for users, and the ffmpeg library doesn't expect its users to use "magic numbers" or duplicate enum definitions across dependencies, I would expect PyAV to expose these enums for the same fields.

As I mentioned, PyAV already exposes PictureType which is one enum. Why expose this one but not the others?
I wouldn't say it would "bloat" PyAV, any more then defining the corresponding C enums which PyAV already does. I would say it would add to PyAV's functionality (and even correctness).

Thanks again, and thanks for the library! It's very useful.