[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