[MPlayer-dev-eng] [BUG] DVB input/MPEG-TS not working correctly
nsabbi at libero.it
Thu Aug 21 09:44:46 CEST 2003
----- Original Message -----
From: David Kuehling <dvdkhlng at gmx.de>
To: mplayer-dev-eng <mplayer-dev-eng at mplayerhq.hu>
Sent: Wednesday, August 20, 2003 11:39 PM
Subject: Re: [MPlayer-dev-eng] [BUG] DVB input/MPEG-TS not working correctly
> > you can't seek in a pipe or in a non-file stream
> I can seek, if I specify -cache. That's odd?
maybe you can seek in the cache, but I'm not sure.
> > 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.
yes, it's not syncronized to key frames, yet
> Shouldn't there be some fail-safe mechanism that forbids seeking in
> cases where it knowingly crashes MPlayer?
a demuxer shouldn't check if you are using a decoder or the other, rather a decoder (libmpeg2) should be fixed.
> >> 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).
what's the bitrate of video?
> > 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.
look better, as far as I remember the default is 0x800000 if you are using BT848 on a BSD, 0x200000 otherwise
>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,
that patch should help a lot
> 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?
threads are forbidden in every version of mplayer;
the real problems are
1) mplayer's impossibility to show still images (on which I could show the menu)
2) it's not expected that a demuxer can read data but can't feed it to the decoder because the content is encrypted;
if I just returned 0 length data read, mplayer would exit, and it's not what I want;
I asked advices long time ago, but none arrived
> 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
did you remember to load the module dvb-core with dvb_shutdown_timeout=0 ? Otherwise the card will be turned
off exactly 10 seconds after the tuning
> 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.
> GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
> Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
More information about the MPlayer-dev-eng