On 11/04/2011 11:00 AM, Martin Storsjö wrote: > On Fri, 4 Nov 2011, Justin Ruggles wrote: > >> On 11/04/2011 09:25 AM, Martin Storsjö wrote: >> >>> From: Carl Eugen Hoyos <[email protected]> >>> >>> These packets are valid packets, and consist of 1 byte (which >>> contains the mode bits). >>> --- >>> libavformat/movenc.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c >>> index fb8749c..b7314dc 100644 >>> --- a/libavformat/movenc.c >>> +++ b/libavformat/movenc.c >>> @@ -2004,7 +2004,7 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket >>> *pkt) >>> if (enc->codec_id == CODEC_ID_AMR_NB) { >>> /* We must find out how many AMR blocks there are in one packet */ >>> static uint16_t packed_size[16] = >>> - {13, 14, 16, 18, 20, 21, 27, 32, 6, 0, 0, 0, 0, 0, 0, 0}; >>> + {13, 14, 16, 18, 20, 21, 27, 32, 6, 0, 0, 0, 0, 0, 0, 1}; >>> int len = 0; >>> >>> while (len < size && samplesInChunk < 100) { >> >> >> looks fine as long as our decoder can handle those 1-byte packets. > > IIRC it does, and that shouldn't really matter here either, since it's in > the muxer. Not sure if the opencore-amr encoder actually can output this > kind of packet, but you might run into it if stream copying AMR data from > somewhere else at least.
ah, i didn't notice that it was the muxer. patch ok. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
