Mailing List Archive: MythTV: Dev

XVideo XvMC VLD broken

1 2

View All

Index | Next | Previous | View Threaded

terry1 at beam

Apr 24, 2005, 10:52 PM

Post #1 of 50 (7465 views)
Permalink

XVideo XvMC VLD broken

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 changing channel I get the following Errors repeated:

2005-04-25 06:38:19.007 AddInheritence(A ) Error, future=frame
2005-04-25 06:38:19.127 AddInheritence( B ) Error, future=frame
2005-04-25 06:38:19.247 AddInheritence( C ) Error, future=frame
2005-04-25 06:38:19.487 AddInheritence( D ) Error, future=frame
2005-04-25 06:38:19.607 AddInheritence( E ) Error, future=frame
2005-04-25 06:38:19.727 AddInheritence( F ) Error, future=frame

After changing the channel I get:

2005-04-25 06:38:28.247 AddInheritence( E ) Error, future=frame
adding pes stream at pid 0xb03 with type 2
adding pes stream at pid 0xb04 with type 4
closing filter for pid 0x200
av_remove_stream 0x200
closing filter for pid 0x28a
av_remove_stream 0x28a
streams_changed()
2005-04-25 06:38:31.847 Prebuffer wait timed out 10 times.
2005-04-25 06:38:31.855 AvFormatDecoder: Video has changed from 0x0 to
704x576.
[mpegvideo_xvmc_vld @ 0x5e2874]XVMC_VLD_field_start: Unknown picture
coding type: 0
2005-04-25 06:38:33.827 Prebuffer wait timed out 10 times.
XvMCPutSlice: This context does not own decoder!
[mpegvideo_xvmc_vld @ 0x5e2874]XVMC_VLD_field_start: Unknown picture
coding type: 0
XvMCPutSlice: This context does not own decoder!
XvMCPutSlice: This context does not own decoder!
[mpegvideo_xvmc_vld @ 0x5e2874]XVMC_VLD_field_start: Unknown picture
coding type: 0
XvMCPutSlice: This context does not own decoder!
XvMCPutSlice: This context does not own decoder!
XvMCPutSlice: This context does not own decoder!
2005-04-25 06:38:49.147 AddInheritence( E ) Error, future=frame
XvMCPutSlice: This context does not own decoder!
XvMCPutSlice: This context does not own decoder!
XvMCPutSlice: This context does not own decoder!
XvMCPutSlice: This context does not own decoder!
XvMCPutSlice: This context does not own decoder!
XvMCPutSlice: This context does not own decoder!

I suspect this could be caused by not calling the XvMCSyncSurface().
This call releases the HWMPEG controller for other processes, and
I suspect a lock is not being released when it is not called.

2. If DVB-T cards are set to PS mode the system will show TV
on startup, but will fail on channel change.
Before changing channel I get the same errors as for TS mode:
After changeing I get no picture/sound with the following errors:

2005-04-25 06:48:23.866 Prebuffer wait timed out 10 times.
2005-04-25 06:48:24.482 AddInheritence(A ) Error, future=frame
2005-04-25 06:48:24.501 AddInheritence( B ) Error, future=frame
2005-04-25 06:48:26.714 Timed out waiting for free video buffers.
2005-04-25 06:48:28.913 Timed out waiting for free video buffers.
2005-04-25 06:48:31.113 Timed out waiting for free video buffers.
2005-04-25 06:48:33.312 Timed out waiting for free video buffers.
2005-04-25 06:48:35.512 Timed out waiting for free video buffers.
2005-04-25 06:48:37.711 Timed out waiting for free video buffers.
2005-04-25 06:48:39.911 Timed out waiting for free video buffers.
2005-04-25 06:48:42.111 Timed out waiting for free video buffers.

I suspect this is a DVB issue.

3. The sound/video stutter badly on channes with multile audio
channels. This used to be cleared by setting the DVB-T
option "HW Encoder", but this no longer seems to
work .... (Probably a DVB/AVCodec issue).

Terry

TV Client: Network boot Via M10K connected to TV with SVideo,
Unichrome drivers. Using XvMC VLD HW MPEG acceleration.
Server: 1G Celeron system with twin DVB-T cards
Software: Fedora core 3 with updates 2.6.10-1.770_FC3 kernel
MythTv: MythTv CVS 2005.04.25

terry1 at beam

Apr 24, 2005, 11:24 PM

Post #2 of 50 (7403 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 changing channel I get the following Errors repeated:
>
> 2005-04-25 06:38:19.007 AddInheritence(A ) Error, future=frame
> 2005-04-25 06:38:19.127 AddInheritence( B ) Error, future=frame
> 2005-04-25 06:38:19.247 AddInheritence( C ) Error, future=frame
> 2005-04-25 06:38:19.487 AddInheritence( D ) Error, future=frame
> 2005-04-25 06:38:19.607 AddInheritence( E ) Error, future=frame
> 2005-04-25 06:38:19.727 AddInheritence( F ) Error, future=frame
>
> After changing the channel I get:
>
> 2005-04-25 06:38:28.247 AddInheritence( E ) Error, future=frame
> adding pes stream at pid 0xb03 with type 2
> adding pes stream at pid 0xb04 with type 4
> closing filter for pid 0x200
> av_remove_stream 0x200
> closing filter for pid 0x28a
> av_remove_stream 0x28a
> streams_changed()
> 2005-04-25 06:38:31.847 Prebuffer wait timed out 10 times.
> 2005-04-25 06:38:31.855 AvFormatDecoder: Video has changed from 0x0 to
> 704x576.
> [mpegvideo_xvmc_vld @ 0x5e2874]XVMC_VLD_field_start: Unknown picture
> coding type: 0
> 2005-04-25 06:38:33.827 Prebuffer wait timed out 10 times.
> XvMCPutSlice: This context does not own decoder!
> [mpegvideo_xvmc_vld @ 0x5e2874]XVMC_VLD_field_start: Unknown picture
> coding type: 0
> XvMCPutSlice: This context does not own decoder!
> XvMCPutSlice: This context does not own decoder!
> [mpegvideo_xvmc_vld @ 0x5e2874]XVMC_VLD_field_start: Unknown picture
> coding type: 0
> XvMCPutSlice: This context does not own decoder!
> XvMCPutSlice: This context does not own decoder!
> XvMCPutSlice: This context does not own decoder!
> 2005-04-25 06:38:49.147 AddInheritence( E ) Error, future=frame
> XvMCPutSlice: This context does not own decoder!
> XvMCPutSlice: This context does not own decoder!
> XvMCPutSlice: This context does not own decoder!
> XvMCPutSlice: This context does not own decoder!
> XvMCPutSlice: This context does not own decoder!
> XvMCPutSlice: This context does not own decoder!
>
> I suspect this could be caused by not calling the XvMCSyncSurface().
> This call releases the HWMPEG controller for other processes, and
> I suspect a lock is not being released when it is not called.
>
> 2. If DVB-T cards are set to PS mode the system will show TV
> on startup, but will fail on channel change.
> Before changing channel I get the same errors as for TS mode:
> After changeing I get no picture/sound with the following errors:
>
> 2005-04-25 06:48:23.866 Prebuffer wait timed out 10 times.
> 2005-04-25 06:48:24.482 AddInheritence(A ) Error, future=frame
> 2005-04-25 06:48:24.501 AddInheritence( B ) Error, future=frame
> 2005-04-25 06:48:26.714 Timed out waiting for free video buffers.
> 2005-04-25 06:48:28.913 Timed out waiting for free video buffers.
> 2005-04-25 06:48:31.113 Timed out waiting for free video buffers.
> 2005-04-25 06:48:33.312 Timed out waiting for free video buffers.
> 2005-04-25 06:48:35.512 Timed out waiting for free video buffers.
> 2005-04-25 06:48:37.711 Timed out waiting for free video buffers.
> 2005-04-25 06:48:39.911 Timed out waiting for free video buffers.
> 2005-04-25 06:48:42.111 Timed out waiting for free video buffers.
>
> I suspect this is a DVB issue.
>
> 3. The sound/video stutter badly on channes with multile audio
> channels. This used to be cleared by setting the DVB-T
> option "HW Encoder", but this no longer seems to
> work .... (Probably a DVB/AVCodec issue).
>
> Terry
>
>
> TV Client: Network boot Via M10K connected to TV with SVideo,
> Unichrome drivers. Using XvMC VLD HW MPEG acceleration.
> Server: 1G Celeron system with twin DVB-T cards
> Software: Fedora core 3 with updates 2.6.10-1.770_FC3 kernel
> MythTv: MythTv CVS 2005.04.25
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Some more on this:
I modified the code in VideoOutputXv::SyncSurface() to call
XvMCSyncSurface(). However this bit of code is never called
during playback (something fishy here) ....

#ifdef ZAP
X11S(XvMCFlushSurface(disp, surf));
while (IsRendering(frame))
usleep(50);
#else
fprintf(stderr, "BEAM: Sync\n");
XvMCSyncSurface(disp, surf);
#endif

Terry

jstembridge at gmail

Apr 25, 2005, 1:24 AM

Post #3 of 50 (7368 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

Hi Terry,

On 4/25/05, Terry Barnaby <terry1 [at] beam> 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 startup, but will fail on channel change.
> Before changing channel I get the following Errors repeated:

I, and some others, have been seeing this behaviour with 0.18, though
I haven't had time to debug it myself as of yet. See this thread:

http://www.gossamer-threads.com/lists/mythtv/dev/108781

So perhaps the Xv/XvMC merge has merely exposed the same bug?

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

danielk at cat

Apr 25, 2005, 6:19 AM

Post #4 of 50 (7363 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 startup, but will fail on channel change.
> Before changing channel I get the following Errors repeated:
>
> 2005-04-25 06:38:19.007 AddInheritence(A ) Error, future=frame
> 2005-04-25 06:38:19.127 AddInheritence( B ) Error, future=frame
> 2005-04-25 06:38:19.247 AddInheritence( C ) Error, future=frame
> 2005-04-25 06:38:19.487 AddInheritence( D ) Error, future=frame
> 2005-04-25 06:38:19.607 AddInheritence( E ) Error, future=frame
> 2005-04-25 06:38:19.727 AddInheritence( F ) Error, future=frame

> I suspect this could be caused by not calling the XvMCSyncSurface().
> This call releases the HWMPEG controller for other processes, and
> I suspect a lock is not being released when it is not called.
We call XvMCSyncSurface(), the problem is that the Unichrome drivers
don't deal with stream changes gracefully. I'm making some changes
to the change channel code this week, once that settles down I'll
ask the unichrome people how to make channel changes work with
their stuff.

-- Daniel

terry1 at beam

Apr 25, 2005, 8:59 AM

Post #5 of 50 (7370 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 startup, but will fail on channel change.
>> Before changing channel I get the following Errors repeated:
>>
>>2005-04-25 06:38:19.007 AddInheritence(A ) Error, future=frame
>>2005-04-25 06:38:19.127 AddInheritence( B ) Error, future=frame
>>2005-04-25 06:38:19.247 AddInheritence( C ) Error, future=frame
>>2005-04-25 06:38:19.487 AddInheritence( D ) Error, future=frame
>>2005-04-25 06:38:19.607 AddInheritence( E ) Error, future=frame
>>2005-04-25 06:38:19.727 AddInheritence( F ) Error, future=frame
>
>
>>I suspect this could be caused by not calling the XvMCSyncSurface().
>>This call releases the HWMPEG controller for other processes, and
>>I suspect a lock is not being released when it is not called.
>
> We call XvMCSyncSurface(), the problem is that the Unichrome drivers
> don't deal with stream changes gracefully. I'm making some changes
> to the change channel code this week, once that settles down I'll
> ask the unichrome people how to make channel changes work with
> their stuff.
>
> -- Daniel
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Hi Daniel,

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 gracefully" ?

Cheers

Terry

terry1 at beam

Apr 25, 2005, 9:02 AM

Post #6 of 50 (7378 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 system will show TV
>>> on startup, but will fail on channel change.
>>> Before changing channel I get the following Errors repeated:
>>>
>>> 2005-04-25 06:38:19.007 AddInheritence(A ) Error, future=frame
>>> 2005-04-25 06:38:19.127 AddInheritence( B ) Error, future=frame
>>> 2005-04-25 06:38:19.247 AddInheritence( C ) Error, future=frame
>>> 2005-04-25 06:38:19.487 AddInheritence( D ) Error, future=frame
>>> 2005-04-25 06:38:19.607 AddInheritence( E ) Error, future=frame
>>> 2005-04-25 06:38:19.727 AddInheritence( F ) Error, future=frame
>>
>>
>>
>>> I suspect this could be caused by not calling the XvMCSyncSurface().
>>> This call releases the HWMPEG controller for other processes, and
>>> I suspect a lock is not being released when it is not called.
>>
>>
>> We call XvMCSyncSurface(), the problem is that the Unichrome drivers
>> don't deal with stream changes gracefully. I'm making some changes
>> to the change channel code this week, once that settles down I'll
>> ask the unichrome people how to make channel changes work with
>> their stuff.
>>
>> -- Daniel
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev [at] mythtv
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
> Hi Daniel,
>
> 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 gracefully" ?
>
> Cheers
>
> Terry
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Hi Daniel,

Can you tell me if the error messages:

"AddInheritence(A ) Error, future=frame"

Are a probem ??

Terry

terry1 at beam

Apr 25, 2005, 1:41 PM

Post #7 of 50 (7375 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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:
XvMCPutSlice2:
XvMCPutSlice2:
....
XvMCPutSlice2:
XvMCFlushSurface:
XvMCSyncSurface:

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(), XvMCSyncSurface() (Getting
rid of buffers ????) then a XvMCPutSlice2() that fails as it no
longer owns the decoder (No XvMCBeginSurface() after the last
XvMCSyncSurface().

Terry

Attachments:

working1 (1.94 KB)

bug1 (1.34 KB)

danielk at cat

Apr 25, 2005, 1:56 PM

Post #8 of 50 (7362 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 gracefully" ?

Well right now on channel changes we call XvMCHideSurface() on all the
XvMCSurfraces, then we call XvMCDestroyContext(), and then we create a
new context, and create new surfaces. But at this point the VLD driver
tells us we do not own the context.

The plan is to change this so that on channel changes we don't delete
the context at all, but rather just delete surfaces and recreate them
one surface at a time as they are needed. Hence I was going to consult
with you guys once I had that implemented, assuming this new
implementation cause problems for VLD.

These messages:
>>2005-04-25 06:38:19.007 AddInheritence(A ) Error, future=frame
mean that the p_future_surface is the same as p_surface. i.e. the frame
depends on itself. This doesn't cause problems within MythTV itself, but
can bring down the nvidia XvMC implementation. I don't know if it
causes problems for the Unichrome driver...

-- Daniel

danielk at cat

Apr 25, 2005, 1:59 PM

Post #9 of 50 (7375 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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(), XvMCSyncSurface() (Getting
> rid of buffers ????) then a XvMCPutSlice2() that fails as it no
> longer owns the decoder (No XvMCBeginSurface() after the last
> XvMCSyncSurface().

See my last message. I think the new channel change implementation
may remove this problem, since we won't delete the context at all.
But we will delete and create surfaces one at a time, so this may
cause other problems.

-- Daniel

terry1 at beam

Apr 25, 2005, 2:20 PM

Post #10 of 50 (7373 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 XvMCFlushSurface(), XvMCSyncSurface() (Getting
>>rid of buffers ????) then a XvMCPutSlice2() that fails as it no
>>longer owns the decoder (No XvMCBeginSurface() after the last
>>XvMCSyncSurface().
>
>
> See my last message. I think the new channel change implementation
> may remove this problem, since we won't delete the context at all.
> But we will delete and create surfaces one at a time, so this may
> cause other problems.
>
> -- Daniel
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Hi Daniel,

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
a channel change.
The XVMC_VLD_field_end() function is continuely called without
any XVMC_VLD_field_start() calls. It appears that avcodec is
trying to decode garbage ....

Terry

terry1 at beam

Apr 25, 2005, 3:00 PM

Post #11 of 50 (7364 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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()
>>> sequence then a lot of XvMCFlushSurface(), XvMCSyncSurface() (Getting
>>> rid of buffers ????) then a XvMCPutSlice2() that fails as it no
>>> longer owns the decoder (No XvMCBeginSurface() after the last
>>> XvMCSyncSurface().
>>
>>
>>
>> See my last message. I think the new channel change implementation may
>> remove this problem, since we won't delete the context at all.
>> But we will delete and create surfaces one at a time, so this may
>> cause other problems.
>>
>> -- Daniel
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev [at] mythtv
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
> Hi Daniel,
>
> 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
> a channel change.
> The XVMC_VLD_field_end() function is continuely called without
> any XVMC_VLD_field_start() calls. It appears that avcodec is
> trying to decode garbage ....
>
> Terry
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Hi Another point of information,

If the DVB-T frond end is set to PS rather than TS mode then
the channel change happens and XvMC VLD carries along quite happily
without any "This context does not own decoder!" messages.
The Vido output does fall over with a " Timed out waiting for free
video buffers" after a bit though.

There are other MythTv issues with av_remove_stream() could this
be something to do with the problem ....

Terry

danielk at cat

Apr 25, 2005, 3:40 PM

Post #12 of 50 (7358 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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
> > a channel change.
> > The XVMC_VLD_field_end() function is continuely called without
> > any XVMC_VLD_field_start() calls. It appears that avcodec is
> > trying to decode garbage ....
Hmm, do you know who wrote the VLD part of avcodec?

> If the DVB-T frond end is set to PS rather than TS mode then
> the channel change happens and XvMC VLD carries along quite happily
> without any "This context does not own decoder!" messages.
> The Vido output does fall over with a " Timed out waiting for free
> video buffers" after a bit though.
> There are other MythTv issues with av_remove_stream() could this
> be something to do with the problem ....
Well we're not calling av_remove_stream right now, we just create a
new decoder in avformatdecoder and leak a some memory. This was a
quick-n-dirty fix for some DVB channel changing problems, I plan to
fix this when I change the channel change behaviour. It probably
makes sense to hold off any VLD changes until the MythTV behaviour
is fixed. Gimme a week or so.

-- Daniel

terry1 at beam

Apr 25, 2005, 10:34 PM

Post #13 of 50 (7375 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 after
>>>a channel change.
>>>The XVMC_VLD_field_end() function is continuely called without
>>>any XVMC_VLD_field_start() calls. It appears that avcodec is
>>>trying to decode garbage ....
>
> Hmm, do you know who wrote the VLD part of avcodec?
Yes, it was me :)

>
>
>>If the DVB-T frond end is set to PS rather than TS mode then
>>the channel change happens and XvMC VLD carries along quite happily
>>without any "This context does not own decoder!" messages.
>>The Vido output does fall over with a " Timed out waiting for free
>>video buffers" after a bit though.
>>There are other MythTv issues with av_remove_stream() could this
>>be something to do with the problem ....
>
> Well we're not calling av_remove_stream right now, we just create a
> new decoder in avformatdecoder and leak a some memory. This was a
> quick-n-dirty fix for some DVB channel changing problems, I plan to
> fix this when I change the channel change behaviour. It probably
> makes sense to hold off any VLD changes until the MythTV behaviour
> is fixed. Gimme a week or so.
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 use. av_remove_stream() does not appear to be
called when PS streams are in use ...
Maybe the "DVB channel changing problems" you refer to is due
to some problem with av_remove_stream() and the VBuffer system ?
I don't intend to make any VLD changes but will investigate a
little more ...

Good luck

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

danielk at cat

Apr 26, 2005, 5:23 AM

Post #14 of 50 (7360 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 use. av_remove_stream() does not appear to be
> called when PS streams are in use ...

Ah, but this isn't being called by us because of the channel change, it
is being called from within avlib because the PMT has changed. This
can happen at any time, regardless of whether the channel has changed.
I think Doug had a test stream where the PMT changed every few seconds.
HDTVRecorder also has a "WHACK_A_BUG_VIDEO" define you can use to debug
this (assuming you can record/playback HDTV).

> Maybe the "DVB channel changing problems" you refer to is due
> to some problem with av_remove_stream() and the VBuffer system ?
> I don't intend to make any VLD changes but will investigate a
> little more ...

It is possible, but all it does currently is stop listening for data
on a stale TS stream, it doesn't even close the old av codecs, it just
opens new ones for the new data streams. I have a patch to actually
delete the codecs but that causes problems for nVidia XvMC I haven't
tracked down yet.

-- Daniel

doug at ties

Apr 26, 2005, 6:42 AM

Post #15 of 50 (7356 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCbkVPf1/38+/zqMERAkRfAJ0bD/mKmLVxPOICIEVVe/qH2oZIswCeLc/b
LRHSzb+byJbu2OoY7CNsjS4=
=Bd6T
-----END PGP SIGNATURE-----
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

torbjorn.jansson at mbox200

Apr 26, 2005, 9:04 AM

Post #16 of 50 (7342 views)
Permalink

RE: XVideo XvMC VLD broken [In reply to]

mythtv-dev-bounces [at] mythtv <> 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

Intresting.
I'm working on makeing mpeg2 ts work in the mythtv filters for windows and
i'm coding on a pat/pmt reader so i can setup the mpeg2 demuxer filter.

I think i'll have to download this and see how my code can handle it, it
probably can't since it's not finished yet and since i don't have any good
sample ts streams with changing pat/pmt in.

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

terry1 at beam

Apr 27, 2005, 1:31 AM

Post #17 of 50 (7337 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 changes is that the
AVCODEC for the old stream starts calling XVMC_VLD_field_end() multiple
times intertwined with the new stream starting to send valid MPEG streams
and hence calling XVMC_VLD_field_start(), XVMC_VLD_decode_slice() ...
XVMC_VLD_field_end(). This messes up the hardware decoding when
XVMC_VLD_field_end() appears out of order.

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 data structures containing pointers etc etc ...

Can anyone give me a run down on what actually is suposed to happen
when a channel is changed in MythTv when using DVB and TS streams ?

I would have expected someting like:

DVB -> MPEGTS -> VideoCodec -> Sync -> Video Out
-> AudioCodec -> Sync -> Audio Out

I would have though that all that would need changing would be
the DVB system selecting different PID's and possibly re-tuning, then
MPEGTS selecting the different streams. The Video out should not need
any changes (aprat from size changes which would be being handled already).
Is this the case ??
Ant pointers to the higher levels of code where the channel change is
implemented ??

Terry

danielk at cat

Apr 27, 2005, 7:11 AM

Post #18 of 50 (7338 views)
Permalink

Re: XVideo XvMC VLD broken [In reply to]

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 data structures containing pointers etc etc ...
> Can anyone give me a run down on what actually is suposed to happen
> when a channel is changed in MythTv when using DVB and TS streams ?

When a channel the recorder waits for any tables it needs then
it waits for keyframe. Once it gets a keyframe it begins writing
out the stream. But it rewrites the PAT table so that it contains
just one program, and it rewrites the PMT table so that it
describes the program listed in the PAT. So basically the
PAT never changes, but the PMT changes to listen to the right
streams for the current program.

Meanwhile the frontend doesn't know what is going on with the
recorder, but after the PMT changes in the stream the
HandleStreamChange() call-back is called from within ffmpeg.
This calls AVFormatDecoder's ScanStreams(). When it finds the
new video stream it calls InitVideoCodec(), which in set's up
the other callbacks within ffmpeg, and calls NVP's
SetVideoParams(), which tells the VideoOutput class about the
changes. Right now VideoOutput is informed of the change via
NVP's ReinitVideo() which calls vo->InputChanged(). InputChanged()
in turn deletes all the XvMC buffers and creates new ones.

What should happen instead, as long as XvMC is still the right output
type, is that VideoOutput should just note the change. It should then
delete the old buffers and create new ones as each frame is requested
by ffmpeg via the get_frame callback, displaying the already decoded
buffers from before the channel change until they have been replaced
with frames from the new stream.

> The Video out should not need
> any changes (aprat from size changes which would be being handled already).

The size changes are done in InputChanged now,
but should be done on a frame by frame basis.

> Ant pointers to the higher levels of code where the channel change is
> implemented ??

The video output method doesn't care at all about the channel change,
it is treated the same way as just a normal PMT change due to a new
program, commercials, etc.

-- Daniel

terry1 at beam

Apr 29, 2005, 10:06 AM

Post #19 of 50 (7310 views)
Permalink

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

Eureka !

I think I have tracked down the problem with the XvMC VLD breaking on
channel changes with TS streams.

I am no expert on libavformat or libavcodec, so some of the following
may not be correct ...

It appears that when the AVCodec is re-created on the TS stream changing
PID's it fails to re-create the MPEG parser to go along with it.
This results in the MPEG decoder getting a RAW stream rather than a
parsed stream. This breaks the AVCodec and then the VLD output.

I enclose a patch that fixes this for the XvMC VLD decoding and
prints an Error message whenever a parser cannot be created for
a Codec. I have also added an exit(1) in this case just so people are not
misled, however this may need to be removed ....

I suspect that the CODEC ID's for the standard XVMC and many other Codecs
will need to be added to the parser.c as well as I would have thought that
all of those not in the basic set (which is mainly software MPEG) would
fail similarly.

Actually, from my looking at libavcodec and libavformat it appears that
there is a bit of a miss use of the Codec ID. It appears, in some cases
to be used as a specific Codec ID and in other cases as a generic MPEG2
Codec identifier.
In fact there are some cases in the libavformat and libavcodec code
where the Codec ID is hard set to CODEC_ID_MPEG2VIDEO even if another Codec
is in use. (See: parser.c:389, mpegts.c:776, mpeg12.c:2174 etc).
I think this needs a look at by someone in the know ....

Anyway this patch works with MythTv CVS 2005-04-25.

I note that in the current CVS 2005-04-29 it does work, but the Video/Audio
AvSync has major issues with huge stutters. I presume this is due
to videoout_xv.c changes ....

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_1.patch (1.30 KB)

jstembridge at gmail

Apr 30, 2005, 2:10 AM

Post #20 of 50 (7307 views)
Permalink

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

Hi Terry,

On 4/29/05, Terry Barnaby <terry1 [at] beam> wrote:
> Eureka !
>
> I think I have tracked down the problem with the XvMC VLD breaking on
> channel changes with TS streams.
...
> Anyway this patch works with MythTv CVS 2005-04-25.

Great stuff! I've applied this patch to 0.18 and I can now change channel :)

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

terry1 at beam

May 1, 2005, 4:20 AM

Post #21 of 50 (7271 views)
Permalink

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

Terry Barnaby wrote:
> Eureka !
>
> I think I have tracked down the problem with the XvMC VLD breaking on
> channel changes with TS streams.
>

Enclosed is an updated patch that fixes the problem of both standard
XvMC and XvMC VLD breaking on channel changes with TS streams.

Note: This only handles XvMC and XvMC VLD Codecs. Other Codecs
that have problems with channel changes with TS streams will
now exit with an error message.

Terry

Attachments:

xvmc_vld_2.patch (3.03 KB)

ian at beware

May 2, 2005, 8:40 AM

Post #22 of 50 (7277 views)
Permalink

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

Terry Barnaby writes:
> Terry Barnaby wrote:
> > Eureka !
> >
> > I think I have tracked down the problem with the XvMC VLD breaking on
> > channel changes with TS streams.
> >
>
> Enclosed is an updated patch that fixes the problem of both standard
> XvMC and XvMC VLD breaking on channel changes with TS streams.

Great. I can now change channels (with XvMC not VLD), at least between
SD TV channels. Changing too or from HD TV is still a problem
though. I no longer get an abort (as I used to) but mythfrontend does
get stuck "waiting for video buffers."

HDTV is the best it has ever been for me. I can get quite smooth
playback with just the occasional stutter. It can also get a bad
stutter, which I can almost stop by stopping and restarting watching
until it is good. Not ideal, but the best it has been!

Ian

danielk at cat

May 2, 2005, 11:41 AM

Post #23 of 50 (7281 views)
Permalink

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

On Sun, 2005-05-01 at 12:20 +0100, Terry Barnaby wrote:
> Terry Barnaby wrote:
> > Eureka !
> >
> > I think I have tracked down the problem with the XvMC VLD breaking on
> > channel changes with TS streams.
> >
>
> Enclosed is an updated patch that fixes the problem of both standard
> XvMC and XvMC VLD breaking on channel changes with TS streams.
>
> Note: This only handles XvMC and XvMC VLD Codecs. Other Codecs
> that have problems with channel changes with TS streams will
> now exit with an error message.

I removed the exit, but kept the error message. One should never
exit from within a library, especially on data, there must be some
proper error handling mechanism you could use.

I also didn't commit the SIPParser changes, you need to convince
Tayler Jacob it is needed.

-- Daniel

terry1 at beam

May 2, 2005, 12:31 PM

Post #24 of 50 (7274 views)
Permalink

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

Daniel Kristjansson wrote:
> On Sun, 2005-05-01 at 12:20 +0100, Terry Barnaby wrote:
>
>>Terry Barnaby wrote:
>>
>>>Eureka !
>>>
>>>I think I have tracked down the problem with the XvMC VLD breaking on
>>>channel changes with TS streams.
>>>
>>
>>Enclosed is an updated patch that fixes the problem of both standard
>>XvMC and XvMC VLD breaking on channel changes with TS streams.
>>
>>Note: This only handles XvMC and XvMC VLD Codecs. Other Codecs
>>that have problems with channel changes with TS streams will
>>now exit with an error message.
>
>
> I removed the exit, but kept the error message. One should never
> exit from within a library, especially on data, there must be some
> proper error handling mechanism you could use.
>
> I also didn't commit the SIPParser changes, you need to convince
> Tayler Jacob it is needed.
>
> -- Daniel
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Hi Daniel,

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 !

Yes, the SIPParser changes were not needed, they slipped into this
patch from some one elses patch.

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 ?

Cheers

Terry

danielk at cat

May 2, 2005, 1:01 PM

Post #25 of 50 (7278 views)
Permalink

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

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

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads