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

[Michael Niedermayer]

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.
---


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080507/492316fd/attachment.pgp>