Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Nicolas Gaullier <nicolas.gaullier@cji.paris>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 4/6] avformat/wavdec: s337m support
Date: Fri, 17 Feb 2023 10:30:56 +0000
Message-ID: <MR1P264MB2483EACEA0088A53BBCB3E809BA19@MR1P264MB2483.FRAP264.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <372327565ea2381ee93a824dfbe72a13c2916518.camel@haerdin.se>

>> +#if CONFIG_S337M_DEMUXER
>> +    {"non_pcm_mode", "Chooses what to do with s337m",
>> OFFSET(non_pcm_mode), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, DEC, 
>> "non_pcm_mode"},
>> +    {"copy"        , "Pass s337m through unchanged", 0,
>> AV_OPT_TYPE_CONST, {.i64 = 0}, 0, 1, DEC, "non_pcm_mode"},
>> +    {"demux"       , "Demux s337m"                 , 0,
>> AV_OPT_TYPE_CONST, {.i64 = 1}, 0, 1, DEC, "non_pcm_mode"},
>> +#endif
>>      { NULL },
>>  };
>
>So default is to demux? Sounds OK and probably avoids eardrum destruction

Well, to be honest, I am not very comfortable with that.
The fact is, I fear that many users have scripts to mux wav/dolby_e into mxf outputs and they will be affected...
But I completely understand the ffmpeg logic to "always decode", as is done currently in wav files to probe dts or even spdif which is really the same thing as s337.
It does not seem reasonable to break this here.
And another point here in this latest edition on my patch serie is that the use of an existing AVOption makes it possible for users
to upgrade their command lines just now by adding the option : ignored in previous version, it will take effect the day they upgrade their ffmpeg version,
so the transition can be smooth...

>> +                            } else {
>> +                                av_log(s, AV_LOG_INFO, "Passing
>> through S337M data: codec will not be reported\n");
>> +                            }
>
>Perhaps the user should also be informed when S337m is demuxed rather than passed through?
>
>/Tomas

I could add a debug message if you think that could be helpful ?
I think I cannot add an INFO log as spdif and other probe-mecanisms are not verbose in current code.

Nicolas

_______________________________________________
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".

  reply	other threads:[~2023-02-17 10:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13 18:09 [FFmpeg-devel] [PATCH 0/6] wavdev: " Nicolas Gaullier
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 1/6] avformat/s337m: Split read_packet/get_packet Nicolas Gaullier
2023-02-16 10:36   ` Tomas Härdin
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 2/6] avformat/s337m: Consider container bit resolution Nicolas Gaullier
2023-02-16 10:36   ` Tomas Härdin
2023-02-17  9:44     ` Nicolas Gaullier
2023-02-21  9:47       ` Tomas Härdin
2023-02-21 10:43         ` Nicolas Gaullier
2023-02-22 10:07           ` Tomas Härdin
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 3/6] avformat/s337m: New ff_s337m_probe() Nicolas Gaullier
2023-02-16 10:36   ` Tomas Härdin
2023-02-17 10:12     ` Nicolas Gaullier
2023-02-21  9:41       ` Tomas Härdin
2023-02-21 10:57         ` Nicolas Gaullier
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 4/6] avformat/wavdec: s337m support Nicolas Gaullier
2023-02-16 10:36   ` Tomas Härdin
2023-02-17 10:30     ` Nicolas Gaullier [this message]
2023-02-21  9:53       ` Tomas Härdin
2023-02-21 12:30         ` Nicolas Gaullier
2023-02-22 10:10           ` Tomas Härdin
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 5/6] avformat/wavdec.c: Reindent after last commit Nicolas Gaullier
2023-02-13 18:09 ` [FFmpeg-devel] [PATCH 6/6] avformat/wavdec: Test s337m Nicolas Gaullier

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=MR1P264MB2483EACEA0088A53BBCB3E809BA19@MR1P264MB2483.FRAP264.PROD.OUTLOOK.COM \
    --to=nicolas.gaullier@cji.paris \
    --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