[MPlayer-dev-eng] Re: [RFC] rc2

[Carl Eugen Hoyos]

Hi Nico!

Nico Sabbi <nsabbi <at> email.it> writes:

> >Quoting http://www.mplayerhq.hu/DOCS/HTML/en/mpeg_decoders.html:
> >
> >Make sure that you have have only Free to Air channels in your channels.conf
> >file, or MPlayer will try to skip to the next visible one, but it may take
> >long if there are many consecutive encrypted channels.
> >
> >Since r20478 (or so, right now, I only tested rc1 and svn, and they show
> >different behaviour), mplayer just prints "TS file format detected" and
> >waits forever (or until encryption ends) instead of skipping. I prefer this
> >new behaviour, because it allows to wait for unencrypted transmissions on
> >otherwise encrypted channels (Euro1080), but in any case, documentation and
> >behaviour differ.
> >
> uhm, it's unexpected. the ts demuxer should only probe up to -tsprobe
> and quit if nothing useful is found. Maybe you overrode that value with
> something insane?

Just to clarify:
I just did svn up && svn update -r20477 libmpdemux/demux_ts.c, merged 22623
(s/stream.h/stream/stream.h) and 21547 (s/min/FFMIN), compiled and tried
./mplayer dvb://HD1 (CA1572 Irdeto encrypted channel)
Result for 20477: mplayer quit with "NO VIDEO! NO AUDIO!  NO SUBS (yet)!" after
a very short time. (Note the two spaces between AUDIO! and NO: Are they
intended?)
Then I updated libmpdemux/demux_ts.c to 20478, made sure that the necessary
changes for compilation (stream and FFMIN) were still there, compiled and tried
./mplayer dvb://HD1 (still encrypted):
Result for 20478: mplayer is still waiting for unencrypted packets ("TS file
format detected.")

Since rc1 (my installed version) shows the same behaviour as 20477, I did not
search for overriden default values.

Again: I personally like the change (because it allows to wait for an
unencrypted program), but since it contradicts DOCS, either documentation or
source should probably be changed before release.

Thanks for your time, Carl Eugen