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

[Nico]

----- 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,
> though.

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.
> 
> David
> -- 
> 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
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>