On 08/01/13 15:34, Anton Khirnov wrote:
> Hi,
> while The Evil Plan is not completely done yet, I feel that it is now
> finished enough for some proper review. Who still does not know what The
> Evil Plan is, see previous threads with it in the subject.
>
> I will split it in three threads for convenience. This one will contain
> the introductional stuff + refcounting AVPackets. The next one will be
> the monster that refcounts every single video decoder in lavc. And the
> final one will switch lavfi to AVFrame.
>
> The full tree can be found at git://git.khirnov.net/libav
> branch avbuffer
>
> Since this is a huge changeset, it's important to get this right. So I'd
> like as many people as possible to look at least at the core API
> changing/adding patches to make sure there are no huge problems with it.
>
> What remains to be done:
> ========================
> 1) There are still some fields in AVFrame where I'm not sure whether they
> should be kept, removed or transformed into some other shape.
> Here is a summary of what I have so far:
>
> certainly keep:
> uint8_t *data[AV_NUM_DATA_POINTERS];
> int linesize[AV_NUM_DATA_POINTERS];
> uint8_t **extended_data;
> int width, height;
> int nb_samples;
> int format;
> AVRational sample_aspect_ratio;
> int64_t pts;
> int sample_rate;
> uint64_t channel_layout;
> int palette_has_changed;
> // possibly merge those two into a single field
> // or alternatively add a frame flags field and stuff
> interlaced_frame there
> int interlaced_frame;
> int top_field_first;
Using an int or an uint64 for flags wouldn't be that horrible I guess.
>
> deprecated by refcounting => remove:
> int reference;
> void *opaque;
> int buffer_hints;
> int type;
> uint8_t *base[AV_NUM_DATA_POINTERS];
>
> mpeg-specific crap, most probably useless => remove:
> int8_t *qscale_table;
> int qstride;
> int qscale_type;
> uint8_t *mbskip_table;
> int16_t (*motion_val[2])[2];
> uint32_t *mb_type;
> short *dct_coeff;
> int8_t *ref_index[2];
> uint8_t motion_subsample_log2;
Surely vp8 will not map to this I guess.
> private lavc fields => move elsewhere in lavc:
> void *hwaccel_picture_private;
> struct AVCodecContext *owner;
> void *thread_opaque;
>
> change into frame side data:
> AVPanScan *pan_scan; // mpeg12-specific
> // contains frame PSNR, mpegvideo_enc specific, used by avconv
> uint64_t error[AV_NUM_DATA_POINTERS];
why it is called error?
>
> ????:
> // those are very lavc-specific, but quite useful so i'm unsure
> // what to do about them. pkt_pts might potentially be replaced by
> pts,
> // since pts is currently not used for anything useful when decoding
> // but pkt_dts is apparently also useful when there is no pts
> int64_t pkt_pts;
> int64_t pkt_dts;
> int64_t reordered_opaque;
I wonder who uses reordered_opaque, the other two have some uses indeed.
> // those two are only set by mpegvideo stuff, not sure if it's of any
> use
> int coded_picture_number;
> int display_picture_number;
I doubt
> // very codec-specific. probably useless for decoding, but some
> encoders use
> // it to allow specifying quantizer per-frame. change into frame side
> data
> // maybe?
> int quality;
Maybe keep last if there is some padding to fill.
> // again, very lavc-specific "weakly coupled" frame metadata, not an
> actual
> // frame propery. at least pict_type is kinda useful.
> int repeat_pict;
> int key_frame;
> enum AVPictureType pict_type;
Key frame and repeat pict could be made redundant merging it with
pickture type in a bitfield?
so we could have
int pict_type;
int quality;
> Suggestions about the ???? fields are very much welcome (of course feel
> free to comment on the other ones as well).
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
