Asf demuxing problems

[hlange@…]

Recent SVN versions seem to have the asf demuxing somewhat broken. I believe that this has been observable since the 23257 changes. Anyway when i tried rewerting asf demuxing related files to previous ones did seem to eliminate the effects i described below:

U was able to identify 2 situations as far :
1) The streaming of asf file from vlc media player
EFFECT:
a) When the -nocache parameter is given in the command line, the player is unable to start the playback. It merely displays :
Stream not seekable!
Till i quit.
The previous mplayer versions did display this 1-3 times, but started playback almost immediately.
b) When the cache is set, sometimes it starts playback sometimes don't. But when it does, it playbacks the first ~0.5 second twice.

2) Playback of some WMV files.
EFFECTS:
a) I observed in case of certain wmv that in the beginning has a still picture (for like 20 seconds) mplayer playbacks that part in 1-2 seconds, and afterwards the audio/video is desynced.
An attemtp to seek further after the initial still phase, corrects the desync.
Attempt to seek back to the still phase desyncs playback again.
b) The additional informations like clip name, author and comments are not displayed.

In both cases, the (new) mplayer displays a warning, about inocrrect length of ASF header.
The older versions of mplayer do not have this problems and seem to decode the header correctly (at least no warnings ar displayed, and the additional clip info is)
Possibly the problem is with the additional info, as i have not observed problems with clips without it, (although also none of available to me seem to have lot of still video)

Additional informations:
I first tried the latest svn version, then after checking the change logs i tried the earlier versions from before asf changes. The i tried the versions from 1+ days from after changes WITH only asf related reverted to older versions.

[compn]

try mplayer -demuxer lavf file.wmv

[hlange@…]

(In reply to comment #1)

try mplayer -demuxer lavf file.wmv

Actually the only improvement this brings is for the vlc stream. Also when applied in older version (which otherwise correctly seems to work for me), produces similar effects like newer versions of mplayer.

What also seems strange is that the ffmpeg reads and converts everything smoothly (And the same svn version number for libavformat in both applications)

When the timer is on the player shows exactly the correct time, but it rushes through the still part like on fast forward, which in effect gives desync. Which gives impression that maybe all the data is correctly extracted, but later it's handled incorrectly during playback.

Perhaps next i will try to split and upload part of from one of files as an example.

[hlange@…]

Ok, i have found today some time to look back at this. Here is what i found :

1) the mplayer -demuxer lavf file.wmv on my older version of mplayer works similiar, simply because it fails on the header readings and eventually falls back on lavf - printout from the console (the language = pl, messages transleted in []) below:

[asfheader] Audio stream found, -aid 1
[asfheader] Video stream found, -vid 2
Nieprawidłowa długośc nagłówka ASF! [Wrong ASF header length!]
Wykryto format pliku libavformat. [file format libavformat detected]
[lavf] Audio stream found, -aid 0
[lavf] Video stream found, -vid 1

Apparently the differences on VLC generated stream was purely coincidental.

Anyway later when using lavf for each step of the frame, the video speeds up, while audio remains steady i include below the console printout for stepping frames from 11 to 16 (all of them are the same still picture) :

A: 6.9 V: 12.3 A-V: -5.444 ct: -0.040 11/ 11 ??% ??% ??,?% 0 0 0%
alsa-pause: pause supported by hardware
alsa-resume: resume supported by hardware
A: 6.9 V: 12.7 A-V: -5.792 ct: -0.044 12/ 12 ??% ??% ??,?% 0 0 0%
alsa-pause: pause supported by hardware
alsa-resume: resume supported by hardware
A: 7.0 V: 13.1 A-V: -6.099 ct: -0.048 13/ 13 ??% ??% ??,?% 0 0 0%
alsa-pause: pause supported by hardware
alsa-resume: resume supported by hardware
A: 7.0 V: 13.4 A-V: -6.435 ct: -0.052 14/ 14 4% 7% 0.1% 0 0 0%
alsa-pause: pause supported by hardware
alsa-resume: resume supported by hardware
A: 7.1 V: 13.8 A-V: -6.783 ct: -0.056 15/ 15 4% 6% 0.1% 0 0 0%
alsa-pause: pause supported by hardware
alsa-resume: resume supported by hardware
A: 7.1 V: 14.2 A-V: -7.092 ct: -0.060 16/ 16 3% 6% 0.1% 0 0 9%

As you can see in the result the video gets several seconds away from audio

This is quite strange, as i got ffmpeg/ffplay stamped with same revisions as the libav libraries in mplayer, and it converts/plays the file correctly.

2) The EXACT PLACE which causes my files to misbehave is in asfheader.c,
around line 558 (rev 23558):

555 asf->dvr_last_vid_pts=0.0;
556 } else asf->asf_is_dvr_ms=0;
557 if (!get_ext_stream_properties(hdr, hdr_len, streamh->stream_no, asf, 1))
558 goto len_err_out;
559 if (get_meta(hdr, hdr_len, streamh->stream_no, &asp_ratio)) {
560 sh_video->aspect = asp_ratio * sh_video->bih->biWidth /
561 sh_video->bih->biHeight;
562 }
563 sh_video->i_bps = asf->bps;
564

After the get_ext_stream_properties fails, the program jumps to len_err_out label, which clears and closes everything, making ASF demuxer fail.
In the result mplayer switches to the next demuxer.

If i simply change the code to do nothing, for example like this:

557 if (!get_ext_stream_properties(hdr, hdr_len, streamh->stream_no, asf, 1))
558 ;goto len_err_out;

It behaves (on my file and on VLC) like the revisions prior to the revision 23257, which means proceeding with fps:1000.00 ftime:=0.0010

I assume there was the reason for "killing" the demuxer when it fails to get the data, so perhaps this is not fully acceptable solution, but at least it works for me and i'm gonna leave it as is for now.

BR

[nsabbi@…]

John Donaghy provided this patch to fix the problem.
Does it work?

Index: asfheader.c
===================================================================
--- asfheader.c (revision 23577)
+++ asfheader.c (working copy)
@@ -288,7 +288,7 @@

return 1;

}

}

• return 0;

+ return 1;

}

#define CHECKDEC(l, n) if (((l) -= (n)) < 0) return 0

[reimar]

No further information, no sample file, and MMSH streaming with VLC 1.1.3 works for me with both demuxers, even though unreliably in both cases (basically it only works if VLC streaming was started very shortly before connecting MPlayer).