[FFmpeg-devel] [PATCH] MOV muxer : Add SoundDescriptionV2 support

Baptiste Coudurier baptiste.coudurier
Sat Nov 28 13:17:00 CET 2009


On 11/28/09 4:07 AM, Jai Menon wrote:
> On Sat, Nov 28, 2009 at 02:00:39AM -0800, Baptiste Coudurier wrote:
>> On 11/28/09 1:21 AM, Jai Menon wrote:
>>> On Sat, Nov 28, 2009 at 12:03:47AM -0800, Baptiste Coudurier wrote:
>>>> Hi,
>>>>
>>>> On 11/27/09 11:41 PM, Jai Menon wrote:
>>>
>>> [...]
>>>
>>>>> sounddescv2.patch
>>>>>
>>>>>
>>>>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>>>>> index ac6378c..36b156e 100644
>>>>> --- a/libavformat/movenc.c
>>>>> +++ b/libavformat/movenc.c
>>>>> @@ -405,13 +405,21 @@ static int mov_write_glbl_tag(ByteIOContext *pb, MOVTrack *track)
>>>>>   static int mov_write_audio_tag(ByteIOContext *pb, MOVTrack *track)
>>>>>   {
>>>>>       int64_t pos = url_ftell(pb);
>>>>> -    int version = track->mode == MODE_MOV&&
>>>>> +    int version;
>>>>> +
>>>>> +    if (track->mode == MODE_MOV&&
>>>>>           (track->audio_vbr ||
>>>>>            track->enc->codec_id == CODEC_ID_PCM_S32LE ||
>>>>> -         track->enc->codec_id == CODEC_ID_PCM_S24LE);
>>>>> +         track->enc->codec_id == CODEC_ID_PCM_S24LE)) {
>>>>> +        if (track->timescale>    UINT16_MAX)
>>>>> +            version = 2;
>>>>
>>>> The stsd v2 must always be used when timescale>   UINT16_MAX
>>>> regardless of codec.
>>>
>>> Yes, I agree, but right now I just dont have the time required to make
>>> samples, remux and test against quicktime. Maybe someone who requires
>>> this for other codecs can add it later?
>>
>> Well, by experience, half-baked solutions for specific codecs rot
>> forever in the codebase, so I would prefer avoiding it.
>
> I don't think this is that big of a problem. The patch itself would be
> trivial since it requires setting version outside of the current if
> block ->  ~2 line diff (unless I'm missing something). The issue as I
> mentioned earlier is that I don't have a QT pro license so I dont
> have the freedom to generate and test against a multitude of samples.
> Also, there is the lack of time ;) I'm sure someone who cares about
> other codecs will want to test it and maybe send a patch. But IMHO
> that shouldn't get in the way of patches which improve the over all
> situation.

Well, I'm glad you say it's trivial so it should be easy for you to 
implement it.

In the mean time I will add a test against sample rate and just fail.

Like I said, by experience, having an half baked solution is more 
harmful than having a clean failure.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-devel mailing list