[MPlayer-dev-eng] [BUG] DVB input/MPEG-TS not working correctly

David Kuehling dvdkhlng at gmx.de
Wed Aug 20 23:39:22 CEST 2003


> you can't seek in a pipe or in a non-file stream

I can seek, if I specify -cache.  That's odd?

> seeking in a TS file works only if you have libavcodec compiled in
> mplayer and appending -vc ffmpeg12 to the cli.

> Seeking with libmpeg2 is reportedly broken.

I see.  -vfm ffmpeg works somehow.  But it seems to seek to non-keyframe
positions, I always see garbage for about .5 seconds after seeking.
Shouldn't there be some fail-safe mechanism that forbids seeking in
cases where it knowingly crashes MPlayer?

>> I'll try to upload the sample file, dvbt-berlin.mpg, this evening
>> (18Mb with Modem should take some time :-( ).

> please, let me know the name, so I can give it a look (but I will be
> back home friday)

I just tried to upload via modem but only got a rate of 2.4 k/secs which
might be due to ftp.mplayerhq.hu or is my providers' fault.  I gave up
after approx. 3Mb.   It's named MPlayer/incoming/dvbt-berlin.mpg.bz2.
Maybe that snippset helps (bzip2 won't be able to unpack the last block
which might be up to 900k).  

> try increasing MAX_PACKS and MAX_PACKS_BYTES in libmpdemux/demuxer.h
> to something like 32768 and 0x800000; you can also try my demux_ts
> patch that I posted in this ML few days ago (last version, dated
> 20030817), but you also need to increase those values.

It does not seem to be that trivial.  I increased MAX_PACKS as you told
me, MAX_PACKS_BYTES was already set to 0x800000.  This just delays the
error, and I can better watch it happen: Video doesn't play fast enough,
although audio is already ahead of video!  The delay gets greater and
greater, and after about 10 seconds, I again see "Too many video packets
in the buffer: (32768 in 5996283 bytes)".  Haven't tried your patch yet,
though.

here's one of the status lines while that effect is happening:

A:78581.4 V:78574.7 A-V:  6.662 ct:  0.088   25/ 25  30% 34% 808.9% 24 0 0%

That's not a CPU load problem, I even don't see much CPU activity while
MPlayer continues playing video at about 2fps.  Please look at the logs,
I included with my last mail. They contain some logging output from the
demuxer, maybe it helps you understand what's happening.

> Are you sure that you don't have encrypted channels in you
> channels.conf? Those are unsupported, so you should remove them. It's
> written in the HTML docs.

?? Encrypted channels on DVB-t here in Berlin.  Don't think so.  I
checked channels.conf, took out all the channels which I might not be
able to receive.  Still the same thing happens:

dvb_streaming_read, attempt N. 5 failed with errno 11 when reading 12 bytes
dvb_streaming_read, attempt N. 4 failed with errno 11 when reading 12 bytes
dvb_streaming_read, attempt N. 3 failed with errno 11 when reading 12 bytes
dvb_streaming_read, attempt N. 2 failed with errno 11 when reading 12 bytes
dvb_streaming_read, attempt N. 1 failed with errno 11 when reading 12 bytes
dvb_streaming_read, attempt N. 5 failed with errno 11 when reading 2048 bytes
dvb_streaming_read, attempt N. 4 failed with errno 11 when reading 2048 bytes
dvb_streaming_read, attempt N. 3 failed with errno 11 when reading 2048 bytes
dvb_streaming_read, attempt N. 2 failed with errno 11 when reading 2048 bytes
dvb_streaming_read, attempt N. 1 failed with errno 11 when reading 2048 bytes
dvb_streaming_read, return 0 bytes
UNINIT COMPLETE

Apropos, isn't it bad design that mplayer hangs with unreceivable
channels?  Couldn't you use some thread or forked process for
preventing that?

Now, I tried with -nosound, even more "interesting" things happen :-) :

mplayer dvb://ZDF -nosound

This time no A/V sync issue, of course.  Video plays at normal speed.
I'm even able to zap.  Once.  After zapping the first time, new channel
is displayed, and mplayer starts to display:

Select error : Bad file descriptor%
Error while reading cmd fd 3: Bad file descriptor
Error on cmd fd 3
...
[message repeats]

Full log with option "-v" attached as mplayer-dump4.txt.bz2


And I noticed yet another bug: 

tzap -r "ZDF" & sleep 1; mplayer dvb://ZDF

MPlayer interrupted by signal 11 in module: open_stream

Of course the command makes no sense, but that's no reason to just
segfault.  I currently have no debug version of mplayer around, so no
backtrace this time.  I'll send one if you cannot reproduce that bug.

Watching TV without zapping is just no fun.  Hope those problems can be
fixed.  If you need more info, just ask.

David
-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-dump4.txt.bz2
Type: application/octet-stream
Size: 8550 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20030820/66c15ec6/attachment.obj>


More information about the MPlayer-dev-eng mailing list