Can anyone help to tell me What's wrong with this clip?

[ruian.xu]

Hi:

I recorded this 3GP clip(H.263 video and AMR audio) with our proprietary encoder. However, it can not be played by QuickTime nor any other player on PC.

Debugging shows that there's something wrong with the Audio data stored in the file format.(I tried to disable audio, and it was playable.) Moreover, I got some warning before StormCodec refused 2 play it too(in the attachment).

Later, I found that Mplayer can play the video and report something about the problem with the audio(info attached).

Can anyone help me in finding out the problem with this file?

Thank you so much!

[Guest]

In the future please use an upload site for clips, rather than attaching them. Thank you.

[ruian.xu]

In the future please use an upload site for clips, rather than attaching them. Thank you.
Okay. Thanks!

[bond]

the file contains amr audio, which is allowed in 3gp. mplayer doesnt support amr audio so its not really useable for testing

[Gusar]

the file contains amr audio, which is allowed in 3gp. mplayer doesnt support amr audio so its not really useable for testingMPlayer does support amr audio. It just needs to be compiled in. Not sure if Celtic Druid's builds have it, but the CCCP mplayer build definitely does and should play the clip including audio.

[ruian.xu]

MPlayer does support amr audio. It just needs to be compiled in. Not sure if Celtic Druid's builds have it, but the CCCP mplayer build definitely does and should play the clip including audio.
I installed AMR-NB codec for MPlayer and so, MPlayer doesn't help now.

Do you know what's wrong with the file? QuickTime can not play it normally....

[Nicholi]

MPlayer itself needs to be built with the amr decoder, you can't just "install" libamr-nb and expect anything to work. However I noticed my older build was broken for amr decoding anyways. Here is a temp build (http://www.cccp-project.net/nichorai/mplayer-amrtest.7z) which actually connects with the amr-nb decoder. Though I only hear silence, it's a bit too short to know if anything is going on :). I tried playing it in ffplay with the amr decoders and was the same, just silent.

[ruian.xu]

MPlayer itself needs to be built with the amr decoder, you can't just "install" libamr-nb and expect anything to work. However I noticed my older build was broken for amr decoding anyways. Here is a temp build (http://www.cccp-project.net/nichorai/mplayer-amrtest.7z) which actually connects with the amr-nb decoder. Though I only hear silence, it's a bit too short to know if anything is going on :). I tried playing it in ffplay with the amr decoders and was the same, just silent.
Thanks a lot!

But I'm still wondering why MPlayer and ffplay can handle it while QuickTime doesn't? Is there anything in this file that does not conform to the File Format Specification?

[stegre]

Is your encoder putting in {99C00BDC-3BF1-4889-9873-F1178D3C5679} as an audio subtype, like that StormCodec.txt file says? I think you should try {726d6173-0000-0010-8000-00aa00389b71}. Thats the normal CLSID for 4cc "samr".

[stegre]

Ignore above post, I know exactly what your error is; it's strictly an structural "mathematical" count error - I'll explain in detail tonight when I get home, as I'm at work now (it's bad enough I was looking at your file instead of working! ;) So I'll write the post explaining it tonight. As a bonus, a related area, there's also a way you'll be able to make your files shorter without any loss of info, I'll explain that too....

[ruian.xu]

Hi, stegre, Thanks a lot for your help! And I anticipate your reply.

[stegre]

OK, here's what I've found so far (btw, I think I was wrong about that comment about making the file "shorter", but I believe I'm correct regarding these more important "errors"). All below numbers are decimal, not hex:

Regarding the audio, you have 23 samples, 1 per chunk, and 23 chunks. Each sample is 105 bytes, except the last, which is 42 bytes. The above info is derived from "stsc", "stco", and "stsz", which, as far as I can tell, seem consistent amongst themselves. But "stts" lists the total sample count as 22, which is a contradiction. It lists them in the compact form simply saying there are 22 samples of "identical duration" - but there's no additional entry following that for the last one (which I guess would require a separate entry because I guess it represents a shorter duration). I'm not sure how critical the actual value for the very last sample is, but having mismatched counts makes these decoders unhappy.

I believe you also have the same problem with the video - the table is more complex there; it has 39 as table entry count (not the sample count) - which is correct, and seems to correctly reflect that 39 table entries indeed follow. Each represents 1, 2 or 3 consecutive video samples. But I think if you add them up you fall one short there too - you get a total of 59 instead of the actual 60 video samples present.

I tried patching the hex file, by just increasing the audio count from 22 to 23, even though the last sample isn't really the same duration. I did the same with the video. I was hoping it would actually play in QT - it didn't, but that may be because these errors (or my patching) have other ramifications; it may need to be fixed at the source.

BUT - on the plus side, MPLAYER did appear to confirm what I'm saying above is true. Two of its four warnings went away when I ran it with the patched file. There's still another pair of warnings - something about "pts" - I don't know if that's related until I figure out what they're talking about when they say "pts" ;) So maybe there's still another problem, or maybe it's indirectly related to this. Anyway take a look and let me know what you think.

[ruian.xu]

Hi, stegre! I was also thinking about the two warnings MPlayr issued and I'm studying relevant code segments in the file writer. I'll let you know whether it works if correct values are used.
Thank you so much for your help!