[1/2] movenc: Set a correct packet size for AMR-NB mode 15, "no data"

Message ID 1320413121-75123-1-git-send-email-martin@martin.st
State Committed
Commit ed669c9becf9d03c25e78ee98c2e4de564b854fc
Headers show

Commit Message

Martin Storsjö Nov. 4, 2011, 1:25 p.m.
From: Carl Eugen Hoyos <cehoyos@ag.or.at>

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(-)

Comments

Justin Ruggles Nov. 4, 2011, 2:52 p.m. | #1
On 11/04/2011 09:25 AM, Martin Storsjö wrote:

> From: Carl Eugen Hoyos <cehoyos@ag.or.at>
> 
> 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.

-Justin
Martin Storsjö Nov. 4, 2011, 3 p.m. | #2
On Fri, 4 Nov 2011, Justin Ruggles wrote:

> On 11/04/2011 09:25 AM, Martin Storsjö wrote:
>
>> From: Carl Eugen Hoyos <cehoyos@ag.or.at>
>>
>> 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.

// Martin
Justin Ruggles Nov. 4, 2011, 3:05 p.m. | #3
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 <cehoyos@ag.or.at>
>>>
>>> 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

Patch

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) {