Re: [MPlayer-dev-eng] Remove internal mp3lib forked copy Thomas Orgis Sat Apr 07 05:00:24 2012
Am Thu, 5 Apr 2012 23:01:00 +0300 schrieb Ivan Kalvachev <[EMAIL PROTECTED]>: > 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.
_______________________________________________ MPlayer-dev-eng mailing list [EMAIL PROTECTED] https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
- Re: [MPlayer-dev-eng] Remove internal mp3lib forked copy Ivan Kalvachev 2012/04/05
- Re: [MPlayer-dev-eng] Remove internal mp3lib forked copy Thomas Orgis 2012/04/07 <=
- Re: [MPlayer-dev-eng] Remove internal mp3lib forked copy Thomas Orgis 2012/04/23
- Re: [MPlayer-dev-eng] Remove internal mp3lib forked copy Ivan Kalvachev 2012/04/25