[Ffmpeg-devel] [PATCH] DVR-MS probe audio format - was DVR-MS bug (MP2 decoding)

Michael Niedermayer michaelni
Tue Mar 20 19:52:11 CET 2007


Hi

On Tue, Mar 20, 2007 at 12:24:17PM -0500, John Donaghy wrote:
> Thanks for the comments.
> 
> including a random mp3 related header from libavcodec in libavformat/utils.c
> >is something i would like to avoid, please remove this
> >also isnt the frame size from the asf-wav header correct?
> 
> 
> I need that header in order to be able to set the frame_size to
> MPA_FRAME_SIZE if it's MP2. I wont know if it is MP2 or AC3 until this point
> so I'm not sure how else to do it.

no you dont need the header to set the frame size to 1152
also its better if you dont set it at all, 1152 is not always correct


[...]
> >+                if (mp3_read_probe(pd) > 1) {
> >> +                    st->codec->codec_id = CODEC_ID_MP3;
> >> +                    st->codec->frame_size = MPA_FRAME_SIZE;
> >> +                } else if (ac3_probe(pd) > 1){
> >> +                    st->codec->codec_id = CODEC_ID_AC3;
> >
> >> +                    st->codec->frame_size = 1;
> >
> >this frame size is wrong
> 
> 
> Yes, I wasn't reading the asf demuxer code carefully enough. For
> CODEC_ID_AC3 I think it will set framesize to 1 via the 'default' limb of
> the case statement. Is that a bug in the asf demuxer then? Should I not set
> the frame_size here for AC3 at all?

either set frame size correct or dont set it, later is much easier
what asf sets frame_size to is irrelevant, the ac3 spec matters and i can
assure you ac3 frames are larger then 1 byte


> 
> >+                }
> >> +                st->codec->codec_tag =
> >codec_get_wav_tag(st->codec->codec_id);
> >
> >this is wrong you cannot just override codec_tag at will
> >also i dont see why that would be needed
> 
> 
> Well, in a dvr-ms file the audio stream header appears at the end of the
> extended stream header for the audio stream. This audio stream header is not
> the same as a normal audio stream header either. It has 64 bytes of unknown
> data followed by what appears to be a WAVEFORMATEX structure. Directly
> reading that structure using get_wav_header worked for a lot of SD samples
> with MP2 audio. Subsequently some samples appeared where the WAVEFORMATEX
> indicated MP2 yet the audio was AC3 (always from Australia for some reason).
> Also, in many other HD sampes, with AC3 audio, the wFormat tag field is set
> to '1' rather than 0x2000 as you might have expected. I dont know why this
> is the case and it could be that all the data in the header is entirely
> useless... if wFormat is wrong them maybe the other fields are wrong too.
> However, setting the tag at this point, and thus overriding what is in the
> stream header, is the only way I know of to get the audio to play in all
> cases. If you still dont think the code_tag should be set here do you have
> any suggestions about how to proceed?

remove line, and send a bugreport if it doesnt work (if ffmpeg/ffplay works
and mplayer doesnt the bug is likely in mplayer)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070320/de8283e4/attachment.pgp>



More information about the ffmpeg-devel mailing list