It's not allowed to modify ctx->hw_device_ctx after avcodec_open2().
Therefore, we need to create the hw_frames_ctx ourselves from it, and from
the get_format() callback. It can be easily done with the
avcodec_get_hw_frames_parameters() helper.
The surface frame count is now known from the Create() function,
therefore, the semaphore can be directly initialized, removing the need
for the pool_sem_init dirty hack.
Recover the hw pool size from the first Get() call (after the
AVCodecContext has been initialized) and use a semaphore to pace the
picture allocation from Get().
That way, we don't rely anymore av_hwframe_get_buffer() return values,
that returned the same error for internal error or when the pool was
full.
Fixes#26166
lavc_UpdateVideoFormat is returning an error when init_device is NULL.
In addition, a NULL init_device cannot happens since this function
expects NULL as pointer-to-pointer to actually allow (and disable the
loading of) a NULL decoder device.
The check was necessary when c06a7fd2fd
was introduced, but 1798f25add fixed the
return value in this case.
This unify the calling of the function with the `,NULL)` version.
We can't really use an interface** where a void** is expected, that's a
cast/aliasing violation, even though that's what Windows and mingw64 API's do
as well.
We use an interim void* variable that receives the pointer and then set it on
the proper variable with the given type.
Fixes#26083
A codec which doesn't set AV_CODEC_CAP_DELAY but has the capability
of multi-threads decoding still needs to be drained by an empty
packet. According to the document, it's safe to pass NULL data to
libavcodec decode function, libavcodec will not pass it along to the
codec unless AV_CODEC_CAP_DELAY is set.
This makes it consistent with all the other uses of such defines in
the source code, which are tested for their existence rather than the
actual value.
When avcodec is found, it does not really add much value to check for
the avcodec header. avutil is required by it, so checking for that
is not needed either.
For avformat, avcodec is required, therefore checking for
avcodec and avutil headers is not needed there either.
Conditionally including those in avcommon_compat.h does not
seem needed at all, as it won't compile without these headers
anyway.
Contrary to all other hardware decoders, vaapi can't work with a
hwaccel_context anymore. It requires a hw_device_ctx or a hw_frames_ctx
to work.
This first implementation use a hw_device_ctx and let avcodec handle its
frames pool. It is also possible to handle hw_frames_ctx ourself to get
more controls.
Note: Most of the code could be reused by other va modules if we decide
to a hw_device_ctx.
Fixes#25707
The future vaapi va module will create AVFrame from hwframes_ctx with a
frame->buf[0] set internally by avcodec. If this is the case, don't
override it and use opaque_ref (an user field) to keep the reference on
the VLC picture_t.
frame->buf[0] must be valid but doesn't have to contain data since the
data will be accessed via frame->data[] directly.
Furthermore, all va modules are only setting frame->data[3], therefore,
frame->data[0] was always NULL.
av_init_packet is deprecated in new major version of ffmpeg.
Also use av_packet_free instead of unref.
Use av_packet_clone and AVPacket * in vlc_av_packet_t.
Since ffmpeg 4.4 specifying channel layout or channel number is required
to call `avcodec_send_frame()` without error.
This is new requirement is due to a change in the avcodec internal API
brought by 827d6fe73d2f5472c1c2128eb14fab6a4db29032 (ffmpeg repo). They
now call `av_frame_ref` which needs the channels fields to be valid.
Fixes: #25851
Sidedata AV_PKT_DATA_QUALITY_STATS has been present since 2015 on
version 56.51.100. Also previous coded_frame->pict_type doesn't seem to
be present anymore in ffmpeg master.
The config "advanced" flag was unused and has been removed by
6a7a137f7b.
It has been removed from many add_*() macros, but not all. Remove it
from the remaining macros.
longtext should add something of value, otherwise results in useless
tooltips and a waste of translator time.
in the ball case, feedback was that the longtext was better than the
existing shorttext.
where identical to shorttext, or near enough.
bad because:
- wastes resources.
- useless tooltips in prefs GUI (poor UX) - tooltip longtext should add
something of value.
- useless repetition of text in certain help output.
in some cases they differed only in full-stop, creating unnecessary extra
burden on translators.