[FFmpeg-trac] #372(avformat:open): spdifenc does an output not correct
FFmpeg
trac at avcodec.org
Sun Jul 31 01:43:52 CEST 2011
#372: spdifenc does an output not correct
----------------------+-----------------------
Reporter: naoya | Owner:
Type: defect | Status: open
Priority: important | Component: avformat
Version: git | Resolution:
Keywords: spdifenc | Blocked By:
Blocking: | Reproduced: 0
Analyzed: 1 |
----------------------+-----------------------
Comment (by anssi):
I guess the intent for the AC3 and AAC changes is to discard garbage at
the end of AVPacket? I'm not sure if that should be handled, but I'm not
against it. cehoyos, what do you think?
{{{
+ ctx->pkt_offset = hdr.num_blocks * 256 << 2;
}}}
Do you have samples where hdr.num_blocks is not 6? IEC 61937-3 mandates a
repetition period of 6144 bytes for AC-3, and non-6 values here would
produce a different repetition period. If you don't have any samples, I'd
guess we should simply refuse to mux such AC-3 streams.
{{{
- ctx->length_code = FFALIGN(pkt->size, 2) << 3;
}}}
ctx->length_code is not set by every packetizer function, this causes 0 to
be written for some codecs.
{{{
- av_fast_malloc(&ctx->buffer, &ctx->buffer_size, ctx->out_bytes +
FF_INPUT_BUFFER_PADDING_SIZE);
+ ctx->buffer = av_mallocz(ctx->out_bytes +
FF_INPUT_BUFFER_PADDING_SIZE);
}}}
Memory leak, no?
--
Ticket URL: <http://avcodec.org/trac/ffmpeg/ticket/372#comment:2>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list