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

Baptiste Coudurier baptiste.coudurier
Fri May 23 21:20:35 CEST 2008

Hi Michael,

Michael Niedermayer wrote:
> On Thu, May 22, 2008 at 08:12:27PM -0700, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>> On Wed, May 07, 2008 at 04:39:05PM +0200, Baptiste Coudurier wrote:
>>>> 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.
>>> thanks
>>> I hope this draft is rejected, its insane.
>>> The problem is that the first dts in mov/mp4 is implicitly 0.
>>> Which doesnt work out because that just isnt always the case. Solution
>>> would be to specify this first dts.
>>> What they do is change the pts-dts offsets to signed so the pts are correct
>>> while the dts are no longer correct. (they also add various optional fields
>>> to allow one to guess the correct dts but optional == useless)
>>> The obvious implementation is to leave dts at AV_NOPTS_VALUE when there
>>> is a version 1 ctts. We could also attempt to guess the dts but this is
>>> not always possible. IP mpeg2 vs low delay IP mpeg2 being an example
>>> which is ambigous.
>> Well, I'll just let current code (ignore negative ctts) for mov/mp4 as is.
>> It seems a full H264 header parser is becoming really needed to
>> correctly compute pts (it seems gpac is good for raw h264 streams, it
>> handles bpyramid quite nicely).
>> In the meantime we can still generate flv with positive dts by adding
>> delay.
> yes
>> Demuxer still handles cts as signed, this should cause no real harm,
>> except maybe some user complaining and I think Im ok with this, it will
>> remind me to think of a correct and good solution ;)
> Iam strongly against any demuxer ever returning pts < dts for undamaged
> streams.

Thing is we would loose pts for streams we would create and I don't know
any other tool creating h264 flv, so this is sad IMHO...
This will make impossible stream copy to .mov/.mp4 for ex ...

> Could you split the pts unrelated code out? I think we could commit that

Sure, patch attached, and patch without pts handling attached too.

Can I change av_set_pts_info to 32 bits too ? Or do you want it set to
64 in all cases for demuxers ?

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: flv_pts.patch
Type: text/x-diff
Size: 1478 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080523/41cc72f5/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h264_flv2.patch
Type: text/x-diff
Size: 9906 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080523/41cc72f5/attachment-0001.patch>

More information about the ffmpeg-devel mailing list