[FFmpeg-devel] [PATCH 38/42] fftools/ffmpeg: add support for multiview video

[James Almer]

On 9/3/2024 9:44 AM, Anton Khirnov wrote:
> Quoting James Almer (2024-09-03 14:26:21)
>> On 9/3/2024 6:47 AM, Anton Khirnov wrote:
>>> Quoting James Almer (2024-08-31 15:56:24)
>>>> On 8/31/2024 4:44 AM, Anton Khirnov wrote:
>>>>> Quoting James Almer (2024-08-30 02:40:49)
>>>>>> On 8/29/2024 8:26 PM, Michael Niedermayer wrote:
>>>>>>> On Tue, Aug 27, 2024 at 05:05:18PM +0200, Anton Khirnov wrote:
>>>>>>>> This extends the syntax for specifying input streams in -map and complex
>>>>>>>> filtergraph labels, to allow selecting a view by view ID, index, or
>>>>>>>> position. The corresponding decoder is then set up to decode the
>>>>>>>> appropriate view and send frames for that view to the correct
>>>>>>>> filtergraph input(s).
>>>>>>>> ---
>>>>>>>>      doc/ffmpeg.texi           |  30 +++-
>>>>>>>>      fftools/cmdutils.c        |   2 +-
>>>>>>>>      fftools/cmdutils.h        |   2 +
>>>>>>>>      fftools/ffmpeg.h          |  45 ++++-
>>>>>>>>      fftools/ffmpeg_dec.c      | 355 +++++++++++++++++++++++++++++++++++++-
>>>>>>>>      fftools/ffmpeg_demux.c    |  24 ++-
>>>>>>>>      fftools/ffmpeg_filter.c   |  71 +++++---
>>>>>>>>      fftools/ffmpeg_mux_init.c |  29 +++-
>>>>>>>>      fftools/ffmpeg_opt.c      |  70 +++++++-
>>>>>>>>      9 files changed, 575 insertions(+), 53 deletions(-)
>>>>>>>
>>>>>>> breaks build on mingw64
>>>>>>>
>>>>>>> src/fftools/ffmpeg_dec.c: In function ‘packet_decode’:
>>>>>>> src/fftools/ffmpeg_dec.c:811:19: error: implicit declaration of function ‘ffs’ [-Werror=implicit-function-declaration]
>>>>>>>       811 |             pos = ffs(outputs_mask) - 1;
>>>>>>>           |                   ^~~
>>>>>>> cc1: some warnings being treated as errors
>>>>>>> make: *** [src/ffbuild/common.mak:81: fftools/ffmpeg_dec.o] Error 1
>>>>>>> make: *** Waiting for unfinished jobs....
>>>>>>>
>>>>>>> thx
>>>>>>
>>>>>> Would ff_clz(outputs_mask) work here?
>>>>>
>>>>> In principle yes, but it's private and I'd rather not include a private
>>>>> header in ffmpeg CLI.
>>>>>
>>>>> We could either make it public, or I could add a ffs() implementation
>>>>> for Windows to compat/. Anyone has a preference?
>>
>> Also, ffs() is posix. Is Windows the only target that lacks it?
> 
> I think so, though I didn't test all that extensively.
> 
>>>>
>>>> I think i prefer making ff_clz public in common.h.
>>>
>>> common.h is the wrong place for anything
>>>
>>>> It has an optimized version not exclusive to Windows using a gcc/clang
>>>> builtin, and even one specific for riscv.
>>>
>>> Which would not be visible to ffmpeg CLI anyway.
>>
>> True. We could make it aware of it by setting HAVE_AV_CONFIG_H during
>> compilation, but that's kinda dirty.
> 
> Yuck.
> 
> If we wanted to be fancy, we could add stdc_first_trailing_zero() from
> C23. Possibly write/steal compatibility wrappers like we did for
> atomics.

I prefer this over ffs() in compat/windows, yes. Good idea.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240903/124ae14a/attachment.sig>