Mailing List Archive: MythTV: Dev

XVideo XvMC VLD broken

1 2

View All

Index | Next | Previous | View Threaded

terry1 at beam

May 2, 2005, 1:27 PM

Post #26 of 50 (2863 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken [In reply to]

Daniel Kristjansson wrote:
> On Mon, 2005-05-02 at 20:31 +0100, Terry Barnaby wrote:
>
>>Daniel Kristjansson wrote:
>>Thanks for adding the patch.
>>I agree there should not be an exit there, but there does not seem
>>to be a way of returning an error from this. I must admit, with my
>>searching through the libavformat and libavcodec code fro the problem
>>there is some room for improvement !
>
> Yep, though it is best to send fixes directly to ffmpeg, to keep
> syncing simpler. We've synced bugs back into the code from ffmpeg
> before.
>
>
>>Now I have got the channel changing working better, (although not
>>ideal as there should be no need to close down and re-create Codecs,
>>(this could be done in mpegts) ...), I would like to get the
>>new merged Xv/XvMC code working with XvMC VLD.
>>Is it worth me having a look at this now, or shall I hang fire untill
>>you have completed the change to the Xv/XvMC init ?
>
> Now is a good time, I'm holding back on Xv/XvMC changes this week
> to allow Andy Poling a chance to get his chromakey OSD patch ready
> for CVS.
>
> -- Daniel
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Ok, any pointer to get going ?
I have just re-compiled from CVS.
With XvMC VLD (bob deinterlace enabled or disabled) I get very
garbaled sound, Screen display is stuterry with frequent MPEG
blocking atifacts. CPU usage is about 14%, which is low
(normally about 18%).
Mythfront end gives the following error messages:

2005-05-02 21:13:24.504 AddInheritence(A ) Error, future=frame
2005-05-02 21:13:24.747 AddInheritence( B ) Error, future=frame
2005-05-02 21:13:24.984 AddInheritence( C ) Error, future=frame
2005-05-02 21:13:25.463 AddInheritence( D ) Error, future=frame
2005-05-02 21:13:25.704 AddInheritence( E ) Error, future=frame
2005-05-02 21:13:25.944 AddInheritence( F ) Error, future=frame
2005-05-02 21:13:26.429 AddInheritence(A ) Error, future=frame
2005-05-02 21:13:26.661 AddInheritence( B ) Error, future=frame
2005-05-02 21:13:26.904 AddInheritence( C ) Error, future=frame
2005-05-02 21:13:27.384 AddInheritence( D ) Error, future=frame
2005-05-02 21:13:27.623 AddInheritence( E ) Error, future=frame
2005-05-02 21:13:27.864 AddInheritence( F ) Error, future=frame

When set to use Xv display and sound is fine although CPU usage
is greater than MythTv CVS 2005-04-22 80% versis 70%.

Cheers

Terry

terry1 at beam

May 2, 2005, 1:30 PM

Post #27 of 50 (2868 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken [In reply to]

terry1 at beam

May 2, 2005, 11:31 PM

Post #28 of 50 (2848 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken [In reply to]

Terry Barnaby wrote:
> Daniel Kristjansson wrote:
>
>> On Mon, 2005-05-02 at 20:31 +0100, Terry Barnaby wrote:
>>
>>> Daniel Kristjansson wrote:
>>> Thanks for adding the patch.
>>> I agree there should not be an exit there, but there does not seem
>>> to be a way of returning an error from this. I must admit, with my
>>> searching through the libavformat and libavcodec code fro the problem
>>> there is some room for improvement !
>>
>>
>> Yep, though it is best to send fixes directly to ffmpeg, to keep
>> syncing simpler. We've synced bugs back into the code from ffmpeg
>> before.
>>
>>
>>> Now I have got the channel changing working better, (although not
>>> ideal as there should be no need to close down and re-create Codecs,
>>> (this could be done in mpegts) ...), I would like to get the
>>> new merged Xv/XvMC code working with XvMC VLD.
>>> Is it worth me having a look at this now, or shall I hang fire untill
>>> you have completed the change to the Xv/XvMC init ?
>>
>>
>> Now is a good time, I'm holding back on Xv/XvMC changes this week
>> to allow Andy Poling a chance to get his chromakey OSD patch ready
>> for CVS.
>>
>> -- Daniel
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev [at] mythtv
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
> Ok, any pointer to get going ?
> I have just re-compiled from CVS.
> With XvMC VLD (bob deinterlace enabled or disabled) I get very
> garbaled sound, Screen display is stuterry with frequent MPEG
> blocking atifacts. CPU usage is about 14%, which is low
> (normally about 18%).
> Mythfront end gives the following error messages:
>
> 2005-05-02 21:13:24.504 AddInheritence(A ) Error, future=frame
> 2005-05-02 21:13:24.747 AddInheritence( B ) Error, future=frame
> 2005-05-02 21:13:24.984 AddInheritence( C ) Error, future=frame
> 2005-05-02 21:13:25.463 AddInheritence( D ) Error, future=frame
> 2005-05-02 21:13:25.704 AddInheritence( E ) Error, future=frame
> 2005-05-02 21:13:25.944 AddInheritence( F ) Error, future=frame
> 2005-05-02 21:13:26.429 AddInheritence(A ) Error, future=frame
> 2005-05-02 21:13:26.661 AddInheritence( B ) Error, future=frame
> 2005-05-02 21:13:26.904 AddInheritence( C ) Error, future=frame
> 2005-05-02 21:13:27.384 AddInheritence( D ) Error, future=frame
> 2005-05-02 21:13:27.623 AddInheritence( E ) Error, future=frame
> 2005-05-02 21:13:27.864 AddInheritence( F ) Error, future=frame
>
> When set to use Xv display and sound is fine although CPU usage
> is greater than MythTv CVS 2005-04-22 80% versis 70%.
>
> Cheers
>
>
> Terry
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Hi Daniel,

Another point of information on this:
I can get rid of the "AddInheritence" error messages by removing
line 77 in xvmcvldvideo.c
"render->p_future_surface = render->p_surface;"
This line may be incorrect ...

This does not affect things much. With some debug turned on I get
the following info, it appears that the video is going at half
frame rate ???

2005-05-03 07:23:09.039 A/V diverged by 6.41477 frames, extending frame
to keep
audio in sync
2005-05-03 07:23:09.119 A/V diverged by 6.44233 frames, extending frame
to keep
audio in sync
2005-05-03 07:23:09.199 A/V diverged by 6.57548 frames, extending frame
to keep
audio in sync
2005-05-03 07:23:09.208 positionMap[ 42 ] == 10243932.
2005-05-03 07:23:09.279 A/V diverged by 6.6566 frames, extending frame
to keep a
udio in sync
2005-05-03 07:23:09.359 A/V diverged by 6.5362 frames, extending frame
to keep a
udio in sync
'video_output' mean = '79991.91', std. dev. = '565.37', fps = '12.50'

Terry

terry1 at beam

May 3, 2005, 1:34 AM

Post #29 of 50 (2871 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken [In reply to]

Terry Barnaby wrote:
> Terry Barnaby wrote:
>
>> Daniel Kristjansson wrote:
>>
>>> On Mon, 2005-05-02 at 20:31 +0100, Terry Barnaby wrote:
>>>
>>>> Daniel Kristjansson wrote:
>>>> Thanks for adding the patch.
>>>> I agree there should not be an exit there, but there does not seem
>>>> to be a way of returning an error from this. I must admit, with my
>>>> searching through the libavformat and libavcodec code fro the
>>>> problem there is some room for improvement !
>>>
>>>
>>>
>>> Yep, though it is best to send fixes directly to ffmpeg, to keep
>>> syncing simpler. We've synced bugs back into the code from ffmpeg
>>> before.
>>>
>>>
>>>> Now I have got the channel changing working better, (although not
>>>> ideal as there should be no need to close down and re-create Codecs,
>>>> (this could be done in mpegts) ...), I would like to get the
>>>> new merged Xv/XvMC code working with XvMC VLD.
>>>> Is it worth me having a look at this now, or shall I hang fire untill
>>>> you have completed the change to the Xv/XvMC init ?
>>>
>>>
>>>
>>> Now is a good time, I'm holding back on Xv/XvMC changes this week
>>> to allow Andy Poling a chance to get his chromakey OSD patch ready
>>> for CVS.
>>>
>>> -- Daniel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> mythtv-dev mailing list
>>> mythtv-dev [at] mythtv
>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>>
>>
>>
>> Ok, any pointer to get going ?
>> I have just re-compiled from CVS.
>> With XvMC VLD (bob deinterlace enabled or disabled) I get very
>> garbaled sound, Screen display is stuterry with frequent MPEG
>> blocking atifacts. CPU usage is about 14%, which is low
>> (normally about 18%).
>> Mythfront end gives the following error messages:
>>
>> 2005-05-02 21:13:24.504 AddInheritence(A ) Error, future=frame
>> 2005-05-02 21:13:24.747 AddInheritence( B ) Error, future=frame
>> 2005-05-02 21:13:24.984 AddInheritence( C ) Error, future=frame
>> 2005-05-02 21:13:25.463 AddInheritence( D ) Error, future=frame
>> 2005-05-02 21:13:25.704 AddInheritence( E ) Error, future=frame
>> 2005-05-02 21:13:25.944 AddInheritence( F ) Error, future=frame
>> 2005-05-02 21:13:26.429 AddInheritence(A ) Error, future=frame
>> 2005-05-02 21:13:26.661 AddInheritence( B ) Error, future=frame
>> 2005-05-02 21:13:26.904 AddInheritence( C ) Error, future=frame
>> 2005-05-02 21:13:27.384 AddInheritence( D ) Error, future=frame
>> 2005-05-02 21:13:27.623 AddInheritence( E ) Error, future=frame
>> 2005-05-02 21:13:27.864 AddInheritence( F ) Error, future=frame
>>
>> When set to use Xv display and sound is fine although CPU usage
>> is greater than MythTv CVS 2005-04-22 80% versis 70%.
>>
>> Cheers
>>
>>
>> Terry
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev [at] mythtv
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
> Hi Daniel,
>
> Another point of information on this:
> I can get rid of the "AddInheritence" error messages by removing
> line 77 in xvmcvldvideo.c
> "render->p_future_surface = render->p_surface;"
> This line may be incorrect ...
>
> This does not affect things much. With some debug turned on I get
> the following info, it appears that the video is going at half
> frame rate ???
>
> 2005-05-03 07:23:09.039 A/V diverged by 6.41477 frames, extending frame
> to keep
> audio in sync
> 2005-05-03 07:23:09.119 A/V diverged by 6.44233 frames, extending frame
> to keep
> audio in sync
> 2005-05-03 07:23:09.199 A/V diverged by 6.57548 frames, extending frame
> to keep
> audio in sync
> 2005-05-03 07:23:09.208 positionMap[ 42 ] == 10243932.
> 2005-05-03 07:23:09.279 A/V diverged by 6.6566 frames, extending frame
> to keep a
> udio in sync
> 2005-05-03 07:23:09.359 A/V diverged by 6.5362 frames, extending frame
> to keep a
> udio in sync
> 'video_output' mean = '79991.91', std. dev. = '565.37', fps = '12.50'
>
> Terry
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

It looks like the problem is with AVSync (again !).

If I set "disableaudio" in NupplePlayer.cpp video display is fine.
If I set "avsync_avg = frame_interval" at the top of
NuppelVideoPlayer::WarpFactor() all is Ok (bar audio delayed/infront).

What is supposed to happen in NuppelVideoPlayer::AVSync() when
"diverge > MAXDIVERGE" ?
Could it be that with XvMC VLD video frames are not actually "extended" ?

Terry

terry1 at beam

May 3, 2005, 1:17 PM

Post #30 of 50 (2861 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken [In reply to]

> It looks like the problem is with AVSync (again !).
>
> If I set "disableaudio" in NupplePlayer.cpp video display is fine.
> If I set "avsync_avg = frame_interval" at the top of
> NuppelVideoPlayer::WarpFactor() all is Ok (bar audio delayed/infront).
>
> What is supposed to happen in NuppelVideoPlayer::AVSync() when
> "diverge > MAXDIVERGE" ?
> Could it be that with XvMC VLD video frames are not actually "extended" ?
>
> Terry
>

I have put some debug statements into NuppelVideoPlayer::AVSync().
It appears that the Video output frame rate has been cut in half
(as it should be) and the correct Video frames are being output
at this rate however the audio seems to have slowed down to match ?
The Audio should be running at normal speed and would catch up with
the Video.
I note that if I set "enable Extra Audio Buffering" the situation
is improved drasticly. However, is this just covering up some
other issue ?
Any ideas on this ?

What I see is the following:

2005-05-03 21:09:07.629 A/V diverged by 6.47223 frames, extending frame
to keep audio in sync
BEAM: AVSync: 1115150947.630 Video: 63139634 Audio: 63139396 Diff: 238
WarpFactor: 253666 40000
2005-05-03 21:09:07.709 A/V diverged by 6.34165 frames, extending frame
to keep audio in sync
BEAM: AVSync: 1115150947.710 Video: 63139674 Audio: 63139441 Diff: 233
WarpFactor: 248499 40000
2005-05-03 21:09:07.789 A/V diverged by 6.21247 frames, extending frame
to keep audio in sync
BEAM: AVSync: 1115150947.790 Video: 63139714 Audio: 63139463 Diff: 251
WarpFactor: 249124 40000
2005-05-03 21:09:07.869 A/V diverged by 6.2281 frames, extending frame
to keep audio in sync
BEAM: AVSync: 1115150947.870 Video: 63139754 Audio: 63139486 Diff: 268
WarpFactor: 253843 40000
2005-05-03 21:09:07.949 A/V diverged by 6.34608 frames, extending frame
to keep audio in sync
BEAM: AVSync: 1115150947.950 Video: 63139794 Audio: 63139529 Diff: 265

Terry

ijr at case

May 3, 2005, 1:41 PM

Post #31 of 50 (2861 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken [In reply to]

On Tuesday 03 May 2005 04:17 pm, Terry Barnaby wrote:
> > It looks like the problem is with AVSync (again !).
> >
> > If I set "disableaudio" in NupplePlayer.cpp video display is fine.
> > If I set "avsync_avg = frame_interval" at the top of
> > NuppelVideoPlayer::WarpFactor() all is Ok (bar audio delayed/infront).
> >
> > What is supposed to happen in NuppelVideoPlayer::AVSync() when
> > "diverge > MAXDIVERGE" ?
> > Could it be that with XvMC VLD video frames are not actually "extended" ?
> >
> > Terry
>
> I have put some debug statements into NuppelVideoPlayer::AVSync().
> It appears that the Video output frame rate has been cut in half
> (as it should be) and the correct Video frames are being output
> at this rate however the audio seems to have slowed down to match ?
> The Audio should be running at normal speed and would catch up with
> the Video.
> I note that if I set "enable Extra Audio Buffering" the situation
> is improved drasticly. However, is this just covering up some
> other issue ?
> Any ideas on this ?

Extra audio buffering should be on for everyone, unless it otherwise causes
problems.

Isaac
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

terry1 at beam

May 3, 2005, 1:49 PM

Post #32 of 50 (2838 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken [In reply to]

Isaac Richards wrote:
> On Tuesday 03 May 2005 04:17 pm, Terry Barnaby wrote:
>
>>>It looks like the problem is with AVSync (again !).
>>>
>>>If I set "disableaudio" in NupplePlayer.cpp video display is fine.
>>>If I set "avsync_avg = frame_interval" at the top of
>>>NuppelVideoPlayer::WarpFactor() all is Ok (bar audio delayed/infront).
>>>
>>>What is supposed to happen in NuppelVideoPlayer::AVSync() when
>>>"diverge > MAXDIVERGE" ?
>>>Could it be that with XvMC VLD video frames are not actually "extended" ?
>>>
>>>Terry
>>
>>I have put some debug statements into NuppelVideoPlayer::AVSync().
>>It appears that the Video output frame rate has been cut in half
>>(as it should be) and the correct Video frames are being output
>>at this rate however the audio seems to have slowed down to match ?
>>The Audio should be running at normal speed and would catch up with
>>the Video.
>>I note that if I set "enable Extra Audio Buffering" the situation
>>is improved drasticly. However, is this just covering up some
>>other issue ?
>>Any ideas on this ?
>
>
> Extra audio buffering should be on for everyone, unless it otherwise causes
> problems.
>
> Isaac
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Ok, It appears to default to off and the settings indicate that it
should not normally be used. So should this be changed ?

I did not need to use this option prior to the XvMC/Xv merge ...
I just want to make sure it is not covering up some other issue, so
any ideas as to the reason that the Audio does not run at
normal speed when the Video has had its frame rate cut in half to allow
the audio to catch up ?

Cheers

Terry

ijr at case

May 3, 2005, 2:04 PM

Post #33 of 50 (2853 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken [In reply to]

On Tuesday 03 May 2005 04:49 pm, Terry Barnaby wrote:
> Ok, It appears to default to off and the settings indicate that it
> should not normally be used. So should this be changed ?
>
> I did not need to use this option prior to the XvMC/Xv merge ...
> I just want to make sure it is not covering up some other issue, so
> any ideas as to the reason that the Audio does not run at
> normal speed when the Video has had its frame rate cut in half to allow
> the audio to catch up ?

Err, it defaults to on in all recent versions of myth, and there's nothing in
the help text that says it shouldn't be used.

Isaac
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

terry1 at beam

May 3, 2005, 11:06 PM

Post #34 of 50 (2850 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken [In reply to]

Isaac Richards wrote:
> On Tuesday 03 May 2005 04:49 pm, Terry Barnaby wrote:
>
>>Ok, It appears to default to off and the settings indicate that it
>>should not normally be used. So should this be changed ?
>>
>>I did not need to use this option prior to the XvMC/Xv merge ...
>>I just want to make sure it is not covering up some other issue, so
>>any ideas as to the reason that the Audio does not run at
>>normal speed when the Video has had its frame rate cut in half to allow
>>the audio to catch up ?
>
>
> Err, it defaults to on in all recent versions of myth, and there's nothing in
> the help text that says it shouldn't be used.
>
> Isaac
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Shows how long I have been using MythTv with this box,
it defaulted to off when it was setup !

I do think the help text suggests it is an "extra" not
normal option to work around a particular bug though.

Anyway things are much better now with this option enabled,
I will send in my XvMC VLD codec patch.

Still does anyone know the reason that enabling the extra
audio buffering fixes this problem ?
I just want to make sure it is not covering up some other issue, so
any ideas as to the reason that the Audio does not run at
normal speed when the Video has had its frame rate cut in half to allow
the audio to catch up ?

Terry

terry1 at beam

May 3, 2005, 11:13 PM

Post #35 of 50 (2839 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken [In reply to]

Hi,

Included is a patch that fixes the error messages when XvMC VLD is
used with the latest XvMC/VLD merge.

Terry

Attachments:

xvmc_vld_3.patch (0.65 KB)

mythmail at richardstraat

May 3, 2005, 11:25 PM

Post #36 of 50 (2831 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken [In reply to]

Terry Barnaby schreef:

> Hi,
>
> Included is a patch that fixes the error messages when XvMC VLD is
> used with the latest XvMC/VLD merge.
>
> Terry

Great! Does it also fix the stutter when the osd is displayed? At the
moment I see prebuffering messages in between the AddInheritence errors
in the logs when the osd is on.

Steven
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

terry1 at beam

May 4, 2005, 1:24 AM

Post #37 of 50 (2836 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken: crash on channel change [In reply to]

The current MythTV CVS with XvMC VLD decoding crashes when changing
a channel.
This is due to to the test to see if a valid XvMC port is available
in the static function VideoOutputXv::GetBestSupportedCodec() on lines
820->838. This fails on a channel change as the latest XvMC code
does not close down the XvMC port and so no ports are available for the
test.
I'm not sure where is functionality should be put
(VideoOutputXv::InitXvMc() ?) so I have put a "#ifdef" around this
code.
A patch to fix this is enclosed, but as stated, the code really
needs a better change.

I think I may nearly be there with XvMC VLD decoding ...

Terry
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK
Email: terry [at] beam Web: www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
"Tandems are twice the fun !"

Attachments:

xvmc_vld_4.patch (0.62 KB)

mythtv-dev.spam at isismanor

May 4, 2005, 4:14 AM

Post #38 of 50 (2846 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken: crash on channel change [In reply to]

Hi Terry,

your xvmc_vld_4.patch fixes the crash, but I still 'hang' when I change
channel. I get this in the log, any clues? I'm running

CVS from 00:00GMT 2005-05-04
+ xtraview.v2.patch
+ xvmc_vld_3.patch
+ xvmc_vld_4.patch

Neale.

2005-05-04 12:11:04.678 Woo Hoo! We have more XvMC Surfaces than we need
2005-05-04 12:11:04.680 Snapping height to avoid scaling: disphoff 576,
dispyoff: 0
2005-05-04 12:11:04.681 Image size. dispxoff -150, dispyoff: 0,
dispwoff: 1021, disphoff: 576
2005-05-04 12:11:04.682 Image size. imgx 0, imgy: 0, imgw: 720, imgh: 576
2005-05-04 12:11:04.787 waiting for prebuffer... 6
2005-05-04 12:11:04.968 waiting for prebuffer... 7
2005-05-04 12:11:05.147 waiting for prebuffer... 8
2005-05-04 12:11:05.327 waiting for prebuffer... 9
2005-05-04 12:11:05.515 waiting for prebuffer... 10
2005-05-04 12:11:05.677 Prebuffer wait timed out 10 times.
2005-05-04 12:11:05.688 waiting for prebuffer... 0
2005-05-04 12:11:05.868 waiting for prebuffer... 1
2005-05-04 12:11:06.047 waiting for prebuffer... 2
2005-05-04 12:11:06.227 waiting for prebuffer... 3
2005-05-04 12:11:06.407 waiting for prebuffer... 4
2005-05-04 12:11:06.587 waiting for prebuffer... 5
2005-05-04 12:11:06.767 waiting for prebuffer... 6
2005-05-04 12:11:06.947 waiting for prebuffer... 7
2005-05-04 12:11:07.127 waiting for prebuffer... 8
2005-05-04 12:11:07.309 waiting for prebuffer... 9
2005-05-04 12:11:07.379 detectInterlace(Detect Scan, Interlaced Scan,
25, 576) ->Interlaced Scan
2005-05-04 12:11:07.380 Interlaced: Interlaced Scan video_height: 576
fps: 25
2005-05-04 12:11:07.381 positionMap[ 8 ] == 283504.
2005-05-04 12:11:07.487 waiting for prebuffer... 10
2005-05-04 12:11:07.574 Prebuffer wait timed out 10 times.
2005-05-04 12:11:07.575 Prebuffer wait timed out, and not enough free
frames. Discardingbuffers.
2005-05-04 12:11:07.576 VideoOutputXv::DiscardFrames() 1: UUUAAULU
2005-05-04 12:11:07.576 VideoOutputXv::DiscardFrames() 2: UUUAAULU
2005-05-04 12:11:07.577 VideoOutputXv::DiscardFrames() 3: UUUAAULU
2005-05-04 12:11:07.578 VideoOutputXv::DiscardFrames() 4: AdAAAAAd -- done()
2005-05-04 12:11:07.582 AddInheritence future G NOT in used or in
limbo. AdALAAAd
2005-05-04 12:11:07.587 prebuffering pause
2005-05-04 12:11:07.588 waiting for prebuffer... 0
2005-05-04 12:11:07.606 AddInheritence past G NOT in used or in
done. AdAULAAd
2005-05-04 12:11:09.875 Timed out waiting for free video buffers.
2005-05-04 12:11:12.075 Timed out waiting for free video buffers.
2005-05-04 12:11:14.274 Timed out waiting for free video buffers.
2005-05-04 12:11:16.474 Timed out waiting for free video buffers.
2005-05-04 12:11:18.673 Timed out waiting for free video buffers.
2005-05-04 12:11:20.873 Timed out waiting for free video buffers.
2005-05-04 12:11:23.073 Timed out waiting for free video buffers.
2005-05-04 12:11:25.272 Timed out waiting for free video buffers.
2005-05-04 12:11:27.472 Timed out waiting for free video buffers.
2005-05-04 12:11:29.672 Timed out waiting for free video buffers.
2005-05-04 12:11:31.871 Timed out waiting for free video buffers.
2005-05-04 12:11:34.071 Timed out waiting for free video buffers.
2005-05-04 12:11:36.270 Timed out waiting for free video buffers.

Terry Barnaby wrote:
> The current MythTV CVS with XvMC VLD decoding crashes when changing
> a channel.
> This is due to to the test to see if a valid XvMC port is available
> in the static function VideoOutputXv::GetBestSupportedCodec() on lines
> 820->838. This fails on a channel change as the latest XvMC code
> does not close down the XvMC port and so no ports are available for the
> test.
> I'm not sure where is functionality should be put
> (VideoOutputXv::InitXvMc() ?) so I have put a "#ifdef" around this
> code.
> A patch to fix this is enclosed, but as stated, the code really
> needs a better change.
>
> I think I may nearly be there with XvMC VLD decoding ...
>
>
> Terry
>
>
> ------------------------------------------------------------------------
>
> Index: libs/libmythtv/videoout_xv.cpp
> ===================================================================
> RCS file: /var/lib/mythcvs/mythtv/libs/libmythtv/videoout_xv.cpp,v
> retrieving revision 1.137
> diff -u -r1.137 videoout_xv.cpp
> --- libs/libmythtv/videoout_xv.cpp 4 May 2005 06:15:55 -0000 1.137
> +++ libs/libmythtv/videoout_xv.cpp 4 May 2005 08:12:51 -0000
> @@ -817,6 +817,7 @@
> }
>
> bool ok = true;
> +#ifdef ZAP
> if (ret>kCodec_NORMAL_END)
> {
> Window root;
> @@ -836,6 +837,7 @@
> X11S(XvUngrabPort(disp, port, CurrentTime));
> }
> }
> +#endif
> X11S(XCloseDisplay(disp));
>
> if (!ok)
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

terry1 at beam

May 4, 2005, 5:20 AM

Post #39 of 50 (2850 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken: crash on channel change [In reply to]

Neale Swinnerton wrote:
> Hi Terry,
>
> your xvmc_vld_4.patch fixes the crash, but I still 'hang' when I change
> channel. I get this in the log, any clues? I'm running
>
> CVS from 00:00GMT 2005-05-04
> + xtraview.v2.patch
> + xvmc_vld_3.patch
> + xvmc_vld_4.patch
>
> Neale.

I'm not sure, the build you have used sounds like the one I am using
except for the xtraview.v2.patch. You could try removing that ?
You could try a complete re-build and ldconfig ?
The system is working for me at the meonent, although I still
think there are issues ....

The settings I use:
1. Base MythTv CVS 2005-05-04
2. My xvmc_vld_2.patch is applied to fix the problem
of changing channels when a DVB source set to record
TS streams. (This is noew in CSV from 2005-05-02.
3. My xvmc_vld_3.patch and xvmc_vld_4.patch patches applied.
4. My MythTv config line is:
./configure --prefix=/usr --enable-xvmc-vld --cpu=pentium-mmx\
--enable-dvb-eit --enable-dvb\
--dvb-path=/data/src/MythTv/include; qmake mythtv.pro
Note: "--cpu=pentium-mmx" is needed to get MMX working (c3-2 might be better).
5. DVB-T cards are set to record TS streams.
6. DVB-T cards have the "Use HW Encoder" option set. Without
this some channels, that have multiple audio streams,
cause heavy stutter of the video/audio stream.
7. The "TVPlayback" de-interlace option is enabled and "bob"
de-interlace setting is selected.
8. The "TVPlayback" aspect override option is set to "fill".
9. The "TVPlayback" "XvMC VLD hardware decoder" option is set :)
10. The "Unichrome X-Server driver is set to "720x576Noscale" mode.
11. The file "/etc/X11/XvMCConfig has the line "libviaXvMC.so.1" in
it.

12. Set "Enable realtime priority threads"
13. Set "Use Video as Timebase" in "TVPlayback"
14. Set "Extra Audio Buffers" in "TVPlayback"

15. Main software is Fedora Core 3 with updates to 2005-04-07.
16. Kernel is 2.6.10-1.770_FC3
17. I use the Unichrome X-Driver of CVS date 2005.04.12.
18. I use the Unichrome libviaxvmc of CVS date 2005.04.04.
19. I use the Via DRM module from CVS date 2005.04.04.

Terry

mythtv-dev.spam at isismanor

May 4, 2005, 5:51 AM

Post #40 of 50 (2819 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken: crash on channel change [In reply to]

Terry Barnaby wrote:
> I'm not sure, the build you have used sounds like the one I am using
> except for the xtraview.v2.patch. You could try removing that ?
> You could try a complete re-build and ldconfig ?

Did a rebuild, still got the problem. The interesting thing is that the
first time I did a channel change it worked. The second time, I got
black screen and about 1/2 second of audio, then nothing, with similar
log as before. I don't know anything about the playback code, Is it
plausible that there is a race condition here? The video frames get sent
and lost, then the audio is sent and the f/e hangs waiting for the video?

> The system is working for me at the meonent, although I still
> think there are issues ....
>
> The settings I use:

I've got the same settings/config other than I'm using gentoo
2.6.11-gentoo-r6 + X-Driver/libviaxvmcx and drm from CVS on sat/sun.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

terry1 at beam

May 4, 2005, 5:58 AM

Post #41 of 50 (2843 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken: crash on channel change [In reply to]

Neale Swinnerton wrote:
>
> Terry Barnaby wrote:
>
>>I'm not sure, the build you have used sounds like the one I am using
>>except for the xtraview.v2.patch. You could try removing that ?
>>You could try a complete re-build and ldconfig ?
>
>
> Did a rebuild, still got the problem. The interesting thing is that the
> first time I did a channel change it worked. The second time, I got
> black screen and about 1/2 second of audio, then nothing, with similar
> log as before. I don't know anything about the playback code, Is it
> plausible that there is a race condition here? The video frames get sent
> and lost, then the audio is sent and the f/e hangs waiting for the video?
>
>
>>The system is working for me at the meonent, although I still
>>think there are issues ....
>>
>>The settings I use:
>
>
> I've got the same settings/config other than I'm using gentoo
> 2.6.11-gentoo-r6 + X-Driver/libviaxvmcx and drm from CVS on sat/sun.
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

I will have a further look at this later this week ...

Terry

mythtv-dev.spam at isismanor

May 4, 2005, 6:00 AM

Post #42 of 50 (2831 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken: crash on channel change [In reply to]

Terry Barnaby wrote:
>
>
> I will have a further look at this later this week ...

thanks Terry, much appreciated.

Neale.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

terry1 at beam

May 5, 2005, 2:21 AM

Post #43 of 50 (2834 views)
Permalink

XVideo XvMC VLD broken [In reply to]

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
VideoOutputXv::GetAvailableOSD() in the loop:
while (!xvmc_osd_available.size())
{
xvmc_osd_lock.unlock();
usleep(50);
xvmc_osd_lock.lock();
}
The error messages from mythfront end are:
"Timed out waiting for free video buffers."

I suspect there is a race hazard between the OSD for the channel
change and the re-initialisation of the XvMC system in:
VideoOutputXv::InputChanged().

I suspect that VideoOutputXv::InputChanged() should close down
the OSD before doing anything and then re-initialise after deleting
and re-instating the Video buffers.
Actually, is it actually necessary to delete and re-create the
Video buffers (could be done only if frame size has changed) ??
I actualy removed the deletion and re-creation of the video buffers
and the channel channes appeared to work Ok then.

I can look into this a bit more but you might be able to see the
cause and solution from the information above.

Terry

mythtv-dev.spam at isismanor

May 5, 2005, 7:31 AM

Post #44 of 50 (2839 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 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
> VideoOutputXv::GetAvailableOSD() in the loop:
> while (!xvmc_osd_available.size())
> {
> xvmc_osd_lock.unlock();
> usleep(50);
> xvmc_osd_lock.lock();
> }
> The error messages from mythfront end are:
> "Timed out waiting for free video buffers."
>
> I suspect there is a race hazard between the OSD for the channel
> change and the re-initialisation of the XvMC system in:
> VideoOutputXv::InputChanged().
>
> I suspect that VideoOutputXv::InputChanged() should close down
> the OSD before doing anything and then re-initialise after deleting
> and re-instating the Video buffers.
> Actually, is it actually necessary to delete and re-create the
> Video buffers (could be done only if frame size has changed) ??
> I actualy removed the deletion and re-creation of the video buffers
> and the channel channes appeared to work Ok then.
>
> I can look into this a bit more but you might be able to see the
> cause and solution from the information above.
>
> Terry
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

terry1 at beam

May 5, 2005, 11:03 PM

Post #45 of 50 (2830 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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
> VideoOutputXv::GetAvailableOSD() in the loop:
> while (!xvmc_osd_available.size())
> {
> xvmc_osd_lock.unlock();
> usleep(50);
> xvmc_osd_lock.lock();
> }
> The error messages from mythfront end are:
> "Timed out waiting for free video buffers."
>
> I suspect there is a race hazard between the OSD for the channel
> change and the re-initialisation of the XvMC system in:
> VideoOutputXv::InputChanged().
>
> I suspect that VideoOutputXv::InputChanged() should close down
> the OSD before doing anything and then re-initialise after deleting
> and re-instating the Video buffers.
> Actually, is it actually necessary to delete and re-create the
> Video buffers (could be done only if frame size has changed) ??
> I actualy removed the deletion and re-creation of the video buffers
> and the channel channes appeared to work Ok then.
>
> I can look into this a bit more but you might be able to see the
> cause and solution from the information above.
>
> Terry
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Hi Daniel,

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 case I get a frozen piucture
and heavily stuttery sound.
I will continue to investigate.
In this case the error messages where:

adding pes stream at pid 0x258 with type 2
adding pes stream at pid 0x259 with type 3
closing filter for pid 0x262
closing filter for pid 0x263
2005-05-06 06:58:14.747 Prebuffer wait timed out 10 times.
2005-05-06 06:58:14.837 AvFormatDecoder: Video has changed from 0x0 to
720x576.
2005-05-06 06:58:16.486 prebuffering pause
2005-05-06 06:58:16.993 prebuffering pause
2005-05-06 06:58:17.149 prebuffering pause
2005-05-06 06:58:17.307 prebuffering pause
2005-05-06 06:58:17.423 prebuffering pause
2005-05-06 06:58:17.485 prebuffering pause
2005-05-06 06:58:17.737 prebuffering pause
2005-05-06 06:58:19.988 ERROR: child A is already in available
adding pes stream at pid 0x262 with type 2
adding pes stream at pid 0x263 with type 3
closing filter for pid 0x258
closing filter for pid 0x259
2005-05-06 06:58:21.967 Prebuffer wait timed out 10 times.
2005-05-06 06:58:22.275 AvFormatDecoder: Video has changed from 0x0 to
720x576.
2005-05-06 06:58:24.727 prebuffering pause
2005-05-06 06:58:24.865 prebuffering pause
2005-05-06 06:58:25.005 prebuffering pause
2005-05-06 06:58:25.145 prebuffering pause
2005-05-06 06:58:25.280 prebuffering pause
2005-05-06 06:58:25.403 prebuffering pause
2005-05-06 06:58:25.447 prebuffering pause
2005-05-06 06:58:25.466 prebuffering pause
2005-05-06 06:58:29.167 ERROR: child B is already in available
2005-05-06 06:58:31.148 Prebuffer wait timed out 10 times.
adding pes stream at pid 0x200 with type 2
adding pes stream at pid 0x28a with type 4
closing filter for pid 0x262
closing filter for pid 0x263
2005-05-06 06:58:31.454 AvFormatDecoder: Video has changed from 0x0 to
704x576.
2005-05-06 06:58:32.598 prebuffering pause
2005-05-06 06:58:34.119 prebuffering pause
2005-05-06 06:58:34.194 prebuffering pause
2005-05-06 06:58:34.278 prebuffering pause
2005-05-06 06:58:34.354 prebuffering pause
2005-05-06 06:58:34.435 prebuffering pause
2005-05-06 06:58:34.505 prebuffering pause
2005-05-06 06:58:34.564 prebuffering pause
2005-05-06 06:58:34.624 prebuffering pause
2005-05-06 06:58:34.626 prebuffering pause
2005-05-06 06:58:34.646 prebuffering pause
2005-05-06 06:58:34.666 prebuffering pause
2005-05-06 06:58:34.686 prebuffering pause
2005-05-06 06:58:34.706 prebuffering pause
2005-05-06 06:58:34.726 prebuffering pause
2005-05-06 06:58:34.746 prebuffering pause
2005-05-06 06:58:34.766 prebuffering pause
2005-05-06 06:58:34.786 prebuffering pause
2005-05-06 06:58:34.806 prebuffering pause
2005-05-06 06:58:34.811 Prebuffer wait timed out 10 times.
2005-05-06 06:58:34.811 Prebuffer wait timed out, and not enough free
frames. Discarding buffers.
2005-05-06 06:58:34.822 AddInheritence future C NOT in used or in
limbo. AAAddL
2005-05-06 06:58:34.826 prebuffering pause
2005-05-06 06:58:34.838 AddInheritence future C NOT in used or in
limbo. AAAddU
2005-05-06 06:58:34.852 AddInheritence past C NOT in used or in
done. AAAddU
2005-05-06 06:58:34.944 prebuffering pause
2005-05-06 06:58:34.958 GetNextFreeFrame() served a busy frame C.
Dropping. UUUdAA
2005-05-06 06:58:35.062 prebuffering pause
2005-05-06 06:58:35.066 prebuffering pause
2005-05-06 06:58:35.086 prebuffering pause
2005-05-06 06:58:35.106 prebuffering pause

Terry

terry1 at beam

May 5, 2005, 11:30 PM

Post #46 of 50 (2814 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

> 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 case I get a frozen piucture
> and heavily stuttery sound.
> I will continue to investigate.
> In this case the error messages where:

Hi Daniel,

I have just tried setting the number of Video buffers from 8 to 16
on the line: videoout_xv.cpp:531 vbuffers.Init(...).
This seems to work around the problem of channel changing on my
Via M10K XvMC VLD box.

Although this is covering up the problem, in the longer run
do you think it is work increasing the number of video buffers
for XvMC VLD machines where the number of XvMC surfaces available
allow this ?

Terry

danielk at cat

May 6, 2005, 5:53 AM

Post #47 of 50 (2827 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 where two channel changes worked Ok
> > and the third failed. On the third case I get a frozen piucture
> > and heavily stuttery sound.
> > I will continue to investigate.
> > In this case the error messages where:
>
> Hi Daniel,
>
> I have just tried setting the number of Video buffers from 8 to 16
> on the line: videoout_xv.cpp:531 vbuffers.Init(...).
> This seems to work around the problem of channel changing on my
> Via M10K XvMC VLD box.

can you try adding
cerr<<xvmc_surfs.size()<<endl;
at line 1099, after the "xvmc_surfs=..." line.

And report back with the actual number of surfaces created.

> Although this is covering up the problem, in the longer run
> do you think it is work increasing the number of video buffers
> for XvMC VLD machines where the number of XvMC surfaces available
> allow this ?
If this is actually increasing the number of XvMC surfaces it may
be actually solving the problem for XvMC-VLD. There are a number of
machinations I go through to free XvMC buffers as soon as possible,
just because we have so few. With just a few more buffers there is
enough head room for the normal DiscardFrame(),ReleaseFrame()
mechanism to work.

Of course your problem may still exits on more limited hardware,
like the nvidia graphics cards...

-- Daniel

terry1 at beam

May 6, 2005, 9:01 AM

Post #48 of 50 (2812 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 an example where two channel changes worked Ok
>>>and the third failed. On the third case I get a frozen piucture
>>>and heavily stuttery sound.
>>>I will continue to investigate.
>>>In this case the error messages where:
>>
>>Hi Daniel,
>>
>>I have just tried setting the number of Video buffers from 8 to 16
>>on the line: videoout_xv.cpp:531 vbuffers.Init(...).
>>This seems to work around the problem of channel changing on my
>>Via M10K XvMC VLD box.
>
>
> can you try adding
> cerr<<xvmc_surfs.size()<<endl;
> at line 1099, after the "xvmc_surfs=..." line.
>
> And report back with the actual number of surfaces created.
>
>
>>Although this is covering up the problem, in the longer run
>>do you think it is work increasing the number of video buffers
>>for XvMC VLD machines where the number of XvMC surfaces available
>>allow this ?
>
> If this is actually increasing the number of XvMC surfaces it may
> be actually solving the problem for XvMC-VLD. There are a number of
> machinations I go through to free XvMC buffers as soon as possible,
> just because we have so few. With just a few more buffers there is
> enough head room for the normal DiscardFrame(),ReleaseFrame()
> mechanism to work.
>
> Of course your problem may still exits on more limited hardware,
> like the nvidia graphics cards...
>
> -- Daniel
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Hi Daniel,

On my Via M10K box I get "16" surfaces. That is why I set the
number of buffers to 16 :)

Terry

mythmail at richardstraat

May 10, 2005, 1:27 PM

Post #49 of 50 (2779 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken: crash on channel change [In reply to]

Terry Barnaby schreef:

> The current MythTV CVS with XvMC VLD decoding crashes when changing
> a channel.
> This is due to to the test to see if a valid XvMC port is available
> in the static function VideoOutputXv::GetBestSupportedCodec() on lines
> 820->838. This fails on a channel change as the latest XvMC code
> does not close down the XvMC port and so no ports are available for the
> test.
> I'm not sure where is functionality should be put
> (VideoOutputXv::InitXvMc() ?) so I have put a "#ifdef" around this
> code.
> A patch to fix this is enclosed, but as stated, the code really
> needs a better change.
>
> I think I may nearly be there with XvMC VLD decoding ...
>
>
> Terry

Terry,

Just wondering. Am I supposed to use your xvmc_vld_3 and 4.patch or are
these issues fixed with the code Daniel checked in to fix the OSD?
I'm asking because I get prebuffers with xvmc-vld on my epia M10000 with
current cvs (without your patches). The prebuffers get worse when the
osd is displayed.

Steven
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

terry1 at beam

May 11, 2005, 1:54 AM

Post #50 of 50 (2751 views)
Permalink

Re: [PATCH] XVideo XvMC VLD broken: crash on channel change [In reply to]

Steven wrote:
> Terry Barnaby schreef:
>
>> The current MythTV CVS with XvMC VLD decoding crashes when changing
>> a channel.
>> This is due to to the test to see if a valid XvMC port is available
>> in the static function VideoOutputXv::GetBestSupportedCodec() on lines
>> 820->838. This fails on a channel change as the latest XvMC code
>> does not close down the XvMC port and so no ports are available for the
>> test.
>> I'm not sure where is functionality should be put
>> (VideoOutputXv::InitXvMc() ?) so I have put a "#ifdef" around this
>> code.
>> A patch to fix this is enclosed, but as stated, the code really
>> needs a better change.
>>
>> I think I may nearly be there with XvMC VLD decoding ...
>>
>>
>> Terry
>
>
> Terry,
>
> Just wondering. Am I supposed to use your xvmc_vld_3 and 4.patch or are
> these issues fixed with the code Daniel checked in to fix the OSD?
> I'm asking because I get prebuffers with xvmc-vld on my epia M10000 with
> current cvs (without your patches). The prebuffers get worse when the
> osd is displayed.
>
> Steven
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Hi,

The current status with me is that MythTv CVS 2005-05-06 with the
enclosed patch works quite well with my Via M10K box. My
xvmc_vld patches 1,2,3 and 4 are already in the CVS as of the CVS
date above.
The enclosed patch is a bit of a hack, something better should
be done, but it does work. It just increases the number of
Vbuffers from 8 to 16 for XvMC VLD HW MPEG acceleration.

Terry

Attachments:

xvmc_vld_5.patch (1.82 KB)

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads