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

[Michael Niedermayer]

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?


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

sample?


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


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

[...]
-- 
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/5bb34dc0/attachment.pgp>