Video Haltiness Multiple Times/Second

[Stephen Warren]

Oh, I just realized that you're using MythTV not MPlayer like I am. I believe MythTV includes its own copy of ffmpeg, and I don't know how often that gets updated to match ffmpeg SVN. It's quite possible (well, probable) that MythTV's copy of ffmpeg doesn't include various recent fixes for VDPAU integration and/or H.264 handling itself. This could be part of your problem, if you're seeing more hangs/crashes than I just detailed in my previous post...

[Stephen Warren]

Sorry, I screwed up my testing; the G86 code had a bunch of heavy-weight debug spew turned on.

So, I have in fact reproduced no VDPAU problems at all with this clip.

Are you using the overlay-based or blit-based presentation queue? Does the problem go away if you switch (export VDPAU_NVIDIA_NO_OVERLAY=1 to force blit, or typically turn off X composite extension to get back to overlay).

Sorry for the confusion.

[Lost Dog]

The video file plays fine in xine and mplayer but has some video glitches first about 25 seconds in and several times after that. In xine and mplayer they play through the error spots but mythtv crashes HARD freezing up the video to the point I had to kill the process.

[Quantumstate]

I am seeing the exact same thing in Myth as the Dog.

As I said above, I compile SVN.mythtv-fixes.20445 with the glvdpau.20405 patch. As I am about to ditch Ubuntu for Debian, I'm not about to go to the trouble of compiling mplayer or xine, and I never actually use them anyway. And as Ubuntu's package system is busted I can't install them, much less with VDPAU support. Myth is my entertainment system.

I don't know what else to do. This clip and numerous others of the same source, are unwatchable with VDPAU in Myth. And driver 185 is driving me crazy because over a couple hours it climbs to 100% CPU usage for X. I can't do with this, as I have to work.

[Lost Dog]

Originally Posted by Quantumstate

I am seeing the exact same thing in Myth as the Dog.

As I said above, I compile SVN.mythtv-fixes.20445 with the glvdpau.20405 patch. As I am about to ditch Ubuntu for Debian, I'm not about to go to the trouble of compiling mplayer or xine, and I never actually use them anyway. And as Ubuntu's package system is busted I can't install them, much less with VDPAU support. Myth is my entertainment system.

I don't know what else to do. This clip and numerous others of the same source, are unwatchable with VDPAU in Myth. And driver 185 is driving me crazy because over a couple hours it climbs to 100% CPU usage for X. I can't do with this, as I have to work.

I use Debian myself and have complied mythtv using the same patch and rev as you. I use xine for DVD's and downloaded video because I've never gotten good performance using the internal mythtv player for anything but atsc recordings.

I agree that it must be the ffmpeg used internally by myth...

[jyavenard]

Originally Posted by Quantumstate

2009-04-22 06:39:19.674 VideoOutputXv: Desired video renderer 'vdpau' not available.
codec 'MPEG2' makes 'opengl,xv-blit,xshm,xlib,' available, using 'opengl' instead.

Two possible issues here:

1-You aren't running mythtv with VDPAU support. VDPAU could still show in your profile because you did run a mythtv with VDPAU support in the past so it created the profile.
But right now, you do not have vdpau support in your mythtv

2-You got an error earlier regarding VDPAU, but it doesn't show up in the log.
starts mythtv with -v playback and report back

[jyavenard]

Originally Posted by Quantumstate

As I am about to ditch Ubuntu for Debian, I'm not about to go to the trouble of compiling mplayer or xine, and I never actually use them anyway. And as Ubuntu's package system is busted I can't install them, much less with VDPAU support. Myth is my entertainment system.

Not sure what you mean with ubuntu package system being busted.

But you could save yourself a lot of hassle by using my ubuntu repository.
Latest mythtv and mplayer with VDPAU support

http://www.avenard.org/media/Ubuntu_...epository.html

ffmpeg in 0.21 is rather old ; and hasn't been updated since 0.21 got released 1.5 years ago.

If you want a newer version of ffmpeg in mythtv; you'll have to go to trunk . But even there, it's a rather old ffmpeg with no native vdpau support.

[Quantumstate]

Originally Posted by jyavenard

1-You aren't running mythtv with VDPAU support. VDPAU could still show in your profile because you did run a mythtv with VDPAU support in the past so it created the profile.
But right now, you do not have vdpau support in your mythtv

This problem was resolved with a subsequent compile. When I patched and compiled with the latest noted versions, it now engages VDPAU.

But the problem now is with any damaged H.264 HD transport stream. (like the one I uploaded above) VDPAU is very intolerant in Myth, and in fact locks up hard for both the Dog and I. Yet when Stephen plays it in Xine and Mplayer it's pretty good. This tells me that the problem is somewhere with the Myth patch. I suspect that the underlying problem is with VDPAU, but it is exacerbated in the Myth patch.

Originally Posted by jyavenard

Not sure what you mean with ubuntu package system being busted.

Hardy on my laptop will no longer install many packages. (says they're 'broken') So tomorrow I'm going back to Debian Testing.

'Busted' is an old southern US colloquial term, meaning broken. In most parts of the US the newer meaning is 'arrested by the police', but that's not the intended use here.

Originally Posted by jyavenard

But you could save yourself a lot of hassle by using my ubuntu repository.

I'd love to but first, I'll be running Debian tomorrow, and second I must also install Alan Nisota's R5000-HD patch so I can record Dish satellite TV. This is the source of my TV. (and often the damaged streams) I have no choice but to compile Myth-fixes source.

Originally Posted by jyavenard

ffmpeg in 0.21 is rather old ; and hasn't been updated since 0.21 got released 1.5 years ago.

I'd understood that Myth uses only libavcodec from ffmpeg? Isn't the libavcodec in -fixes, newer?

[Lost Dog]

Originally Posted by Quantumstate

Hardy on my laptop will no longer install many packages. (says they're 'broken') So tomorrow I'm going back to Debian Testing.

Looks like Debian forums are back on line!

I've been running mythtv on Lenny for quite a while now (It's been stable so I don't see a need to move it to Squeeze) and I've been happy with it.

[Quantumstate]

Back online?! That's a surprise. I've been warning them about security issues for months. In fact the day that spam was sent I posted a message decrying security again, right before the takedown. Checking to see if it's been deleted... yep, they deleted it.

Oh well, time to leave for LinuxFest Northwest.

[Stephen Warren]

Just FYI, I spoke to the MythTV developers re: embedded ffmpeg version:

In the development MythTV version, the embedded ffmpeg version is from ~ last November, and hence probably doesn't include some of the fixes for VDPAU integration. There's a plan to update it in the near future. However, the developer doing this was waiting for the new hwaccel API to be fully merged and stable. Unfortunately, the ffmpeg developers are dragging out the review process for this.

For the 0.21 branch, the embedded ffmpeg is maybe a couple years old. Couple this with using patches for VDPAU integration that are probably also from the same time period (i.e. ~ Nov last year) and problems are to be expected.

[Quantumstate]

Thanks Stephen. But see my overall concerns are that:

- The stream discontinuities are not being addressed. Are you saying that your mplayer is using the latest ffmpeg? And that any Myth in existence will not be able to cope well with stream discontinuities?

- I thought that ffmpeg isn't even in the mix with Myth and Mplayer. I thought that only a subcomponent of ffmpeg (libavcodec) was what is integrated. And that libavcodec compiled into mythtv-fixes and Mplayer is much newer than the stock ffmpeg one.

- The Dish transport stream (with its slight differences) is not even being considered by anyone. (referenced sample) This is a concern for three reasons:
a. It is more likely to have stream discontinuities than a DVD program stream; and
b. I would like to clean the TS to a PS with a tool like avidemux, but avidemux can't understand the indexing in a satellite TS. The developer is indifferent, as is apparently jyavenard (VDPAU patch) since he doesn't seem to grasp the problem; and
c. Sure not everyone gets the pure TS from sat providers yet, but those of us who do are trying to give an early warning. This has such technical merit that it has to take off and so apps should be able to accommodate.