[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