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

FFmpeg trac at avcodec.org
Wed Aug 10 16:06:54 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:5 anssi]:
 > Replying to [comment:4 naoya]:
 > > {{{+#ifndef AC3_HEADER_SIZE}}}
 > Is there a reason for the conditional here?
 #ifndef is not needed.

 > > {{{+ av_log(s, AV_LOG_ERROR, "Wrong AC3 file format\n");}}}
 > I think better would be "Invalid AC3 header\n" or similar
 I agree.
 By the same token, I think better would modify AAC&MPEG function.

 > > {{{+ av_log(s, AV_LOG_ERROR, "AC3 invalid num_blocks[%d]\n",
 hdr.num_blocks);}}}
 > I don't think non-6 values here are "invalid", just unsupported by the
 muxer. So I'd go for "AC3 num_blocks[%d] not supported for IEC-61937" or
 something.
 I agree.

 > Also, the leak was not fixed. Why not just keep av_fast_malloc() as it
 was previously?
 I had mistake.
 av_fast_malloc() has no problem.

 > Regarding the replacement of av_freep() with av_free(). The
 documentation says that av_freep() is recommended instead, but indeed in
 this case that doesn't make much sense since the structure is discarded
 anyway. Cehoyos, do you know what is the convention here?
 I understand.

 patch updated.

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


More information about the FFmpeg-trac mailing list