[MPlayer-dev-eng] Remove internal mp3lib forked copy

[Thomas Orgis]

Am Thu, 5 Apr 2012 23:01:00 +0300
schrieb Ivan Kalvachev <ikalvachev at gmail.com>: 

> A little bit off-topic.
> 
> with mpg123 in very rare cases, mostly after seeking, I get something like:
> 
> A:   0.2 V:   0.0 A-V:  0.183 ct: -0.011   1/  1 ??% ??% ??,?% 0 0 84%
> mpg123 failed to reopen stream: Error reading the stream. (code 18)
> mpg123 cannot reopen stream for resync.
> mpg123 decoding failed: No stream opened. (code 24)
> A:  60.2 V:  60.2 A-V:  0.014 ct:  0.001 1804/1804 ??% ??% ??,?% 0 0 65%
> mpg123 decoding failed: No stream opened. (code 24)
> 
> It goes on like this until I seek again.
> Can you do something to make the resync a little bit more resilient.

Hm, we already tell mpg123 to try to resync forever after been into the
stream already. What I can imagine is the code for finding a valid
start of the stream failing to do so here, as MPlayer resync triggers
reopening of the stream for mpg123. I was wondering in the past if I
should change this or not:

On opening a stream, apart from specific handling of ID3 tags, up to
64K are skipped as "junk at beginning" if there is no valid header
found (actually, more can be skipped if occasionally an MPEG header
appears that is not followed by another one after the alleged frame).
I changed the limit for junk after knowing we are in an MPEG stream to
be tunable by the library user, so that MPlayer can set that to
infinity.

Now, my assumption is that one also wants to be able to set the initial
scanning limit to infinity. I hesitate to make that the default, though.

As I am unable to reproduce those very rare cases (yet), can you help
me by uncommenting that line in ad_mpg123.c:

	mpg123_param(con->handle, MPG123_ADD_FLAGS, MPG123_QUIET, 0.0);

Without that line, if my assumption about the mode of failure is right,
you should get such additional output:

	Giving up searching valid MPEG header after (over) 64K of junk.

I do wonder if that really happens. Are you seeking well within the
stream, far from leading/trailing stuff like funky tags (Monkey Audio
or such) or album art? I do wonder where the over 64K of junk are
supposed to come from. Not that there is actually some data corruption
in the communication.

Is it a file you can make available for testing?

In any case, I suppose I will just have to make ad_mpg123 retry
reopening the stream until there is no input data left. Either that
works or we run out of data. Is there something I overlook here?


Alrighty then,

Thomas

PS: I am not happy about those:
mpg123 decoding failed: No stream opened. (code 24)
I was initially deluded into MPlayer doing something with the return
code of control(), for example. The return CONTROL_FALSE I have there
is a remnant of that delusion. I learned that MPlayer does not expect
anything unexpected to happen in a decoder, failure is not an option.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120407/bf50e08c/attachment.asc>