Chiebot-Mirror/FFmpeg - FFmpeg - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Andreas Rheinhardt	fe6037fd04	avcodec/mpegpicture: Split MPVPicture into WorkPicture and ordinary Pic There are two types of MPVPictures: Three (cur_pic, last_pic, next_pic) that are directly part of MpegEncContext and an array of MPVPictures that are separately allocated and are mostly accessed via pointers (cur\|last\|next)_pic_ptr; they are also used to store AVFrames in the encoder (necessary due to B-frames). As the name implies, each of the former is directly associated with one of the _ptr pointers: They actually share the same underlying buffers, but the ones that are part of the context can have their data pointers offset and their linesize doubled for field pictures. Up until now, each of these had their own references; in particular, there was an underlying av_frame_ref() to sync cur_pic and cur_pic_ptr etc. This is wasteful. This commit changes this relationship: cur_pic, last_pic and next_pic now become MPVWorkPictures; this structure does not have an AVFrame at all any more, but only the cached values of data and linesize. It also contains a pointer to the corresponding MPVPicture, establishing a more natural relationsship between the two. This already means that creating the context-pictures from the pointers can no longer fail. What has not been changed is the fact that the MPVPicture* pointers are not ownership pointers and that the MPVPictures are part of an array of MPVPictures that is owned by a single AVCodecContext. Doing so will be done in a latter commit. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	9 months ago
Andreas Rheinhardt	ec1eba792a	avcodec/mpegvideo: Shorten variable names current_picture->cur_pic, last_picture->last_pic, similarly for new_picture and next_picture. Also rename the corresponding *_ptr fields. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	9 months ago
Andreas Rheinhardt	e35dfe864d	avcodec/avcodec: Add FFHWAccel, hide internals of AVHWAccel This commit is the AVHWAccel analogue of commit 20f972701806be20a77f808db332d9489343bb78: It moves the private fields of AVHWAccel to a new struct FFHWAccel extending AVHWAccel in an internal header (namely hwaccel_internal.h). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	2 years ago
Hendrik Leppkes	b3e938ef80	avcodec/nvdec_mpeg4: fix order of quant matrix coefficients The matrix coefficients are stored permutated for the IDCT, rather then in plain raster order, and need to be un-permutated for the hardware.	2 years ago
Andreas Rheinhardt	500bbd584d	avcodec/mpeg4video: Factor non-codec stuff out into a header of its own This avoids including mpegvideo.h in mpeg4_unpack_bframes_bsf.c. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Andreas Rheinhardt	746e7102be	avcodec/mpegvideo: Move encoder-only stuff to a new header Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Andreas Rheinhardt	1187765f3b	avcodec/mpeg4video.h: Move decoder-only parts to a new header Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Philip Langdale	83c7ac2e47	avcodec/nvdec: Explicitly mark codecs that support 444 output formats With the introduction of HEVC 444 support, we technically have two codecs that can handle 444 - HEVC and MJPEG. In the case of MJPEG, it can decode, but can only output one of the semi-planar formats. That means we need additional logic to decide whether to use a 444 output format or not.	6 years ago
Mark Thompson	3a71bcc213	lavc: Mark all AVHWAccel structures as const	7 years ago
Philip Langdale	6b77a10e43	avcodec: Implement mpeg4 nvdec hwaccel This was predictably nightmarish, given how ridiculous mpeg4 is. I had to stare at the cuvid parser output for a long time to work out what each field was supposed to be, and even then, I still don't fully understand some of them. Particularly: vop_coded: If I'm reading the decoder correctly, this flag will always be 1 as the decoder will not pass the hwaccel any frame where it is not 1. divx_flags: There's obviously no documentation on what the possible flags are. I simply observed that this is '0' for a normal bitstream and '5' for packed b-frames. gmc_enabled: I had a number of guesses as to what this mapped to. I picked the condition I did based on when the cuvid parser was setting flag. Also note that as with the vdpau hwaccel, the decoder needs to consume the entire frame and not the slice.	7 years ago