[mythtv] ring buffer and live TV

[Felix Rubinstein]

Why do you impose limitations on users?
Why not to let it choose what he/she wants?
Did it ever occured to you that your're doing a project for many users or
you always though about running it on different hardware?

And what about live tv, really live like real-time live tv with buffering
capabilities, man, you have commercial products doing it on old hardware
pretty good with 0 (zero) delay!

Improper use of myth, what improper in connecting myth with S-Video without
EPG?
Guys, stop imposing limitations, your're running on Linux, you have all the
fancy libraries and OS, just don't impose limitations on users, give it a
chance by any mean, copilation flag, run-time flag, anything.

Thanks.



On 4/15/06, Isaac Richards <ijr at case.edu> wrote:
>
> On Saturday 15 April 2006 09:11, Daniel Kristjansson wrote:
> > On Sat, 2006-04-15 at 14:43 +0200, Felix Rubinstein wrote:
> > > Please see my posts on users list by topic "MythTV channel buffer"
> > > How is that possible to watch live TV and have PVR: pause, rewind,
> > > etc. functionality with S-Video/RCA connection?
> > > What was the intention of quite large delay?
> >
> > MythTV needs to work on many different systems with different
> > video bitrates and different levels of hardware performance.
> > Hence the buffering requirements are somewhat conservative
> > compared to a dedicated piece of hardware. There are many
> > things that could be done to speed up channel changing without
> > ever touching the buffering code. But if you want this to improve,
> > you will have to implement it yourself as LiveTV performance
> > is not a huge priority for us. I would suggest benchmarking using
> > oprofile as the first step, to find the low hanging fruit.
> >
> > Then there are other things you could do, for instance the ring
> > buffer estimates the number of bytes it needs in the buffer
> > based on the bitrate estimate from ffmeg, but this isn't always
> > accurate. Maybe if the backend communicated the number of frames
> > sent/written it would improve performance, maybe not. At one
> > point we found that regular expression parsing of the channel
> > entry code was consuming massive amounts of CPU on Mac OS X
> > machines, benchmarking might reveal another such surprise.
> > There are also many usleeps in the code where a QWaitCondition
> > would suffice. Just go at it, benchmark everything and attach
> > small independent patches to trac.
>
> I won't accept patches to improve improper use of myth (in this case, not
> changing channels with myth).
>
> Isaac
>
> > -- Daniel
> >
> >
> >
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev at mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20060415/476d38cd/attachment.htm