Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 5/6] avformat/movenc: utilize existing AC-3 parsing workflow for AC-3
Date: Tue, 21 Jun 2022 09:30:34 +0200
Message-ID: <DB6PR0101MB22145A752C47A677ADB8BCFE8FB39@DB6PR0101MB2214.eurprd01.prod.exchangelabs.com> (raw)
In-Reply-To: <CAEu79SZNo8URGJkNhs5fo0XAb=90MKpJ5tTkg-QzebZU3Xss7w@mail.gmail.com>

Jan Ekström:
> On Mon, Jun 20, 2022 at 12:10 PM Andreas Rheinhardt
> <andreas.rheinhardt@outlook.com> wrote:
>>
>> Jan Ekström:
>>> From: Jan Ekström <jan.ekstrom@24i.com>
>>>
>>> Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
>>> ---
>>>  libavformat/Makefile          |  1 +
>>>  libavformat/ac3_bitrate_tab.c | 22 ++++++++++++++
>>>  libavformat/movenc.c          | 55 +++++++++++++++++------------------
>>>  3 files changed, 50 insertions(+), 28 deletions(-)
>>>  create mode 100644 libavformat/ac3_bitrate_tab.c
>>>
>>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>>> index 1416bf31bd..c71de95b2f 100644
>>> --- a/libavformat/Makefile
>>> +++ b/libavformat/Makefile
>>> @@ -699,6 +699,7 @@ SHLIBOBJS-$(CONFIG_FLV_MUXER)            += mpeg4audio_sample_rates.o
>>>  SHLIBOBJS-$(CONFIG_HLS_DEMUXER)          += ac3_channel_layout_tab.o
>>>  SHLIBOBJS-$(CONFIG_MATROSKA_DEMUXER)     += mpeg4audio_sample_rates.o
>>>  SHLIBOBJS-$(CONFIG_MOV_DEMUXER)          += ac3_channel_layout_tab.o
>>> +SHLIBOBJS-$(CONFIG_MOV_MUXER)            += ac3_bitrate_tab.o
>>>  SHLIBOBJS-$(CONFIG_MP3_MUXER)            += mpegaudiotabs.o
>>>  SHLIBOBJS-$(CONFIG_MXF_MUXER)            += golomb_tab.o
>>>  SHLIBOBJS-$(CONFIG_NUT_MUXER)            += mpegaudiotabs.o
>>
>> The above line only takes care of duplicating ac3_bitrate_tab.o into
>> lavf for shared builds; yet there needs to be a corresponding STLIBOBJS
>> entry in lavc/Makefile so that lavc/ac3_bitrate_tab.o is compiled in
>> case the mov muxer is enabled in a static build.
>> It would work either way in this case because #2 made the mov muxer
>> depend upon the ac3 parser which makes lavc/ac3_bitrate_tab.o be included.
>>
> 
> OK, then I clearly missed something since I thought I was following
> how you had done things earlier for the other table. Will look into
> this tomorrow morning.
> 
>>> diff --git a/libavformat/ac3_bitrate_tab.c b/libavformat/ac3_bitrate_tab.c
>>> new file mode 100644
>>> index 0000000000..57b6181511
>>> --- /dev/null
>>> +++ b/libavformat/ac3_bitrate_tab.c
>>> @@ -0,0 +1,22 @@
>>> +/*
>>> + * AC-3 bit rate table
>>> + * copyright (c) 2001 Fabrice Bellard
>>> + *
>>> + * This file is part of FFmpeg.
>>> + *
>>> + * FFmpeg is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Lesser General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2.1 of the License, or (at your option) any later version.
>>> + *
>>> + * FFmpeg is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>> + * Lesser General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Lesser General Public
>>> + * License along with FFmpeg; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
>>> + */
>>> +
>>> +#include "libavcodec/ac3_bitrate_tab.h"
>>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>>> index 103f958d75..a071f1cdd5 100644
>>> --- a/libavformat/movenc.c
>>> +++ b/libavformat/movenc.c
>>> @@ -36,6 +36,7 @@
>>>  #include "av1.h"
>>>  #include "avc.h"
>>>  #include "libavcodec/ac3_parser_internal.h"
>>> +#include "libavcodec/ac3tab.h"
>>>  #include "libavcodec/dnxhddata.h"
>>>  #include "libavcodec/flac.h"
>>>  #include "libavcodec/get_bits.h"
>>> @@ -362,44 +363,42 @@ struct eac3_info {
>>>
>>>  static int mov_write_ac3_tag(AVFormatContext *s, AVIOContext *pb, MOVTrack *track)
>>>  {
>>> -    GetBitContext gbc;
>>> +    struct eac3_info *info = track->eac3_priv;
>>> +    int8_t ac3_bit_rate_code = -1;
>>>      PutBitContext pbc;
>>>      uint8_t buf[3];
>>> -    int fscod, bsid, bsmod, acmod, lfeon, frmsizecod;
>>>
>>> -    if (track->vos_len < 7) {
>>> +    if (!info || !info->ec3_done) {
>>>          av_log(s, AV_LOG_ERROR,
>>>                 "Cannot write moov atom before AC3 packets."
>>>                 " Set the delay_moov flag to fix this.\n");
>>>          return AVERROR(EINVAL);
>>>      }
>>>
>>> -    avio_wb32(pb, 11);
>>> -    ffio_wfourcc(pb, "dac3");
>>> +    for (unsigned int i = 0; i < FF_ARRAY_ELEMS(ff_ac3_bitrate_tab); i++) {
>>> +        if (info->data_rate == ff_ac3_bitrate_tab[i]) {
>>> +            ac3_bit_rate_code = i;
>>
>> Anyway, I see that you use ff_ac3_bitrate_tab in lavf instead of adding
>> the frame_size_code to AC3HeaderInfo. Did it turn out to be easier this
>> way or what is the reason for this?
> 
> I did partially go through the reasoning in the cover letter, but
> here's a short rewording:
> 
> 1. This way doesn't extend the semi-public avpriv.
> 2. While reviewing I noticed that bsid 9, 10 streams (apparently some
> RealAudio fork of AC-3) actually have the sample/bit rate values bit
> shifted (divided by either 2 or 4). The table in the ETSI
> specification is based on the effective bit rate. While it is highly
> unlikely that someone would put that type of AC-3 into MP4, In that
> case I'd then have to re-index the value based on the effective bit
> rate instead of just taking the value from the bit stream in the
> parser. So as the effective bit rate is already available through the
> header parser, it just seems simpler to have the re-indexing happen on
> the using side in this case.
> 

I have to admit not to get this point at all. Let's work through an
example: You have bsid 10 and you use ff_ac3_bitrate_tab[17] (i.e. 576).
AC3HeaderInfo.bit_rate will then contain 144000 (i.e. the value is
already divided by four). Your data_rate will be set to 144 based upon
this (if there is no higher datarate already encountered). But there is
no entry for 144 in ff_ac3_bitrate_tab, so that one will enter the "No
valid AC3 bit rate code for data rate" branch. Is this intended?

- Andreas
_______________________________________________
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:[~2022-06-21  7:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-17 13:04 [FFmpeg-devel] [PATCH 0/6 v2] avformat/movenc: normalize on AC-3 parser usage Jan Ekström
2022-06-17 13:04 ` [FFmpeg-devel] [PATCH 1/6] avcodec: make AC-3 bit rate table available in a separate header Jan Ekström
2022-06-17 13:04 ` [FFmpeg-devel] [PATCH 2/6] {configure, avformat/movenc}: enable AC-3 parser for movenc Jan Ekström
2022-06-17 13:04 ` [FFmpeg-devel] [PATCH 3/6] avformat/movenc: enable handle_eac3 to handle AC-3 tracks Jan Ekström
2022-06-17 13:04 ` [FFmpeg-devel] [PATCH 4/6] avformat/movenc: move eac3_info definition so that it can be used for AC-3 Jan Ekström
2022-06-17 13:04 ` [FFmpeg-devel] [PATCH 5/6] avformat/movenc: utilize existing AC-3 parsing workflow " Jan Ekström
2022-06-20  9:10   ` Andreas Rheinhardt
2022-06-20 14:26     ` Jan Ekström
2022-06-21  7:30       ` Andreas Rheinhardt [this message]
2022-06-21 14:34         ` Jan Ekström
2022-06-21 22:05           ` Andreas Rheinhardt
2022-06-22  6:54             ` Jan Ekström
2022-06-17 13:04 ` [FFmpeg-devel] [PATCH 6/6] avformat/movenc: handle OOM situations when parsing AC-3 headers Jan Ekström
2022-06-20  7:19 ` [FFmpeg-devel] [PATCH 0/6 v2] avformat/movenc: normalize on AC-3 parser usage Jan Ekström
  -- strict thread matches above, loose matches on Subject: below --
2022-06-03 12:46 [FFmpeg-devel] [PATCH 0/6] " Jan Ekström
2022-06-03 12:46 ` [FFmpeg-devel] [PATCH 5/6] avformat/movenc: utilize existing AC-3 parsing workflow for AC-3 Jan Ekström

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=DB6PR0101MB22145A752C47A677ADB8BCFE8FB39@DB6PR0101MB2214.eurprd01.prod.exchangelabs.com \
    --to=andreas.rheinhardt@outlook.com \
    --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