[Cin] ffmpeg 6.1 is out!

Phyllis Smith phylsmith2017 at gmail.com
Sun Nov 12 01:44:40 CET 2023


OK, got your last 2 suggestions and will work on that.  But getting too
tired to do much anymore today!

On Sat, Nov 11, 2023 at 5:42 PM Andrew Randrianasulu <
randrianasulu at gmail.com> wrote:

>
>
> вс, 12 нояб. 2023 г., 03:21 Andrew Randrianasulu <randrianasulu at gmail.com
> >:
>
>>
>>
>> вс, 12 нояб. 2023 г., 02:59 Phyllis Smith <phylsmith2017 at gmail.com>:
>>
>>> Downloaded it today and now am re-doing the patches so that there are no
>>> "Hunk #1 succeeded at xxx (offset xxx lines)" warning messages.  Seems like
>>> just about all of them are off so it will take me some time.  Did not
>>> include patch10 and getting errors that are stopping the compile as shown
>>> below.  This patch10 is more than I know how to fix.
>>>
>>> In file included from libavutil/hwcontext_cuda.c:27:
>>>> libavutil/hwcontext_cuda.c: In function ‘cuda_context_init’:
>>>> libavutil/hwcontext_cuda.c:365:28: error: ‘CudaFunctions’ has no member
>>>> named ‘cuCtxGetCurrent’; did you mean ‘cuCtxPopCurrent’?
>>>>   365 |         ret = CHECK_CU(cu->cuCtxGetCurrent(&hwctx->cuda_ctx));
>>>>       |                            ^~~~~~~~~~~~~~~
>>>> libavutil/cuda_check.h:65:114: note: in definition of macro
>>>> ‘FF_CUDA_CHECK_DL’
>>>>    65 | #define FF_CUDA_CHECK_DL(avclass, cudl, x)
>>>> ff_cuda_check(avclass, cudl->cuGetErrorName, cudl->cuGetErrorString, (x),
>>>> #x)
>>>>       |
>>>>                                                  ^
>>>> libavutil/hwcontext_cuda.c:365:15: note: in expansion of macro
>>>> ‘CHECK_CU’
>>>>   365 |         ret = CHECK_CU(cu->cuCtxGetCurrent(&hwctx->cuda_ctx));
>>>>       |               ^~~~~~~~
>>>> make[3]: *** [ffbuild/common.mak:81: libavutil/hwcontext_cuda.o] Error 1
>>>>
>>>
>> may be first revert those two?
>>
>>
>> https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/f904e60c32a87f4124c3b94598a3b0141cd8b1b9
>>
>>
>> https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/05f8b2ca0f7e28775837a572c65ce9218f534ee2
>>
>>
>> or update ffnvheaders (not sure if it will work for legacy proprietary
>> driver , something to find out)
>>
>> https://github.com/FFmpeg/nv-codec-headers/releases
>>
>>
>> not sure that exactly version? we seems to have 10.x and only updated
>> ones there (so the potentially include fix for this cudaCurrent change)
>> are 11.x and 12.x .....
>>
>
> Also,ffmpeg 6.1 removed libopenjpeg *decoder* but encoder apparently still
> in place:
>
>
> https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/60ccb3fe787be3bb10fc4545b3593cd1e0b769ed
>
> I also  hope to add lcms2 (for icc profile support via ffmpeg) but not
> sure if that pach was finished.
>
>
>
>
>>
>>
>>
>>> On Sat, Nov 11, 2023 at 7:14 AM Andrew Randrianasulu <
>>> randrianasulu at gmail.com> wrote:
>>>
>>>> http://ffmpeg.org/download.html#release_6.1
>>>>
>>>> ======
>>>>
>>>> November 10th, 2023, FFmpeg 6.1 "Heaviside"
>>>>
>>>> FFmpeg 6.1 "Heaviside" <http://ffmpeg.org/download.html#release_6.1>,
>>>> a new major release, is now available! Some of the highlights:
>>>>
>>>>    - libaribcaption decoder
>>>>    - Playdate video decoder and demuxer
>>>>    - Extend VAAPI support for libva-win32 on Windows
>>>>    - afireqsrc audio source filter
>>>>    - arls filter
>>>>    - ffmpeg CLI new option: -readrate_initial_burst
>>>>    - zoneplate video source filter
>>>>    - command support in the setpts and asetpts filters
>>>>    - Vulkan decode hwaccel, supporting H264, HEVC and AV1
>>>>    - color_vulkan filter
>>>>    - bwdif_vulkan filter
>>>>    - nlmeans_vulkan filter
>>>>    - RivaTuner video decoder
>>>>    - xfade_vulkan filter
>>>>    - vMix video decoder
>>>>    - Essential Video Coding parser, muxer and demuxer
>>>>    - Essential Video Coding frame merge bsf
>>>>    - bwdif_cuda filter
>>>>    - Microsoft RLE video encoder
>>>>    - Raw AC-4 muxer and demuxer
>>>>    - Raw VVC bitstream parser, muxer and demuxer
>>>>    - Bitstream filter for editing metadata in VVC streams
>>>>    - Bitstream filter for converting VVC from MP4 to Annex B
>>>>    - scale_vt filter for videotoolbox
>>>>    - transpose_vt filter for videotoolbox
>>>>    - support for the P_SKIP hinting to speed up libx264 encoding
>>>>    - Support HEVC,VP9,AV1 codec in enhanced flv format
>>>>    - apsnr and asisdr audio filters
>>>>    - OSQ demuxer and decoder
>>>>    - Support HEVC,VP9,AV1 codec fourcclist in enhanced rtmp protocol
>>>>    - CRI USM demuxer
>>>>    - ffmpeg CLI '-top' option deprecated in favor of the setfield
>>>>    filter
>>>>    - VAAPI AV1 encoder
>>>>    - ffprobe XML output schema changed to account for multiple
>>>>    variable-fields elements within the same parent element
>>>>    - ffprobe -output_format option added as an alias of -of
>>>>
>>>> This release had been overdue for at least half a year, but due to
>>>> constant activity in the repository, had to be delayed, and we were finally
>>>> able to branch off the release recently, before some of the large changes
>>>> scheduled for 7.0 were merged.
>>>>
>>>> Internally, we have had a number of changes too. The FFT, MDCT, DCT and
>>>> DST implementation used for codecs and filters has been fully replaced with
>>>> the faster libavutil/tx (full article about it coming soon).
>>>> This also led to a reduction in the the size of the compiled binary,
>>>> which can be noticeable in small builds.
>>>> There was a very large reduction in the total amount of allocations
>>>> being done on each frame throughout video decoders, reducing overhead.
>>>> RISC-V optimizations for many parts of our DSP code have been merged,
>>>> with mainly the large decoders being left.
>>>> There was an effort to improve the correctness of timestamps and frame
>>>> durations of each packet, increasing the accurracy of variable frame rate
>>>> video.
>>>>
>>>> Next major release will be version 7.0, scheduled to be released in
>>>> February. We will attempt to better stick to the new release schedule we
>>>> announced at the start of this year.
>>>>
>>>> We strongly recommend users, distributors, and system integrators to
>>>> upgrade unless they use current git master.
>>>>
>>>>
>>>>
>>>> =====
>>>>
>>>>
>>>> on last line here .. yeah, "we break API, deal with it" in small
>>>> invisible text ...... Well, actually THIS TIME it was not broken  too
>>>> badly, but with upcoming 7.x ...... who knows! Previous history tells me it
>>>> more likely than not.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20231111/faf3157b/attachment-0001.htm>


More information about the Cin mailing list