[FFmpeg-devel] [PATCH] spdifenc: IEC 61937 encapsulation of DTS-HD for HDMI

[Anssi Hannula]

On 10.02.2011 23:38, Reimar D?ffinger wrote:
> On Sat, Jan 29, 2011 at 03:36:30AM +0200, Anssi Hannula wrote:
>> +/*
>> + * DTS type IV (DTS-HD) can be transmitted with various frame repetition
>> + * periods; longer repetition periods allow for longer packets and therefore
>> + * higher bitrate. Longer repetition periods mean that the constant bitrate of
>> + * the outputted IEC 61937 stream is higher.
>> + * The repetition period is measured in IEC 60958 frames (4 bytes).
>> + */
>> +enum {
>> +    DTS4_REP_PER_512   = 0x0,
>> +    DTS4_REP_PER_1024  = 0x1,
>> +    DTS4_REP_PER_2048  = 0x2,
>> +    DTS4_REP_PER_4096  = 0x3,
>> +    DTS4_REP_PER_8192  = 0x4,
>> +    DTS4_REP_PER_16384 = 0x5,
>> +};
>> +
>> +static int spdif_dts4_subtype(int period)
>> +{
>> +    switch (period) {
>> +    case 512:   return DTS4_REP_PER_512;
>> +    case 1024:  return DTS4_REP_PER_1024;
>> +    case 2048:  return DTS4_REP_PER_2048;
>> +    case 4096:  return DTS4_REP_PER_4096;
>> +    case 8192:  return DTS4_REP_PER_8192;
>> +    case 16384: return DTS4_REP_PER_16384;
>> +    }
>> +    return -1;
>> +}
> 
> That does seem a bit extreme code-amount wise for what it does
> (not ment as a serious objection).

Hmm, indeed, the enum could probably be omitted.

>> +        if (ctx->dtshd_fallback > 0)
>> +            ctx->dtshd_skip = sample_rate * ctx->dtshd_fallback / (blocks << 5);
>> +        else
>> +            /* skip permanently (-1) or just once (0) */
>> +            ctx->dtshd_skip = 1;
> 
> Uh, and what does the value 1 which is actually used at that point mean?

That comment refers to the dtshd_fallback values when that else block is
executed.. I admit it is a bit unclear, though.

>> +    ctx->hd_buf = av_fast_realloc(ctx->hd_buf, &ctx->hd_buf_size,
>> +                                  ctx->out_bytes);
>> +    if (!ctx->hd_buf)
>> +        return AVERROR(ENOMEM);
> 
> Huh? Do you really need to preserve the previous contents?

Good catch, I don't. This is a remnant from the truehd/e-ac-3 functions
that actually need to preserve them.

I'll post an updated patch shortly. Thanks a lot for you review :)

> Otherwise av_fast_malloc could be faster and comes without that
> memleak on fail.

-- 
Anssi Hannula