From: Marton Balint <cus@passwd.hu>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v2 4/5] avutil/channel_layout: add av_channel_layout_retype()
Date: Thu, 1 Feb 2024 21:36:31 +0100 (CET)
Message-ID: <46247782-1fde-d0e3-23b8-2b3180b1d780@passwd.hu> (raw)
In-Reply-To: <170677812437.8914.7666506536395922524@lain.khirnov.net>
On Thu, 1 Feb 2024, Anton Khirnov wrote:
> Quoting Marton Balint (2024-02-01 00:01:36)
>> diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
>> index 37629ab5d2..7e27a00d39 100644
>> --- a/libavutil/channel_layout.h
>> +++ b/libavutil/channel_layout.h
>> @@ -817,6 +817,17 @@ int av_channel_layout_check(const AVChannelLayout *channel_layout);
>> */
>> int av_channel_layout_compare(const AVChannelLayout *chl, const AVChannelLayout *chl1);
>>
>> +/**
>> + * Try changing the AVChannelOrder of a channel layout.
>
> What exactly is the rule for when the change succeeds or not? I would
> expect it to be when all the channels can be represented in the new
> order, but that is not the case for conversion to unspec.
Yes, you are right. Converting to unspec indeed makes you lose the
channel designations, so the conversion will not be lossless. On the other
hand, when you specify UNSPEC as a target, you don't actually expect to
keep the designations, so what is the point of returning an error...
I think this is one of those cases when both behaviour (always doing the
conversion, or returning a failure in case the source order is not already
unspec) can make sense. We have to decide though if a custom layout with
all channels as UNKNOWN can be losslessly converted to UNSPEC layout or
not. And if yes, then would not that conflict with
av_channel_layout_channel_from_index() which returns AV_CHAN_NONE and not
AV_CHAN_UNKNOWN for UNSPEC layouts...
So if you have a preference, I can change this (and document it), I don't
particularly feel strongly about any of the two approaches. Probably there
is no bad choce as long as it is properly documented.
>
>> + *
>> + * @param channel_layout channel layout which will be changed
>> + * @param order the desired channel layout order
>> + * @return 0 on success or if the channel layout is already in the desired order
>> + * 1 if using the desired order is not possible for the specified layout
>
> AVERROR(ENOSYS) seems more consistent to me
By using a positive result all negative return values can be considered
serious errors which have to be propagated back to the user.
In the next patch I try to simplify a custom channel layout:
+ ret = av_channel_layout_retype(ch_layout, AV_CHANNEL_ORDER_NATIVE);
+ if (ret < 0)
+ goto out;
I can do simply this, because I don't care if the simplification was
successful.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-02-01 20:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 23:27 [FFmpeg-devel] [PATCH 1/5] avformat/mov_chan: do not assume channels are in native order Marton Balint
2024-01-29 23:27 ` [FFmpeg-devel] [PATCH 2/5] avformat/mov_chan: never override number of channels based on chan atom Marton Balint
2024-01-29 23:27 ` [FFmpeg-devel] [PATCH 3/5] avutil/channel_layout: add av_channel_layout_from_custom() Marton Balint
2024-02-01 8:56 ` Anton Khirnov
2024-02-01 20:01 ` Marton Balint
2024-02-02 4:42 ` Anton Khirnov
2024-01-29 23:27 ` [FFmpeg-devel] [PATCH 4/5] avutil/channel_layout: add av_channel_layout_retype() Marton Balint
2024-01-31 23:01 ` [FFmpeg-devel] [PATCH v2 " Marton Balint
2024-02-01 9:02 ` Anton Khirnov
2024-02-01 20:36 ` Marton Balint [this message]
2024-02-03 16:19 ` Anton Khirnov
2024-02-02 12:56 ` [FFmpeg-devel] [PATCH " James Almer
2024-02-03 10:38 ` Anton Khirnov
2024-02-03 13:24 ` James Almer
2024-02-04 19:28 ` [FFmpeg-devel] [PATCH v2 3/5] avutil/channel_layout: add av_channel_layout_custom_init() Marton Balint
2024-02-04 19:28 ` [FFmpeg-devel] [PATCH v2 4/5] avutil/channel_layout: add av_channel_layout_retype() Marton Balint
2024-02-09 15:10 ` Anton Khirnov
2024-02-11 22:38 ` Marton Balint
2024-02-11 22:51 ` James Almer
2024-02-11 23:03 ` Marton Balint
2024-02-04 19:28 ` [FFmpeg-devel] [PATCH v2 5/5] avformat/mov_chan: add support for reading custom channel layouts when layout_tag == 0 Marton Balint
2024-02-08 20:16 ` [FFmpeg-devel] [PATCH v3 " Marton Balint
2024-01-29 23:27 ` [FFmpeg-devel] [PATCH " Marton Balint
2024-02-08 19:25 ` [FFmpeg-devel] [PATCH 1/5] avformat/mov_chan: do not assume channels are in native order Marton Balint
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46247782-1fde-d0e3-23b8-2b3180b1d780@passwd.hu \
--to=cus@passwd.hu \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git