DVR-MS bug (MP2 decoding)
Hi, A user sent us a DVR-MS file (ASF with MPEG-2 and MP2) that doesn't decode correctly in FFMPEG. The issue in DrFFMPEG (with some fixes in ASF submited on this list) is that the audio is not decoded at all. The video is decoded fine. In FFMPEG the files crashes very fast but not at the same place with the following gdb log: (gdb) run -i c:\test\divx\today.dvr-ms -vn test.wav Starting program: c:\Perso\Programmes\ffmpeg.cvs/ffmpeg_g.exe -i c:\test\divx\today.dvr-ms -vn test.wav gdb: do_initial_child_stuff: process 1336 gdb: kernel event for pid=1336 tid=1300 code=CREATE_PROCESS_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=EXCEPTION_DEBUG_EVENT) gdb: Target exception EXCEPTION_BREAKPOINT at 0x7c901230 gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=UNLOAD_DLL_DEBUG_EVENT) ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=LOAD_DLL_DEBUG_EVENT) gdb: child_resume.SetThreadContext: thread 1336.0x514 ContinueDebugEvent (cpid=1336, ctid=1300, DBG_CONTINUE); gdb: kernel event for pid=1336 tid=1300 code=EXCEPTION_DEBUG_EVENT) gdb: Target exception EXCEPTION_ACCESS_VIOLATION at 0x00524801 Program received signal SIGSEGV, Segmentation fault. mpeg_decode_mb (s=0x3d950, block=0x2) at mpeg12.c:1894 1894 block[0] = dc << (3 - s->intra_dc_precision); (gdb) bt #0 mpeg_decode_mb (s=0x3d950, block=0x2) at mpeg12.c:1894 #1 0x00525230 in mpeg_decode_slice (s1=0x3d950, mb_y=0, buf=0x23efe4, buf_size=101196) at mpeg12.c:2567 #2 0x00527942 in mpeg_decode_frame (avctx=0x3bf90, data=0x23f4d0, data_size=0x23f47c, buf=0x1500030 "", buf_size=101380) at mpeg12.c:3157 #3 0x00458612 in avcodec_decode_video (avctx=0x3bf90, picture=0x23f4d0, got_picture_ptr=0x23f47c, buf=0x1500030 "", buf_size=101380) at utils.c:946 #4 0x0040f44c in av_find_stream_info (ic=0x36790) at utils.c:1826 #5 0x00405c87 in opt_input_file (filename=0x0) at ffmpeg.c:2834 #6 0x00032422 in ?? () #7 0x00000000 in ?? () from #8 0x00000000 in ?? () from #9 0x0023f900 in ?? () #10 0x0023f8e4 in ?? () #11 0x7c90ee18 in strchr () from ntdll.dll #12 0x7c9106f0 in ntdll!RtlAppendStringToString () from ntdll.dll #13 0xffffffff in ?? () #14 0x7c9106eb in ntdll!RtlAppendStringToString () from ntdll.dll #15 0x77c2c3c9 in msvcrt!free () from C:\WINDOWS\system32\msvcrt.dll #16 0x00030000 in ?? () #17 0x40000060 in ?? () #18 0x77c2c3ce in msvcrt!free () from C:\WINDOWS\system32\msvcrt.dll #19 0x0000003c in ?? () #20 0x77c5fcc0 in msvcrt!_iob () #21 0x00000002 in ?? () #22 0x0023f6cc in ?? () #23 0x00000000 in ?? () from #24 0x00000000 in ?? () from #25 0x7c90ee18 in strchr () from ntdll.dll #26 0x0023f988 in ?? () #27 0x77c35c94 in msvcrt!_except_handler2 () from C:\WINDOWS\system32\msvcrt.dll (gdb) disass $pc-32 $pc+32 Dump of assembler code from 0x5247e1 to 0x524821: 0x005247e1 <mpeg_decode_mb+6625>: pusha 0x005247e2 <mpeg_decode_mb+6626>: pop %es 0x005247e3 <mpeg_decode_mb+6627>: add %al,(%eax) 0x005247e5 <mpeg_decode_mb+6629>: mov 0x1c74(%esi),%edx 0x005247eb <mpeg_decode_mb+6635>: add %edi,%eax 0x005247ed <mpeg_decode_mb+6637>: mov %eax,0x760(%esi,%ebx,4) 0x005247f4 <mpeg_decode_mb+6644>: sub %edx,%ecx 0x005247f6 <mpeg_decode_mb+6646>: mov 0xffffffcc(%ebp),%edi 0x005247f9 <mpeg_decode_mb+6649>: shl %cl,%eax 0x005247fb <mpeg_decode_mb+6651>: mov 0x1c88(%esi),%ecx 0x00524801 <mpeg_decode_mb+6657>: mov %ax,(%edi) 0x00524804 <mpeg_decode_mb+6660>: xor $0x1,%eax 0x00524807 <mpeg_decode_mb+6663>: cwtl 0x00524808 <mpeg_decode_mb+6664>: mov %eax,0xffffffbc(%ebp) 0x0052480b <mpeg_decode_mb+6667>: test %ecx,%ecx 0x0052480d <mpeg_decode_mb+6669>: mov $0x681780,%eax 0x00524812 <mpeg_decode_mb+6674>: jne 0x524819 <mpeg_decode_mb+6681> 0x00524814 <mpeg_decode_mb+6676>: mov $0x6816c0,%eax 0x00524819 <mpeg_decode_mb+6681>: mov 0xfffffff0(%ebp),%esi 0x0052481c <mpeg_decode_mb+6684>: mov 0x3c(%eax),%eax 0x0052481f <mpeg_decode_mb+6687>: mov 0x1c3c(%esi),%ebx When loaded in GraphEdit this file needs 2 filters named "Decrypt/Tag". And it doesn't decode when ffdshow is used (either with libmad or mp3lib). But it does decode when using DScaler5. Dunno what library they use, apparently libmad: http://cvs.sourceforge.net/viewcvs.py/deinterlace/DScaler5/Filters/Decoders/... For those interrested in finding out what's wrong, here is the sample URL: ftp://uleguadv:refulavi at ftp.divxnetworks.com/today.dvr-ms Steve
A user sent us a DVR-MS file (ASF with MPEG-2 and MP2) that doesn't decode correctly in FFMPEG.
I'll have a look at this when I get a chance since I'd like to get audio working in all dvr-ms files. When I played it with "mplayer -demuxer 35" it didnt crash but I only saw part of the picture... it's HD which I havent seen before. Perhaps the audio codec used in HD dvr-ms isnt supported in ffmpeg - I dont know. I got this output from mplayer: Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 Too many video packets in the buffer: (125 in 8396376 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. ADecoder init failed :( ADecoder init failed :( Requested audio codec family [ffmp2] (afm=ffmpeg) not available. Enable it at compilation. Requested audio codec family [mad] (afm=libmad) not available. Enable it at compilation. Opening audio decoder: [hwmpa] MPEG audio pass-through (fake decoder) Too many video packets in the buffer: (125 in 8396376 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. Cannot sync MPA frame: 0 ADecoder init failed :( ADecoder init failed :( Cannot find codec for audio format 0x50. Read DOCS/HTML/en/codecs.html!
Steve - is the picture clipped when you play this file? Mplayer only shows the top corner of the screen because the size picked up by the asf demuxer code isnt right. I'm guessing the picture size is not stored in the same way in dvr-ms files as for other asf files. Also, I've learned that HD dvr-ms files can contain an audio stream encoded with ac3 rather than mp2 (depending on how it is brodcast). I'm guessing your file has an ac3 audio stream if that helps at all. Apparently a number of players have a problem with HD dvr-ms audio.
John Donaghy wrote:
Steve - is the picture clipped when you play this file? Mplayer only shows the top corner of the screen because the size picked up by the asf demuxer code isnt right. I'm guessing the picture size is not stored in the same way in dvr-ms files as for other asf files.
No, the picture is decoded correctly. But I use a patched version of FFMPEG without the MPEG2 bug ;)
Also, I've learned that HD dvr-ms files can contain an audio stream encoded with ac3 rather than mp2 (depending on how it is brodcast). I'm guessing your file has an ac3 audio stream if that helps at all. Apparently a number of players have a problem with HD dvr-ms audio.
No, because in GraphEdit the input pin is different for files with AC3. So I assume it's MP2 and not AC3. Steve -- robUx4 on blog <http://robux4.blogspot.com/>
No, the picture is decoded correctly. But I use a patched version of FFMPEG without the MPEG2 bug ;)
So you're not getting the frame size from the asf demuxer? If not, how do you get it?
No, because in GraphEdit the input pin is different for files with AC3. So I assume it's MP2 and not AC3.
You're right, I looked at it in GraphEdit and on my machine it chooses my InterVideo audio decoder for this file rather than the regular MPEG Audio Decoder. The properties dialog for the Intervideo decoder calim it is '2 speaker mode, Dolby Sound compatible (as opposed to stereo/mono). It says the format is MPEG2 and the attributes are 16bit/48k/1ch. I wonder what is different about this audio stream that causes it to pick the Intervideo decoder - maybe the 'dolby' setting? Have to been able to play other HD dvr-ms files successfully? John
John Donaghy wrote:
No, the picture is decoded correctly. But I use a patched version of FFMPEG without the MPEG2 bug ;)
So you're not getting the frame size from the asf demuxer? If not, how do you get it?
I get the source width/height from AVCodecContext* catched as this: video_codec = avctx->streams[vidTrackId]->codec;
No, because in GraphEdit the input pin is different for files with AC3. So I assume it's MP2 and not AC3.
You're right, I looked at it in GraphEdit and on my machine it chooses my InterVideo audio decoder for this file rather than the regular MPEG Audio Decoder. The properties dialog for the Intervideo decoder calim it is '2 speaker mode, Dolby Sound compatible (as opposed to stereo/mono). It says the format is MPEG2 and the attributes are 16bit/48k/1ch. I wonder what is different about this audio stream that causes it to pick the Intervideo decoder - maybe the 'dolby' setting?
All I know is that it's not AC3. DScaler has an input type MEDIATYPE_DVD_ENCRYPTED_PACK instead of MEDIATYPE_Audio, that could be the difference.
Have to been able to play other HD dvr-ms files successfully?
Yes, most of them. And they decode fine with DrFFMPEG (apart from that weird kind of file). Steve -- robUx4 on blog <http://robux4.blogspot.com/>
I get the source width/height from AVCodecContext* catched as this:
video_codec = avctx->streams[vidTrackId]->codec;
Thanks for that.
So I assume it's MP2 and not AC3.
You're right, I looked at it in GraphEdit and on my machine it chooses my InterVideo audio decoder for this file rather than the regular MPEG Audio Decoder. The properties dialog for the Intervideo decoder calim it is '2 speaker mode, Dolby Sound compatible (as opposed to stereo/mono). It says the format is MPEG2 and the attributes are 16bit/48k/1ch. I wonder what is different about this audio stream that causes it to pick the Intervideo decoder - maybe the 'dolby' setting?
All I know is that it's not AC3. DScaler has an input type MEDIATYPE_DVD_ENCRYPTED_PACK instead of MEDIATYPE_Audio, that could be the difference.
I'm afraid I've got no more ideas about this. I looked at what the code was doing and the demuxer reports it as an mp2 stream which is presumably correct. Then the mp3 lib code makes a call to 'read_frame' which repeatedly calls 'decode_header' to try to find a valid header without success. libmad.a also fails in that it plays some strange noises instead of the real audio stream. I'm curious though, does DScaler play dvr-ms files or did you convert the file first?
Have to been able to play other HD dvr-ms files successfully?
That's good to know anyway. Cheers, John
John Donaghy wrote:
So I assume it's MP2 and not AC3. You're right, I looked at it in GraphEdit and on my machine it chooses my InterVideo audio decoder for this file rather than the regular MPEG Audio Decoder. The properties dialog for the Intervideo decoder calim it is '2 speaker mode, Dolby Sound compatible (as opposed to stereo/mono). It says the format is MPEG2 and the attributes are 16bit/48k/1ch. I wonder what is different about this audio stream that causes it to pick the Intervideo decoder - maybe the 'dolby' setting? All I know is that it's not AC3. DScaler has an input type MEDIATYPE_DVD_ENCRYPTED_PACK instead of MEDIATYPE_Audio, that could be the difference.
I'm afraid I've got no more ideas about this. I looked at what the code was doing and the demuxer reports it as an mp2 stream which is presumably correct. Then the mp3 lib code makes a call to 'read_frame' which repeatedly calls 'decode_header' to try to find a valid header without success. libmad.a also fails in that it plays some strange noises instead of the real audio stream.
I'm curious though, does DScaler play dvr-ms files or did you convert the file first?
It decodes the original audio stream (presumably MP2) just fine. Maybe one day when I have time I'll try to compile DScaler and see what it's using. But not in the short term future... Steve -- robUx4 on blog <http://robux4.blogspot.com/>
Hi On Mon, Apr 24, 2006 at 10:50:13AM -0500, John Donaghy wrote:
I get the source width/height from AVCodecContext* catched as this:
video_codec = avctx->streams[vidTrackId]->codec;
Thanks for that.
So I assume it's MP2 and not AC3.
You're right, I looked at it in GraphEdit and on my machine it chooses my InterVideo audio decoder for this file rather than the regular MPEG Audio Decoder. The properties dialog for the Intervideo decoder calim it is '2 speaker mode, Dolby Sound compatible (as opposed to stereo/mono). It says the format is MPEG2 and the attributes are 16bit/48k/1ch. I wonder what is different about this audio stream that causes it to pick the Intervideo decoder - maybe the 'dolby' setting?
All I know is that it's not AC3. DScaler has an input type MEDIATYPE_DVD_ENCRYPTED_PACK instead of MEDIATYPE_Audio, that could be the difference.
I'm afraid I've got no more ideas about this. I looked at what the code was doing and the demuxer reports it as an mp2 stream which is presumably correct. Then the mp3 lib code makes a call to 'read_frame' which repeatedly calls 'decode_header' to try to find a valid header without success. libmad.a also fails in that it plays some strange noises instead of the real audio stream.
hmm, what happens if you dump the audio stream into a file and try to play that with mplayer or ffmpeg? and if that doesnt work, maybe post a few kb of that audio stream maybe someone can spot something by looking at it .... [...] -- Michael In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
Michael Niedermayer wrote:
I get the source width/height from AVCodecContext* catched as this:
video_codec = avctx->streams[vidTrackId]->codec; Thanks for that.
So I assume it's MP2 and not AC3. You're right, I looked at it in GraphEdit and on my machine it chooses my InterVideo audio decoder for this file rather than the regular MPEG Audio Decoder. The properties dialog for the Intervideo decoder calim it is '2 speaker mode, Dolby Sound compatible (as opposed to stereo/mono). It says the format is MPEG2 and the attributes are 16bit/48k/1ch. I wonder what is different about this audio stream that causes it to pick the Intervideo decoder - maybe the 'dolby' setting? All I know is that it's not AC3. DScaler has an input type MEDIATYPE_DVD_ENCRYPTED_PACK instead of MEDIATYPE_Audio, that could be the difference. I'm afraid I've got no more ideas about this. I looked at what the code was doing and the demuxer reports it as an mp2 stream which is presumably correct. Then the mp3 lib code makes a call to 'read_frame' which repeatedly calls 'decode_header' to try to find a valid header without success. libmad.a also fails in that it plays some strange noises instead of the real audio stream.
hmm, what happens if you dump the audio stream into a file and try to play that with mplayer or ffmpeg?
I tried: ffmpeg -i /C/test/DivX/today.dvr-ms -vcodec copy -an dvr-ms.m2v And got a file doesn't doesn't play. Then I tried: ffmpeg -i /C/test/DivX/today.dvr-ms -acodec copy -vn dvr-ms.mp2 And got an empty file.
and if that doesnt work, maybe post a few kb of that audio stream maybe someone can spot something by looking at it ....
Is my command-line correct to extract audio from the source file ? Steve -- robUx4 on blog <http://robux4.blogspot.com/>
Hi It's been a long time since I posted here but if anyone cares (which I doubt) I discovered recently why the audio in this file doesn't play. The problem seems to be that the audio in this sample is AC3 but the 'format tag' in the WAVEFORMATEX structure in the audio stream header incorrectly indicates that the audio is MP3 (which it tends to be in dvr-ms). I discovered this while working on getting mplayer to play these files using libmpdemux. I obtained a few more samples where the audio didnt work - sometimes the audio was MP3 and sometimes it was AC3. The 'format tag' was always wrong (sometime ='0', sometime ='1' and in this case ='80') when the audio didnt work. I dont have a patch for this because all I've been able to do so far is hard code the correct value which makes the audio work if it's the right kind. I suppose the only way to fix it is to find if the audio codec type can be read from somewhere else in the file but I'm not too hopeful about finding it in the absence of proper documentation. Supposedly the audio is only ever MP3 or AC3 in a dvr-ms file so maybe it's possible to somehow try one then the other. I have looked into it though. John On 4/25/06, Steve Lhomme <steve.lhomme at free.fr> wrote:
Michael Niedermayer wrote:
I get the source width/height from AVCodecContext* catched as this:
video_codec = avctx->streams[vidTrackId]->codec; Thanks for that.
So I assume it's MP2 and not AC3. You're right, I looked at it in GraphEdit and on my machine it chooses my InterVideo audio decoder for this file rather than the regular MPEG Audio Decoder. The properties dialog for the Intervideo decoder calim it is '2 speaker mode, Dolby Sound compatible (as opposed to stereo/mono). It says the format is MPEG2 and the attributes are 16bit/48k/1ch. I wonder what is different about this audio stream that causes it to pick the Intervideo decoder - maybe the 'dolby' setting? All I know is that it's not AC3. DScaler has an input type MEDIATYPE_DVD_ENCRYPTED_PACK instead of MEDIATYPE_Audio, that could be the difference. I'm afraid I've got no more ideas about this. I looked at what the code was doing and the demuxer reports it as an mp2 stream which is presumably correct. Then the mp3 lib code makes a call to 'read_frame' which repeatedly calls 'decode_header' to try to find a valid header without success. libmad.a also fails in that it plays some strange noises instead of the real audio stream.
hmm, what happens if you dump the audio stream into a file and try to play that with mplayer or ffmpeg?
I tried: ffmpeg -i /C/test/DivX/today.dvr-ms -vcodec copy -an dvr-ms.m2v
And got a file doesn't doesn't play.
Then I tried: ffmpeg -i /C/test/DivX/today.dvr-ms -acodec copy -vn dvr-ms.mp2
And got an empty file.
and if that doesnt work, maybe post a few kb of that audio stream maybe someone can spot something by looking at it ....
Is my command-line correct to extract audio from the source file ?
Steve
-- robUx4 on blog <http://robux4.blogspot.com/>
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Hi On Wed, Apr 19, 2006 at 08:49:28PM +0200, Steve Lhomme wrote:
Hi,
A user sent us a DVR-MS file (ASF with MPEG-2 and MP2) that doesn't decode correctly in FFMPEG.
The issue in DrFFMPEG (with some fixes in ASF submited on this list) is that the audio is not decoded at all. The video is decoded fine. In FFMPEG the files crashes very fast but not at the same place with the following gdb log:
[...]
Program received signal SIGSEGV, Segmentation fault. mpeg_decode_mb (s=0x3d950, block=0x2) at mpeg12.c:1894 1894 block[0] = dc << (3 - s->intra_dc_precision); (gdb) bt #0 mpeg_decode_mb (s=0x3d950, block=0x2) at mpeg12.c:1894 #1 0x00525230 in mpeg_decode_slice (s1=0x3d950, mb_y=0, buf=0x23efe4, buf_size=101196) at mpeg12.c:2567 #2 0x00527942 in mpeg_decode_frame (avctx=0x3bf90, data=0x23f4d0, data_size=0x23f47c, buf=0x1500030 "", buf_size=101380) at mpeg12.c:3157 #3 0x00458612 in avcodec_decode_video (avctx=0x3bf90, picture=0x23f4d0, got_picture_ptr=0x23f47c, buf=0x1500030 "", buf_size=101380) at utils.c:946 #4 0x0040f44c in av_find_stream_info (ic=0x36790) at utils.c:1826 #5 0x00405c87 in opt_input_file (filename=0x0) at ffmpeg.c:2834 [...] (gdb) disass $pc-32 $pc+32 Dump of assembler code from 0x5247e1 to 0x524821: 0x005247e1 <mpeg_decode_mb+6625>: pusha 0x005247e2 <mpeg_decode_mb+6626>: pop %es 0x005247e3 <mpeg_decode_mb+6627>: add %al,(%eax) 0x005247e5 <mpeg_decode_mb+6629>: mov 0x1c74(%esi),%edx 0x005247eb <mpeg_decode_mb+6635>: add %edi,%eax 0x005247ed <mpeg_decode_mb+6637>: mov %eax,0x760(%esi,%ebx,4) 0x005247f4 <mpeg_decode_mb+6644>: sub %edx,%ecx 0x005247f6 <mpeg_decode_mb+6646>: mov 0xffffffcc(%ebp),%edi 0x005247f9 <mpeg_decode_mb+6649>: shl %cl,%eax 0x005247fb <mpeg_decode_mb+6651>: mov 0x1c88(%esi),%ecx 0x00524801 <mpeg_decode_mb+6657>: mov %ax,(%edi) 0x00524804 <mpeg_decode_mb+6660>: xor $0x1,%eax 0x00524807 <mpeg_decode_mb+6663>: cwtl 0x00524808 <mpeg_decode_mb+6664>: mov %eax,0xffffffbc(%ebp) 0x0052480b <mpeg_decode_mb+6667>: test %ecx,%ecx 0x0052480d <mpeg_decode_mb+6669>: mov $0x681780,%eax 0x00524812 <mpeg_decode_mb+6674>: jne 0x524819 <mpeg_decode_mb+6681> 0x00524814 <mpeg_decode_mb+6676>: mov $0x6816c0,%eax 0x00524819 <mpeg_decode_mb+6681>: mov 0xfffffff0(%ebp),%esi 0x0052481c <mpeg_decode_mb+6684>: mov 0x3c(%eax),%eax 0x0052481f <mpeg_decode_mb+6687>: mov 0x1c3c(%esi),%ebx
When loaded in GraphEdit this file needs 2 filters named "Decrypt/Tag". And it doesn't decode when ffdshow is used (either with libmad or mp3lib). But it does decode when using DScaler5. Dunno what library they use, apparently libmad: http://cvs.sourceforge.net/viewcvs.py/deinterlace/DScaler5/Filters/Decoders/...
For those interrested in finding out what's wrong, here is the sample URL: ftp://uleguadv:refulavi at ftp.divxnetworks.com/today.dvr-ms
has this bug been fixed? (no i cant check ... as "file not found") [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you really think that XML is the answer, then you definitly missunderstood the question -- Attila Kinali
has this bug been fixed? (no i cant check ... as "file not found")
This hasnt been fixed but I know what's wrong now. The problem is that the audio stream header in this sample 'suggests' that the audio is MP2 when in fact it is actually AC3. I say 'suggests' here because there's no public documentation on the content of a dvr-ms audio stream header. I originally submitted a patch (to get dvr-ms audio working) that reads what appears to be a WAVEFORMATEX structure from the middle of the header. This seemed to work well enough for SD content but it turns out that it doesnt typically work for HD content. As far as I know the wFormatTag field of a WAVEFORMATEX should contain 0x50 for MP2 and 0x2000 for AC3. However, for the sample in question, wFormatTag contains 0x50, which means there's currently no way to know in the demuxer that the audio is AC3. Most other HD samples I've seen contain the value 0x00 in wFormatTag if the audio is AC3. I've built an experimental version of mplayer that changes the value to 0x2000 if 0x00 is found, and this allows me to play most HD files I have - except for the sample in question. I doubt this is the basis for a patch though given that at least one sample still doesnt work. There must be some other way to determine the audio stream type but I dont know how to at the minute. If anyone's interested in helping I have a bunch of samples I can post. John
John Donaghy wrote:
There must be some other way to determine the audio stream type but I dont know how to at the minute. If anyone's interested in helping I have a bunch of samples I can post.
John
since the options are so few and telling which stream is which is easy, you can do a scan on a short amount of data and keep a scoreboard of the valid syncwords found -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Video Lezioni Gratis? Internet, Informatica, Hobby direttamente da professionisti. Scopri adesso come imparare senza fatica e stress! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5147&d=26-1
Hi On Fri, Jan 26, 2007 at 06:22:26PM +0100, Nico Sabbi wrote:
John Donaghy wrote:
There must be some other way to determine the audio stream type but I dont know how to at the minute. If anyone's interested in helping I have a bunch of samples I can post.
John
since the options are so few and telling which stream is which is easy, you can do a scan on a short amount of data and keep a scoreboard of the valid syncwords found
and you can use mp3_demuxer.read_probe() to do this, no need to duplicate it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle
participants (5)
-
johnfdonaghy＠gmail.com -
michaelni＠gmx.at -
nsabbi＠email.it -
slhomme＠divxcorp.com -
steve.lhomme＠free.fr