mplayer + bktr

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

mplayer + bktr

Daniel O'Connor-3
Hi,
I'm trying to use mplayer to watch TV and while it does work it has a few
problems.

The first is that when you force it to capture audio (so mute and volume
control work, or you can use mencoder) it does about 0.25 fps :( It doesn't
appear to be using heaps of CPU or anything so I am not sure what the problem
is.

The other is that it hitches when playing TV - it doesn't do this when viewing
movies.

Has anyone else used mplayer for this? Do you see these problems? Anyone have
any suggestions or solutions?

The PC is running 5.4 and is an 900Mhz Athlon. The TV card is some generic
bktr card with no EEPROM.

I have the following in .mplayer/config if anyone is interested.

tv=driver=bsdbt848:input=1:norm=PAL:chanlist=australia:channels=2-ABC,7-SAS7,9-NINE,10-TEN,28-SBS

It would be nice to iron out this stuff because applying the mplayer post
processing filters to TV makes it look much nicer :)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mplayer + bktr

Miguel Mendez
Hi there,

> The first is that when you force it to capture audio (so mute and volume
> control work, or you can use mencoder) it does about 0.25 fps :( It doesn't
> appear to be using heaps of CPU or anything so I am not sure what the problem
> is.

I haven't tried this yet but can give it a go.

> The other is that it hitches when playing TV - it doesn't do this when viewing
> movies.

After trying to figure out why tv support wasn't there I've added the
" --enable-tv-bsdbt848" to the configure args and it's warking
flawlessly on my AMD64 box. This is 0.99.7_6. The output is crystal
clear here.

> Has anyone else used mplayer for this? Do you see these problems? Anyone
> have any suggestions or solutions?

Have you tried with xawtv and fxtv? Does the problem only show with
mplayer? What other build options did you enable when building the
software?

>tv=driver=bsdbt848:input=1:norm=PAL:chanlist=australia:channels=2-ABC,7-SAS7,9-NINE,10-TEN,28-SBS

I have a similar config except set for Europe.

> It would be nice to iron out this stuff because applying the mplayer post
> processing filters to TV makes it look much nicer :)

Yes, it rocks. I've been using xawtv for a month and mplayer is so
much better. :)

Cheers,
--
        Miguel Mendez <[hidden email]>
        http://energyhq.blogspot.com
        PGP Key: 0xDC8514F1
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: mplayer + bktr

Daniel O'Connor-3
On Mon, 14 Nov 2005 01:00, Miguel Mendez wrote:
> > The first is that when you force it to capture audio (so mute and volume
> > control work, or you can use mencoder) it does about 0.25 fps :( It
> > doesn't appear to be using heaps of CPU or anything so I am not sure what
> > the problem is.
>
> I haven't tried this yet but can give it a go.

If you add immediatemode=0 to the tv args it will do it.

> > The other is that it hitches when playing TV - it doesn't do this when
> > viewing movies.
>
> After trying to figure out why tv support wasn't there I've added the
> " --enable-tv-bsdbt848" to the configure args and it's warking
> flawlessly on my AMD64 box. This is 0.99.7_6. The output is crystal
> clear here.

Hmm, I didn't think I needed to do that, but I am not 100% sure.

> > Has anyone else used mplayer for this? Do you see these problems? Anyone
> > have any suggestions or solutions?
>
> Have you tried with xawtv and fxtv? Does the problem only show with
> mplayer? What other build options did you enable when building the
> software?

I don't use either of those, but a small program I wrote which captures YUV
frames and uses the Xv extension doesn't show the problem.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mplayer + bktr

Miguel Mendez
Hi there,

On 11/13/05, Daniel O'Connor <[hidden email]> wrote:
> On Mon, 14 Nov 2005 01:00, Miguel Mendez wrote:
> > > The first is that when you force it to capture audio (so mute and volume
> > > control work, or you can use mencoder) it does about 0.25 fps :( It
> > > doesn't appear to be using heaps of CPU or anything so I am not sure what
> > > the problem is.
> >
> > I haven't tried this yet but can give it a go.
>
> If you add immediatemode=0 to the tv args it will do it.

I've just tried that and the speed drops to something like 5-6 fps.
Interesting problem.

> > After trying to figure out why tv support wasn't there I've added the
> > " --enable-tv-bsdbt848" to the configure args and it's warking
> > flawlessly on my AMD64 box. This is 0.99.7_6. The output is crystal
> > clear here.
>
> Hmm, I didn't think I needed to do that, but I am not 100% sure.

The reason I did that was because before doing so mplayer complained
about the bsdbt848 driver not being there. I don't think it's related
to your problem.

> > Have you tried with xawtv and fxtv? Does the problem only show with
> > mplayer? What other build options did you enable when building the
> > software?
>
> I don't use either of those, but a small program I wrote which captures YUV
> frames and uses the Xv extension doesn't show the problem.

Since this bug is reproducible next step would be building a mplayer
binary with -g and try to find out what's going on. Maybe you could
try the mplayer lists to see if this problem appears on other systems.
I'll try to do some research as well.

Cheers,
--
        Miguel Mendez <[hidden email]>
        http://www.energyhq.es.eu.org
        PGP Key: 0xDC8514F1
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: mplayer + bktr

Daniel O'Connor-3
On Mon, 14 Nov 2005 07:13, Miguel Mendez wrote:
> > If you add immediatemode=0 to the tv args it will do it.
>
> I've just tried that and the speed drops to something like 5-6 fps.
> Interesting problem.

Yeah, I suspect there is something wrong with the audio sampling, but I
haven't looked at it properly.

> > I don't use either of those, but a small program I wrote which captures
> > YUV frames and uses the Xv extension doesn't show the problem.
>
> Since this bug is reproducible next step would be building a mplayer
> binary with -g and try to find out what's going on. Maybe you could
> try the mplayer lists to see if this problem appears on other systems.
> I'll try to do some research as well.

Yeah, the long haul :(
I was hoping for a magic wand ;)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mplayer + bktr

Danny Pansters
On Monday 14 November 2005 01:02, Daniel O'Connor wrote:
> On Mon, 14 Nov 2005 07:13, Miguel Mendez wrote:
> > > If you add immediatemode=0 to the tv args it will do it.
> >
> > I've just tried that and the speed drops to something like 5-6 fps.
> > Interesting problem.
>
> Yeah, I suspect there is something wrong with the audio sampling, but I
> haven't looked at it properly.

I myself am not really doing anything with capturing, but some ideas that may
be helpful:

FWIW, from what I know in ring capture mode the video gets synch'd by the
audio by having enough frames per audio sample. So if audio sample size or
expected speed or expected kHz is somehow wrong...

Also the code for ring capture mode (as opposed to immediate which does not do
audio but does give a video one could capture at 25 fps) has its own timing
(perhaps it uses rtc down the line, I dunno, is rtc.ko alright?). You may get
into a worst-worst-worst-even worst scenario where the software timer
degrades on and on possibly.

Maybe capturing only works well if you use immediate (case 2 in bktr(4) IIRC)
and you should capture audio seperately and later merge them to frames.

> > > I don't use either of those, but a small program I wrote which captures
> > > YUV frames and uses the Xv extension doesn't show the problem.
> >

Capturing only pictures at 25 fps (with mplayer vo) can be handled easily.

Dan
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: mplayer + bktr

Daniel O'Connor-3
On Mon, 14 Nov 2005 12:51, Danny Pansters wrote:
> I myself am not really doing anything with capturing, but some ideas that
> may be helpful:
>
> FWIW, from what I know in ring capture mode the video gets synch'd by the
> audio by having enough frames per audio sample. So if audio sample size or
> expected speed or expected kHz is somehow wrong...

Hmm..
Certainly worth instrumenting.. Although wading through the mplayer source is
always an 'interesting' experience :)

> Also the code for ring capture mode (as opposed to immediate which does not
> do audio but does give a video one could capture at 25 fps) has its own
> timing (perhaps it uses rtc down the line, I dunno, is rtc.ko alright?).
> You may get into a worst-worst-worst-even worst scenario where the software
> timer degrades on and on possibly.

FreeBSD doesn't have rtc.ko.. Mine doesn't anyway :)

I'm not sure how mplayer in FreeBSD stamps frames either.

> Maybe capturing only works well if you use immediate (case 2 in bktr(4)
> IIRC) and you should capture audio seperately and later merge them to
> frames.

Hmm, well in any capture you're going to have to worry about clock drift
(between the sound card and the bktr card) and dropped frames.

> > > > I don't use either of those, but a small program I wrote which
> > > > captures YUV frames and uses the Xv extension doesn't show the
> > > > problem.
>
> Capturing only pictures at 25 fps (with mplayer vo) can be handled easily.

Hmm OK.

So much to learn! :)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: mplayer + bktr

Stephen Hurd
Daniel O'Connor wrote:

>FreeBSD doesn't have rtc.ko.. Mine doesn't anyway :)
>
>I'm not sure how mplayer in FreeBSD stamps frames either.
>  
>
It's not stock, but /dev/rtc (via rtc.ko) can be had via emulators/rtc
if rtc.ko exists, it's a dependency, to force it to be built you can
frob the WITH_RTC knob.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: mplayer + bktr

Steve O'Hara-Smith
In reply to this post by Daniel O'Connor-3
On Sun, 13 Nov 2005 22:04:48 +1030
"Daniel O'Connor" <[hidden email]> wrote:

> The first is that when you force it to capture audio (so mute and volume
> control work, or you can use mencoder) it does about 0.25 fps :( It doesn't
> appear to be using heaps of CPU or anything so I am not sure what the problem
> is.
>
> The other is that it hitches when playing TV - it doesn't do this when viewing
> movies.

        I had a quick look at what has happened to the capture code in
mplayer since I last saw it (and felt a bit ill). It seems that it pretty
much depends on the frame sync signals from the bktr device with a fallback
one second alarm. I know that missing frame sync signals are not uncommon
from instrumenting my capture code in ffmpeg which is kept sane by using
a tightly timed usleep to capture a frame close ot the right time when the
signal is missed.

        I'm guessing that enabling the audio capture is causing signals
to be missed.

--
C:>WIN                                      |   Directable Mirror Arrays
The computer obeys and wins.                | A better way to focus the sun
You lose and Bill collects.                 |    licences available see
                                            |    http://www.sohara.org/
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: mplayer + bktr

Daniel O'Connor-3
On Wed, 16 Nov 2005 20:49, Steve O'Hara-Smith wrote:
> I had a quick look at what has happened to the capture code in
> mplayer since I last saw it (and felt a bit ill). It seems that it pretty
> much depends on the frame sync signals from the bktr device with a fallback
> one second alarm. I know that missing frame sync signals are not uncommon
> from instrumenting my capture code in ffmpeg which is kept sane by using
> a tightly timed usleep to capture a frame close ot the right time when the
> signal is missed.

Hmm I see..

> I'm guessing that enabling the audio capture is causing signals
> to be missed.

Strange.. I wouldn't expect to miss signals.. Missing frames I can believe -
the picture quality sucks due to a long cable.

Time to dig into the code myself I guess :)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

attachment0 (194 bytes) Download Attachment