Daniel Kristjansson wrote:
On Fri, 2005-05-06 at 07:30 +0100, Terry Barnaby wrote:
Your OSD fix in CVS has certainly fixed the problem with changing
channels due to the OSD locks. Thanks. Things are much better now.
However I have still had a channel change fail after quite a few
changes. Here is a
On Fri, 2005-05-06 at 07:30 +0100, Terry Barnaby wrote:
> > Your OSD fix in CVS has certainly fixed the problem with changing
> > channels due to the OSD locks. Thanks. Things are much better now.
> > However I have still had a channel change fail after quite a few
> > changes. Here is an example w
Your OSD fix in CVS has certainly fixed the problem with changing
channels due to the OSD locks. Thanks. Things are much better now.
However I have still had a channel change fail after quite a few
changes. Here is an example where two channel changes worked Ok
and the third failed. On the third ca
Terry Barnaby wrote:
Hi Daniel,
XvMC VLD in a Via M10K box is now working better, but still not right.
The main problem now is that sometimes channel changes work and
sometimes they don't.
I have tracked this down to an issue with the OSD.
When the channel change fails the code is stuck in
VideoOut
Hi Daniel/Terry,
Thought I'd confirm that commenting out the Delete/createBuffers() gets
channel change working for me too. ;-)
Neale.
Terry Barnaby wrote:
> Hi Daniel,
>
> XvMC VLD in a Via M10K box is now working better, but still not right.
> The main problem now is that sometimes channel ch
> Great stuff! I've applied this patch to 0.18
> and I can now change channel :)
Doesn't seem to work for me :(
Before I applied the patch I got garbage
video if I changed DVB channel, now
frontend just exits.
Channel changes are fine with non-DVB or
if I switch off XvMC.
I'm using XvMC with lat
On Wed, 2005-04-27 at 09:31 +0100, Terry Barnaby wrote:
> Hi,
> I also notice that when a stream is removed in av_remove_stream():2099
> it manages its list of streams by moving up a complex data structure
> with a memmove() routine. This is a potentialy very dangerous thing
> to do with complex d
Hi,
My investigations into this are leading to the fact that there is a bug
in the MPEG TS handling in libavformat or libavcodecs. At least when
XvMC VLD is involved but possibly in all cases although other decoding
methods my cope with the bug better.
What "appears" to happen is that when the PMT
[EMAIL PROTECTED] <> wrote:
> Daniel Kristjansson wrote:
>> I think Doug had a test stream where the PMT changed every few
>> seconds.
>
> To be fair, I went to extremes to capture it, but...
>
> http://jekyl.no-ip.org/doug/change.mpg (22 MB) -- please be gentle to
> my cable modem.
>
> - -Doug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Kristjansson wrote:
> I think Doug had a test stream where the PMT changed every few seconds.
To be fair, I went to extremes to capture it, but...
http://jekyl.no-ip.org/doug/change.mpg (22 MB) -- please be gentle to my
cable modem.
- -Doug
-
On Tue, 2005-04-26 at 06:34 +0100, Terry Barnaby wrote:
> > Hmm, do you know who wrote the VLD part of avcodec?
> Yes, it was me :)
:)
> If you look at my "bug1" log from a few emails back, you will see
> that "something" is calling av_remove_stream() on a channel change
> when TS streams are in
Daniel Kristjansson wrote:
On Mon, 2005-04-25 at 23:00 +0100, Terry Barnaby wrote:
I don't think there is an issue with closing and re-opening the
context in XvMC VLD. So I am note sure your channel change
system will affect the problem.
There appears to be a more fundemental problem in avcodec af
On Mon, 2005-04-25 at 23:00 +0100, Terry Barnaby wrote:
> > I don't think there is an issue with closing and re-opening the
> > context in XvMC VLD. So I am note sure your channel change
> > system will affect the problem.
> >
> > There appears to be a more fundemental problem in avcodec after
>
Terry Barnaby wrote:
Daniel Kristjansson wrote:
On Mon, 2005-04-25 at 21:41 +0100, Terry Barnaby wrote:
My enclosed attachments show some part of the sequence before changing
the channel (working1) and the first bit after (bug1).
The Via XvMC system gets a XvMCLoadQMatrix(),XvMCBeginSurface()
seque
Daniel Kristjansson wrote:
On Mon, 2005-04-25 at 21:41 +0100, Terry Barnaby wrote:
My enclosed attachments show some part of the sequence before changing
the channel (working1) and the first bit after (bug1).
The Via XvMC system gets a XvMCLoadQMatrix(),XvMCBeginSurface()
sequence then a lot of XvM
On Mon, 2005-04-25 at 21:41 +0100, Terry Barnaby wrote:
>
> My enclosed attachments show some part of the sequence before changing
> the channel (working1) and the first bit after (bug1).
> The Via XvMC system gets a XvMCLoadQMatrix(),XvMCBeginSurface()
> sequence then a lot of XvMCFlushSurface(),
On Mon, 2005-04-25 at 16:59 +0100, Terry Barnaby wrote:
> I am one of the unichrome people, and the one responsible for the
> original MythTV XvMC VLD implementation.
> I am happy to have a look at this issue.
> In what way do you think that "the Unichrome drivers don't deal with
> stream changes
Here is a little more feedback on this problem.
It appears that the Xv/XvMC/avcodec system has not recondigured itself
properly after a channel change.
I have put debug messages in the libviaXvMC library to see what is called.
You should see a sequence like:
XvMCLoadQMatrix:
XvMCBeginSurface:
XvMCP
Terry Barnaby wrote:
Daniel Kristjansson wrote:
On Mon, 2005-04-25 at 06:52 +0100, Terry Barnaby wrote:
Hi,
The current MythTv CVS version (2004-04-25) of the Xv/XvMC merge
appears to be broken on a Via M10K box using XvMC VLD acceleration.
Problems are:
1. If DVB-T cards are set to TS mode the s
Daniel Kristjansson wrote:
On Mon, 2005-04-25 at 06:52 +0100, Terry Barnaby wrote:
Hi,
The current MythTv CVS version (2004-04-25) of the Xv/XvMC merge appears
to be broken on a Via M10K box using XvMC VLD acceleration.
Problems are:
1. If DVB-T cards are set to TS mode the system will show TV
On Mon, 2005-04-25 at 06:52 +0100, Terry Barnaby wrote:
> Hi,
>
> The current MythTv CVS version (2004-04-25) of the Xv/XvMC merge appears
> to be broken on a Via M10K box using XvMC VLD acceleration.
>
> Problems are:
> 1. If DVB-T cards are set to TS mode the system will show TV
> on sta
Hi Terry,
On 4/25/05, Terry Barnaby <[EMAIL PROTECTED]> wrote:
> The current MythTv CVS version (2004-04-25) of the Xv/XvMC merge appears
> to be broken on a Via M10K box using XvMC VLD acceleration.
>
> Problems are:
> 1. If DVB-T cards are set to TS mode the system will show TV
> on sta
Terry Barnaby wrote:
Hi,
The current MythTv CVS version (2004-04-25) of the Xv/XvMC merge appears
to be broken on a Via M10K box using XvMC VLD acceleration.
Problems are:
1. If DVB-T cards are set to TS mode the system will show TV
on startup, but will fail on channel change.
Before chan
23 matches
Mail list logo
