[FFmpeg-devel] [PATCH 2/3] avformat: add raw AC-4 demuxer
Andreas Rheinhardt
andreas.rheinhardt at gmail.com
Thu Mar 5 13:25:58 EET 2020
Paul B Mahol:
> On 3/5/20, Andreas Rheinhardt <andreas.rheinhardt at gmail.com> wrote:
>> Am 05.03.2020 um 00:05 schrieb James Almer:
>>> On 3/4/2020 7:51 PM, Paul B Mahol wrote:
>>>> On 3/4/20, James Almer <jamrial at gmail.com> wrote:
>>>>> On 3/4/2020 7:26 PM, Paul B Mahol wrote:
>>>>>> Signed-off-by: Paul B Mahol <onemda at gmail.com>
>>>>>> ---
>>>>>> libavformat/Makefile | 1 +
>>>>>> libavformat/ac4dec.c | 104
>>>>>> +++++++++++++++++++++++++++++++++++++++
>>>>>> libavformat/allformats.c | 1 +
>>>>>> 3 files changed, 106 insertions(+)
>>>>>> create mode 100644 libavformat/ac4dec.c
>>>>>>
>>>>>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>>>>>> index e0681058a2..b4e8d20e65 100644
>>>>>> --- a/libavformat/Makefile
>>>>>> +++ b/libavformat/Makefile
>>>>>> @@ -70,6 +70,7 @@ OBJS-$(CONFIG_AA_DEMUXER) += aadec.o
>>>>>> OBJS-$(CONFIG_AAC_DEMUXER) += aacdec.o apetag.o img2.o
>>>>>> rawdec.o
>>>>>> OBJS-$(CONFIG_AC3_DEMUXER) += ac3dec.o rawdec.o
>>>>>> OBJS-$(CONFIG_AC3_MUXER) += rawenc.o
>>>>>> +OBJS-$(CONFIG_AC4_DEMUXER) += ac4dec.o
>>>>>> OBJS-$(CONFIG_ACM_DEMUXER) += acm.o rawdec.o
>>>>>> OBJS-$(CONFIG_ACT_DEMUXER) += act.o
>>>>>> OBJS-$(CONFIG_ADF_DEMUXER) += bintext.o sauce.o
>>>>>> diff --git a/libavformat/ac4dec.c b/libavformat/ac4dec.c
>>>>>> new file mode 100644
>>>>>> index 0000000000..8c6e539409
>>>>>> --- /dev/null
>>>>>> +++ b/libavformat/ac4dec.c
>>>>>> @@ -0,0 +1,104 @@
>>>>>> +/*
>>>>>> + * RAW AC-4 demuxer
>>>>>> + * Copyright (c) 2019 Paul B Mahol
>>>>>> + *
>>>>>> + * 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 "libavutil/avassert.h"
>>>>>> +#include "libavutil/crc.h"
>>>>>> +#include "avformat.h"
>>>>>> +#include "rawdec.h"
>>>>>> +
>>>>>> +static int ac4_probe(const AVProbeData *p)
>>>>>> +{
>>>>>> + const uint8_t *buf = p->buf;
>>>>>> + int left = p->buf_size;
>>>>>> + int max_frames = 0;
>>>>>> +
>>>>>> + while (left > 7) {
>>>>>> + int size;
>>>>>> +
>>>>>> + if (buf[0] == 0xAC &&
>>>>>> + (buf[1] == 0x40 ||
>>>>>> + buf[1] == 0x41)) {
>>>>>> + size = (buf[2] << 8) | buf[3];
>>>>>> + if (size == 0xFFFF)
>>>>>> + size = 3 + (buf[4] << 16) | (buf[5] << 8) | buf[6];
>>>>>> + size += 4;
>>>>>> + if (buf[1] == 0x41)
>>>>>> + size += 2;
>>>>>> + max_frames++;
>>>>>> + left -= size;
>>>>>> + buf += size;
>>>>>> + } else {
>>>>>> + break;
>>>>>> + }
>>>>>> + }
>>>>>> +
>>>>>> + return FFMIN(AVPROBE_SCORE_MAX, max_frames * 7);
>>>>>> +}
>>>>>> +
>>>>>> +static int ac4_read_header(AVFormatContext *s)
>>>>>> +{
>>>>>> + AVStream *st;
>>>>>> +
>>>>>> + st = avformat_new_stream(s, NULL);
>>>>>> + if (!st)
>>>>>> + return AVERROR(ENOMEM);
>>>>>> +
>>>>>> + st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
>>>>>> + st->codecpar->codec_id = AV_CODEC_ID_AC4;
>>>>>> +
>>>>>> + return 0;
>>>>>> +}
>>>>>> +
>>>>>> +static int ac4_read_packet(AVFormatContext *s, AVPacket *pkt)
>>>>>> +{
>>>>>> + AVIOContext *pb = s->pb;
>>>>>> + int64_t pos;
>>>>>> + uint16_t sync;
>>>>>> + int ret, size;
>>>>>> +
>>>>>> + if (avio_feof(s->pb))
>>>>>> + return AVERROR_EOF;
>>>>>> +
>>>>>> + pos = avio_tell(s->pb);
>>>>>> + sync = avio_rb16(pb);
>>>>>
>>>>> If there are sync codes then it sounds like the proper thing to do is,
>>>>> much like with AC3, writing a trivial parser to assemble frames and then
>>>>> use ff_raw_audio_read_header() and ff_raw_read_partial_packet() here
>>>>> instead of custom functions.
>>>>
>>>> That is over complication for simple parsing like here.
>>>> Every raw packet have exact frame size set in bitstream.
>>>
>>> So does AC3, judging by how its parser assembles frames.
>>>
>>> An AVParser will let you resync after a bad seek, read frames in non
>>> seekable input like a pipe, read frames within badly muxed files,
>>> simplify the demuxer, etc, and is a matter of just looking for that
>>> 16bit sync code and assembling a frame. Essentially just re-implementing
>>> what you already did in ac4_probe().
>>>
>>
>> If it is intended that the actual AVPackets should not contain the
>> sync code and the size field at all, then this should be dropped in
>> the demuxer here (but then the demuxer actually needs to check for
>> sync codes and needs to handle resyncing itself). This will also mean
>> that memcpy of the data can be avoided; which is not so when relying
>> on a parser as the packet size is not chosen adaptively for the content.
>>
>> The decoder seems to allow both variants: With header and without
>> header. Is there a packetization that strips this header away? (And
>> what is actually contained in the last two bytes in case the sync code
>> is 0xAC41?)
>
> CRC word.
>
You seem to intend for there to be two forms of AC-4 packets (at least
your decoder tries to support both): The one with syncwords, size
field and CRC stripped away and another one where these elements are
still present. This immediately brings a few questions:
1. Can a stripped packet be mistaken for an unstripped one, i.e. is it
possible for the data after the header to begin with a syncword?
2. How reversible is stripping away the header and the CRC? Stripping
away the CRC is obviously irreversible unless we presume that the CRC
matches. But is stripping the size field away reversible (it is not
reversible if one is allowed to use the three byte size field if the
two byte size field would suffice)?
3. Are there any container that use the stripped version?
If the answer to the third question is no, then I don't think we
should create a new packetization of AC-4 and potentially incur the
first problem as well as the inability to retain CRCs for codec copy.
- Andreas
More information about the ffmpeg-devel
mailing list