[MPlayer-dev-eng] Re: [MPlayer-cvslog] CVS: main/mp3lib sr1.c, 1.33, 1.34

[Zuxy Meng]

Hi,

2006/1/4, Guillaume POIRIER <poirierg at gmail.com>:
> Hi,
>
> Before of after your patch? It appears to me that previous code did
> initialize MP3_resync to 0, didn't it?

It should be initilalized to 1 for each mp3 stream to be synchronized.
It's reset to 0 in read_frame() after an mp3 stream has been
synchronized. Just like a state machine.

>
> > To fix the bug, all you have to do is to
> > initialize it to 1 somewhere. If MP3_Init() wasn't the proper place,
> > maybe someone could find a better way.
>
> Well, I can't comment on current code, all I can say is that the
> problem your patch is supposed to fix should be addressed at the
> demuxer level, i.e.: the codec should get clean data, and should not
> have some workarounds for demuxer bugs.

Well, I don't think it's a demuxer bug:-) The demuxer does produce
clean data, but it's definitely codec's work to sync and decode the
data. In fact, all the synchronization work is done inside
read_frame().

> In other words, even if your patch worked alright to fix the playback
> of the file you gave a link to, it hides some other mplayer's part
> bugs.
>
>
> > Just curious: why static vars are undesirable? For thread-safety or
> > for consistency?
>
> I suppose it's for concurrency issues, though I can't say for sure. If
> you want to discuss this matter further, I suggest you post on the
> mailing list.
> I've been mostly quoting what was discussed on IRC yesterday.

OK


--
Zuxy
Beauty is truth,
While truth is beauty.
PGP KeyID: E8555ED6