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

[Baptiste Coudurier]

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.

Currently, compute_pkt_fields with flv with screw dts up:

if(pkt->pts != AV_NOPTS_VALUE && pkt->dts != AV_NOPTS_VALUE &&
    pkt->dts > pkt->pts && st->pts_wrap_bits<63
       /*&& pkt->dts-(1LL<<st->pts_wrap_bits) < pkt->pts*/){
        pkt->dts -= 1LL<<st->pts_wrap_bits;
}

because: av_set_pts_info(st, 24, 1, 1000); /* 24 bit pts in ms */
(this should be changed to 32 though, but we can put 64, and problem
will be gone)

However when stream copying, muxing will choke with "error, pts < dts"

What should we do about this ? Manually add delay ?

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h264_aac_flv_demux.patch
Type: text/x-diff
Size: 3845 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080507/89ca6d8e/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h264_aac_flv_mux.patch
Type: text/x-diff
Size: 5612 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080507/89ca6d8e/attachment-0001.patch>