The following files was reported to us by a user, we tested it with recent version of MPlayer and ffmpeg. MPlayer tries to use lavf, lavf says that no audio or video headers found. According to the user that reported it, it was grabbed with the Qtec s100 phone/pda (http://www.qtek.ch/DescriptionQtekS100FR.htm) and it works in Real Player. The file can be downloaded from http://www.cwi.nl/~boncz/test.mp4 <http://www.cwi.nl/%7Eboncz/test.mp4> Here is what MPlayer says: ==================== MPlayer dev-CVS-050928-16:38-3.4.2 (C) 2000-2005 MPlayer Team CPU: Intel Pentium 4/Xeon/Celeron Foster (Family: 8, Stepping: 9) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0 Compiled with runtime CPU detection - WARNING - this is not optimal! To get best performance, recompile MPlayer with --disable-runtime-cpudetection. c:/windows/fonts/arial.ttf doesn't look like a font description, ignoring. Cannot load font: c:/windows/fonts/arial.ttf Playing d:\testmedia\test.mp4. ISO: File Type Major Brand: 3GPP Profile 4 ISO: File Type Major Brand: 3GPP Profile 4 ID_VIDEO_ID=0 libavformat file format detected. LAVF: no audio or video headers found - broken file? Exiting... (End of file)

1: QTP 7 doesn't play it either. 2: VLC finds the ftyp box and then i says it found a box with size 0. 3: the next box appears to be a mdat box, with it's shortsize set to 0 which would mean that it's as long as the remainder of the file. 4: the moov box and track boxes seem to be stuck in a header at the end of file. I suspect a muxing error here. DJ damn you bill, you beat me to it :D Well at least we came to the same conclusion. On 27-jan-2006, at 21:31, M?ns Rullg?rd wrote:

Ronen Mizrahi <ronen at tversity.com> writes:

...

The following files was reported to us by a user, we tested it with recent version of MPlayer and ffmpeg. MPlayer tries to use lavf, lavf says that no audio or video headers found. According to the user that reported it, it was grabbed with the Qtec s100 phone/pda (http://www.qtek.ch/DescriptionQtekS100FR.htm) and it works in Real Player.

The file can be downloaded from http://www.cwi.nl/~boncz/test.mp4

Problem confirmed. Mike, time to show off your QT skills.

-- M?ns Rullg?rd mru at inprovide.com

_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Ronen Mizrahi wrote:

The following files was reported to us by a user, we tested it with recent version of MPlayer and ffmpeg. MPlayer tries to use lavf, lavf says that no audio or video headers found. According to the user that reported it, it was grabbed with the Qtec s100 phone/pda (http://www.qtek.ch/DescriptionQtekS100FR.htm) and it works in Real Player.

The file can be downloaded from http://www.cwi.nl/~boncz/test.mp4 <http://www.cwi.nl/%7Eboncz/test.mp4>

Here is what MPlayer says: ==================== MPlayer dev-CVS-050928-16:38-3.4.2 (C) 2000-2005 MPlayer Team CPU: Intel Pentium 4/Xeon/Celeron Foster (Family: 8, Stepping: 9) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0 Compiled with runtime CPU detection - WARNING - this is not optimal! To get best performance, recompile MPlayer with --disable-runtime-cpudetection.

c:/windows/fonts/arial.ttf doesn't look like a font description, ignoring. Cannot load font: c:/windows/fonts/arial.ttf Playing d:\testmedia\test.mp4. ISO: File Type Major Brand: 3GPP Profile 4 ISO: File Type Major Brand: 3GPP Profile 4 ID_VIDEO_ID=0 libavformat file format detected. LAVF: no audio or video headers found - broken file?

Exiting... (End of file)

I get ======== MPlayer dev-CVS-060125-05:13-4.0.3 (C) 2000-2006 MPlayer Team CPU: Advanced Micro Devices Sempron/Athlon MP/XP Thoroughbred; Duron Applebred ( Family: 6, Stepping: 0) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE Playing test.mp4. ISO: File Type Major Brand: 3GPP Profile 4 ISO: File Type Major Brand: 3GPP Profile 4 RAWDV file format detected. VIDEO: [DVSD] 720x480 24bpp 29.970 fps 0.0 kbps ( 0.0 kbyte/s) dvdsublang...test en dvdsublang...test en ========================================================================== Opening audio decoder: [libdv] Raw DV Audio Decoder Unknown/missing audio format -> no sound ADecoder init failed :( Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders Cannot find codec 'dvaudio' in libavcodec... ADecoder init failed :( ADecoder init failed :( Cannot find codec for audio format 0x56444152. Read DOCS/HTML/en/codecs.html! ========================================================================== ========================================================================== Trying to force video codec driver family ffmpeg... Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffdv] vfm: ffmpeg (FFmpeg DV decoder) ========================================================================== Audio: no sound Starting playback... VDec: vo config request - 720 x 480 (preferred colorspace: Planar 411P) Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] VDec: using Planar 411P as output csp (no 0) Movie-Aspect is undefined - no prescaling applied. SwScaler: BICUBIC scaler, from Planar 411P to Planar YV12 using MMX2 VO: [xv] 720x480 => 720x480 Planar YV12 AC EOB marker is absent pos=112 ======== (and that last line repeats, with varying values for pos, enough times to fill a ~160K text file). The video displays as simply a hash of large red, green and blue "pixels". Obviously this is still incorrect, but it is at least something different from what has been mentioned so far, which is why I'm posting this. The above is with the "vfm=ffmpeg," option in my config file. If I remove that, instead of [ffmpeg] and then [ffdv] the only indication of codec is given as [dshow]. The only apparently notable change to the output (ignoring the different format of the text produced) is in the colorspace received by the decoder; the video output does not appear to change at all. (For the record, none of my other config options have any bearing on decoding or demuxing - just on interface, processing, and output.) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.

-----Original Message----- From: elupus [mailto:elupus at ecce.se] Sent: den 27 januari 2006 23:26 To: 'FFMpeg development discussions and patches' Subject: RE: [Ffmpeg-devel] PATCH: make libavformat find codecid forAACstreams in matroska container.

...

-----Original Message----- From: Steve Lhomme [mailto:slhomme at divxcorp.com] Sent: den 27 januari 2006 20:16 To: FFMpeg development discussions and patches Subject: Re: [Ffmpeg-devel] PATCH: make libavformat find codecid for AACstreams in matroska container.

...

Hi,

Here is a small patch to allow libavformat to find the codec on AAC streams in matroska containers.

The defines for the AAC codec's are set like this,

#define MATROSKA_CODEC_ID_AUDIO_MPEG2 "A_AAC/MPEG2/" #define MATROSKA_CODEC_ID_AUDIO_MPEG4 "A_AAC/MPEG4/"

which isn't the full name for the codec's. I.e. it normally has some more extension to it like MAIN, LC...

Anyway, this patch fixes so that when the codec_id is compared to these defines, only the given length is compared (which I think was the original idea). I suppose some more information could be gotten from

elupus wrote: that extra

...

information, but I think this should be enough.

Cheers

/Joakim

I provided a patch that handles this and the codec private and also the new and simple A_AAC (everything is said in the codec private). But the patch was rejected (although factorizing that code means having FAAD support which is GPL).

You can find the code in the source releases of DrFFMPEG on SourceForge.

Took the liberty of finding this patch.. Stripped some of the compiler warning / int64 fixes away and I've not tried to compile it right now. Just a RFC for now.

/Joakim

Okey, cleaned out the patchs some more. Now it really should only contain the stuff concerning AAC in mkv's. I've only tested mkv's wich has extradata stored. I've not tested any mkv's where extradata is missing and is generated by the extra code. Seening as it is the same code as mplayer uses in it's demuxer, I'm fairly sure it should work. /Joakim

Okey, cleaned out the patchs some more. Now it really should only contain the stuff concerning AAC in mkv's. I've only tested mkv's wich has extradata stored. I've not tested any mkv's where extradata is missing and is generated by the extra code. Seening as it is the same code as mplayer uses in it's demuxer, I'm fairly sure it should work.

/Joakim

Okey, I apperently attached the wrong patch (before last fixes). I'm not sure about one change. It changes the local extradata variable from being a void* to an unsigned char (same as mkv uses internally). Makes more sense to me since it's used for adding extra extradata/modifying existing. Working with a unsigned char* is easier than a void*, atleast when working in bytes. Also noticed some redundant code in there. Vorbis codec duplicates it's extradata, even thou the extradata that is set in the mkv track is also copied to ffmpeg extradata location. /Joakim

Sigh.. (i'm getting annoyed with myself).. Noticed an error in the previous patch ( the untested part ). Swapped internal and normal samplerate in the sbr case. Now it hopefully should be completly correct. Maybe Steve Lhomme has some sample so we could test the generated extradata, otherwise it's still better than before as AAC's get's detected and extradata passed on. Cheers /Joakim

Hi, On 10/1/06, Diego Biurrun <diego at biurrun.de> wrote:

On Tue, Jan 31, 2006 at 07:43:19PM +0100, elupus wrote:

...

Sigh.. (i'm getting annoyed with myself).. Noticed an error in the previous patch ( the untested part ). Swapped internal and normal samplerate in the sbr case.

Now it hopefully should be completly correct.

Maybe Steve Lhomme has some sample so we could test the generated extradata, otherwise it's still better than before as AAC's get's detected and extradata passed on.

This patch does not apply cleanly anymore. Michael OKed a previous incarnation of this patch. If the patch is still relevant (and if Michael is still OK with it), please resend it. Also, please remove the trailing whitespace while you're at it.

Eplus, ping? -- With DADVSI (http://en.wikipedia.org/wiki/DADVSI), France finally has a lead on USA on selling out individuals right to corporations! Vive la France!