[FFmpeg-devel] [PATCH]E-AC-3 over HDMI

[Anssi Hannula]

Carl Eugen Hoyos kirjoitti torstai, 24. kes?kuuta 2010 22:31:25:
> New patch attached, please comment (if nobody comments, I will consider
> adding myself as maintainer).

Tested it and it worked, but a few comments below.

> About TrueHD and DTS-HD: Is there anybody on this list who can compile and
> use ffdshow-tryout? Please mail me.

Not me. They perform some interesting gymnastics with TrueHD, but if I
interpreted correctly, they are effectively sending 24 concatenated frames
per a 61400-offset block, with the blanks actually distributed between the
concatenated frames instead of being in the end of the whole block, and
adding some extra headers to the beginning, end and in the middle of the
block.

They have some interesting frames-and-blanks-overflowing-to-next-packet
stuff there, I wonder if all that can be avoided just by aligning the 24
frames exactly to the block, as AFAICS they fit perfectly.

Also there's still the problem that according to HDMI standard one has to
use a different kind of audio packet (HBR, which is same as normal with
some bits flipped) for the compressed audio that doesn't fit in a single
IEC60958 channel. I guess we should inquire the ALSA people about this,
we'd need some mode that lets us pass the packets unmodified to HBR
packets. Or if the receivers are forgiving enough that it doesn't have to
be in a HBR, we'd probably want a way anyway to pass the packets
unmodified to the regular audio sample packets (normally the channels are
remapped) so that no pre-mangling for the channel remapping is needed.

> Index: libavformat/spdif.c
> ===================================================================
> --- libavformat/spdif.c       (revision 23733)
> +++ libavformat/spdif.c       (working copy)
[...]
> +static int spdif_header_eac3(AVFormatContext *s, AVPacket *pkt)
> +{
> +    IEC958Context *ctx = s->priv_data;
> +    int repeat, bitstream_mode = pkt->data[6] & 0x7;

bitstream_mode is not there in E-AC-3. It is actually quite deep in the
headers, they'd have to be practically completely parsed (it is
encountered around 100 lines into our ff_eac3_parse_header) to get.

I'd think that it would not be really used by A/V receivers.. but I guess
it is possible for a receiver to have some special mode depending on if
the content is music/effects or dialogue or whatever, so maybe we should
implement it anyway, I don't know. But only if it is confirmed that the
IEC 61937-3 really specifies one for E-AC-3 as well.

> +    if (s->streams[0]->codec->bit_rate <= 384000) {
> +        repeat = 1;
> +    } else if (s->streams[0]->codec->bit_rate <= 768000) {
> +        repeat = 2;
> +    } else
> +        repeat = 6;

Interesting. The number of needed repeats is affected by the amount PCM
samples produced by single packet (see my message in the "Add data_types
for EAC3" thread), not the codec bitrate. Is the bit_rate guaranteed to
correlate with this? And it seems the case 'repeat = 3' is missing, which
is AFAICS needed if there are 2 * 256 PCM samples produced per packet,
which is an allowed mode in E-AC-3.

I'd make it something like this (tested):

static const uint8_t eac3_repeat[4] = {
    6, 3, 2, 1
};
    int repeat = 1;
    if ((pkt->data[4] & 0xc0) != 0xc0) /* fscod */
        repeat = eac3_repeat[(pkt->data[4] & 0x30) >> 4]; /* numblkscod */

[...]
>  static int spdif_write_packet(struct AVFormatContext *s, AVPacket *pkt)
>  {
[...]
> +    ctx->pkt_size = FFALIGN(frame_size, 2) << 3;

This overflows with E-AC-3 bitrates above 2 Mbps (wikipedia says the max
is 6.144 Mbps, which matches the bandwidth of the 192kHz iec60958 link).
I wonder if this is coded in bytes for E-AC-3, like TrueHD? Again, can't
confirm one way or another since my receiver doesn't seem to care.

(Actually, this may happen with AAC as well, which has offset = 16384 when
 aac_hdr.samlpes = 4096... but I'm not sure if there is some other
 (bitrate?) constraint in AAC which stops it from happening)

-- 
Anssi Hannula