[FFmpeg-devel] [PATCH] h264/aac in flv

[Baptiste Coudurier]

Michael Niedermayer wrote:
> On Wed, May 07, 2008 at 03:38:02PM +0200, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>> On Wed, May 07, 2008 at 12:36:42PM +0200, Baptiste Coudurier wrote:
>>>> Hi Michael,
>>>>
>>>> Michael Niedermayer wrote:
>>>>> On Tue, May 06, 2008 at 07:31:53PM +0200, Baptiste Coudurier wrote:
>>>>>> Michael Niedermayer wrote:
>>>>>>>>>>>> [...]
>>>>>>>>>>>>  
>>>>>>>>>>>>  static int get_audio_flags(AVCodecContext *enc){
>>>>>>>>>>>>      int flags = (enc->bits_per_sample == 16) ? FLV_SAMPLESSIZE_16BIT : FLV_SAMPLESSIZE_8BIT;
>>>>>>>>>>>>  
>>>>>>>>>>>> +    if (enc->codec_id == CODEC_ID_AAC) // specs force these parameters
>>>>>>>>>>>> +        return FLV_CODECID_AAC | FLV_SAMPLERATE_44100HZ | FLV_SAMPLESSIZE_16BIT | FLV_STEREO;
>>>>>>>>>>> Is this also correct for AAC streams for which these arent true? Or are
>>>>>>>>>>> such streams just not supported?
>>>>>>>>>>>
>>>>>>>>>> Streams are supported (like mp3 48khz btw), and play well. Like written,
>>>>>>>>>> specs mandates these values.
>>>>>>>>> I know but what about lets say 48khz AAC or 22khz AAC your code would mux this
>>>>>>>>> with a claimed samplerate of 44khz.
>>>>>>>>> Is such 22khz AAC and 48khz AAC legal in flv accoridng to spec or is just
>>>>>>>>> 44khz AAC allowed?
>>>>>>>>> If later then the muxer should reject AAC with samplerates differing from 
>>>>>>>>> 44khz.
>>>>>>>>>
>>>>>>>> Rofl:
>>>>>>>> "Sampling rate
>>>>>>>> For AAC: always 3"
>>>>>>>>
>>>>>>>> Is this ok for you ?
>>>>>>> Ive not doubted that this has to be set to 3. The question is if
>>>>>>> 48khz/22khz AAC is allowed in flv or not. If one takes the spec literally
>>>>>>> then the awnser is clearly no.
>>>>>> Well, I would say it is probably yes, considering aac and
>>>>>> AudioSpecificConfig.
>>>>>>
>>>>>>> But your muxer would store them blindly
>>>>>>> with a claimed sample rate of 44khz.
>>>>>> Well, what can I say ? It's not clearly mentioned.
>>>>>> I fear they used the same crap as mp4, AudioSpecificConfig mentions the
>>>>>> correct sample rate and channels number.
>>>>>> This is the case for channels too:
>>>>>>
>>>>>> "SoundType UB[1]
>>>>>> 0 = sndMono
>>>>>> 1 = sndStereo
>>>>>> Mono or stereo sound
>>>>>> For Nellymoser: always 0
>>>>>> For AAC: always 1"
>>>>>>
>>>>>> Im in favor of muxing this way.
>>>>> Iam ok with that if the official software also generates such 22/48khz AAC.
>>>>>
>>>> Updated patches considering signed ctts offset.
>>>>
>>>> Now there is a problem with timestamps, also with mov (which use signed
>>>> offsets), because pts can be < dts.
>>> dts is the time at which a packet enters the decoder
>>> pts is the time at which the correspoding decoded packet leaves the decoder
>>>
>>> Thus dts <= pts
>>>
>>>
>>> Also quoting  ISO/IEC 14496-12 Second edition 2005-04-01 Corrected version 2005-10-01:
>>> ---
>>> This box provides the offset between decoding time and composition time. Since decoding time must be less
>>>                                                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> than the composition time, the offsets are expressed as unsigned numbers such that CT(n) = DT(n) +
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>>> CTTS(n) where CTTS(n) is the (uncompressed) table entry for sample n.
>> FYI, this will be soon obsoleted by an amendment,
> 
> link?

Sent the draft I have on hands.

>> and Quicktime (.mov)
>> already uses negative ctts which generates pts < dts.
> 
> sample?

H264_negative_ctts.mov in incoming, generated by quicktime.

>> FLV use that too, and it was confirmed.
>>
>> Now the point is not about quoting specs, it's about supporting files,
>> features and thus extending FFmpeg.
> 
> The definitions of pts and dts currently require pts >= dts.
> Thus if one assumes pts < dts would be valid then the definitons currently
> used must be invalid.

Probably, we must find an appropriate solution to deal with them.

>> What's the plan ? Patch rejected ?
> 
> Plan is to wait until someone provides a document explaining what pts<dts
> is supposed to mean. I dont see how we could support them before that even
> if we wanted.

I think some explanation are given in the draft.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA