[FFmpeg-trac] #372(avformat:open): spdifenc does an output not correct

FFmpeg trac at avcodec.org
Sun Jul 31 17:06:53 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 naoya):

 Replying to [comment:2 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?
 If AVPacket.size is greater than AVPacket.data size in it.(However, this
 is a problem of the parser)
 Invalid IEC 61937 stream will out going.
 Check byte lengh of AVPacket.data and use that value.

 > {{{
 > +    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.
 I also think so.
 My DVD(only 10 samples) value is 6.

 > {{{
 > -    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.
 MPA function does not set ctx->length_code.
 I revert that code back to the original.

 > {{{
 > -    av_fast_malloc(&ctx->buffer, &ctx->buffer_size, ctx->out_bytes +
 > +        ctx->buffer = av_mallocz(ctx->out_bytes +
 > }}}
 > Memory leak, no?
 This will leak. add free function.

 Patch was updated.

Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/372#comment:4>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list