[vdr] Re: Streamdev 0.0.2 problem

[Rene Bartsch <ml@bartschnet.de>]

Am Mon, 2003-05-05 um 22.08 schrieb Sascha Volkenandt:
> On Sonntag, 4. Mai 2003 23:17 Rene Bartsch wrote:
> > Objection!
> 
> Whoops ;)
> 
> > MPlayer-playback get's heavy artefarcts (errors in decoding slice) when
> > two machine access the same channel (this can't be a network-problems as
> > the VDR-server and one client is connected to the switch by 1000Base-T
> > and the second client by 100Base-T).
> 
> Hey I said it works with mplayer, I didn't say it works with specificly TWO 
> mplayers. I've thought someone might use only one, or at least three or more, 
> so two is impossible ;)
> 

Really? Do I have to buy two or twenty additional machines? (My inmate
already has three machines in his room, so I'll have to upgrade soon -
maybe I can get some used Cray 2 or X from the NSA? ;o)

> Honestly, of course I'll have a look at that as soon as I get a second client 
> with graphics up and running ;). But are you sure it can't be a network 
> problem? When I am streaming one channel (Pro7), I have about 3,8-4,5 MB/sec 
> floating around. But since I don't know much about 1000Base-T and especially 
> not about mixing 1000 and 100, so I am afraid I cant say for sure anyway.

We do have a througput of about 4 MByte/s with 100BaseTX (ncftp
sometimes reaches 10 MByte/s) and more than 12 MByte/s (limit of my
harddisk, didn't test ram-disk-based transmission, yet) over 1000Base-T.

Watching two different channels by http works fine.

And something funny:

I've had MPlayer running with channel 3 (Pro-7) fine on my PC and then I
started another MPlayer-session on my notebook, but with -nosound as I
do have problems with sound driver.

And what happend? The picture on the notebook was fine, I got only a
nice still-picture on the PC - but - cristal-clear sound! When I started
with sound on the notebook, sound on the PC was gone.

Great feature - isn't it? ;o)

(And I tried to shift sound from one machine to another with ESD and
ARTS for at least two months without success!)

> 
> > As it seems duplicating the packets or opening a new receiver thread
> > (how did you implement it?) doesn't work properly, while recording and
> > watching by http works fine.
> 
> Currently every actual video stream has one receiver delivering the data. This 
> situation works locally without problems (I can record 3 channels 
> simultaneously without having artefacts on any of them, and every recording 
> is a receiver), and I've also recorded a channel locally and watched the same 
> one on my dxr3-client (that makes two receivers on the same channel)

As told above this works for me, too. But not several http-connections
on one channel.

> 
> This makes a lot of mysteries I'll start observing the next days...
> 

As soon as you get it working I'll declare you to my personal God of
streaming! ;o)

> Greetings,
> Sascha Volkenandt
> 
> P.S.: I've *just* been observing my http stream (displayed by mplayer) begin 
> to show artifacts, and the server had buffer overflows. Funnily, pausing the 
> mplayer replay "paused" the live picture as well (?!?). Both the same 
> channel, and the Server had transfer mode involved (the 
> two-receivers-at-one-channel situation). So at least now I know what you mean 
> ;)
> 

At least one who understands me! Let's hug! ;o)

But to be serious, I get the impression there's a buffer-handling
problem in transfer-mode of VDR. When one receiver-thread cannot take
over enough or as much data as the others the source-stream seems to
stop/slow down affecting all other receiver-threads on that channel.

The 100BaseTX- and 1000BaseT-mix could be the reason that I have such a
lot of problems as the transfer-mode gets crazy with two different media
speeds (significant change of behavior when using caching in MPlayer
seems to confirm that).

Rene



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.