Opened 14 years ago

Closed 13 years ago

#8201 closed defect (Fixed)

H264 broadcast causes missing DTS and PTS timestamps

Reported by: Per <heldal@…> Owned by: Janne Grunau
Priority: minor Milestone: 0.24
Component: MythTV - Video Playback Version: head
Severity: medium Keywords: h264 timestamps
Cc: Ticket locked: no

Description

One of my HD-channels suffer from stutter in mythtv. The only playback profile defined is supposed to use the VDPAU decoder, yet mythtv decides the format isn't supported by VDPAU and falls back to software decoding anyway (and the hardware E6600 can't keep up). I first suspected it was a problem with VDPAU, but got clips from this channel playing with hardware decoding once I got a recent mplayer installed.

The discussion with nvidia support can be found in http://www.nvnews.net/vbulletin/showthread.php?t=149058

It appears that mythtv asks for VDP_DECODER_PROFILE_MPEG4_PART2_ASP (which the hardware - GTX260 - doesn't support) while the correct format for this channel should be VDP_DECODER_PROFILE_H264_MAIN or VDP_DECODER_PROFILE_H264_HIGH.

Other channels distributed in a similar 1080i format are handled just fine through vdpau.

Change History (11)

comment:1 Changed 14 years ago by Per Heldal <heldal@…>

A sample clip from the affected channel can be found at http://www.megaupload.com/?d=5BB0SE3N

comment:2 Changed 14 years ago by Per Heldal <heldal@…>

I did not intially notice that the CPU-load doesn't increase while watching recordings from the troublesome channel. That indicates that the decoding is still handled in hardware and not falling back to use libavformat as previously assumed. The issue may not be VDPAU-related at all, but rather something else to do with A/V sync. I don't have a machine that is powerful enough to test software decoding of HD-streams to confirm this. Using VDPAU the frontend is reporting that it is dropping frames because video lags behind audio.

Also worth mentioning is that the problem with this channel has existed in mythtv/trunk for a few months. It was ok some time ago, but I'm unable to trace it back to a particular changeset in myth code or relate it to a change in the operators encoding of the channel.

comment:3 Changed 14 years ago by anonymous

Per - I'd happily take a look at this but I simply can't download from that link. can you post the clip somewhere else? thanks

comment:4 Changed 14 years ago by Per Heldal <heldal@…>

Had forgotten to share the clip after upload, sorry.

Should now be available at http://www.megaupload.com/?d=EFE7RJG7

comment:5 Changed 14 years ago by markk

Sorry - I should have been clearer. I cannot access certain sites such as this one. can you use something like filebin.ca. thanks, Mark

comment:6 Changed 14 years ago by robertm

Owner: changed from Janne Grunau to markk
Status: newassigned

Mark, I downloaded this sample and uploaded it myself to:

http://www.fecitfacta.com/rushtv-sample.mpg

Trunk selects a VDPAU profile, though it does play completely horribly and eventually fails out waiting for buffers.

comment:7 Changed 14 years ago by anonymous

This is not a VDPAU problem.

The clip has no DTS or PTS (timestamps) for the video stream and normal software playback fails as well. The correct VDPAU profile is selected but A/V sync is just too broken.

comment:8 Changed 14 years ago by tralph

Keywords: timestamps added; vdpau removed
Milestone: unknown0.24
Owner: changed from markk to janneg
Summary: Mythtv requesting wrong decoder profile from VDPAUH264 broadcast causes missing DTS and PTS timestamps

This is resolved by [25665]. However I'm assigning to Janne since he noticed some issue with the DTS and PTS timestamps getting cleared somewhere. This might be an a deeper issue that needs some attention.

Per, Does this channel still have issues for you?

comment:9 Changed 14 years ago by Per Heldal <heldal@…>

Just upgraded from trunk rev 25623 to 25668. Recording and watching this channel now works fine.

comment:10 Changed 14 years ago by beirdo

Owner: changed from janneg to Janne Grunau

comment:11 Changed 13 years ago by robertm

Resolution: Fixed
Status: assignedclosed

resolving as fixed since the original issue is fixed. If there's a deeper task to be addressed later, we can open a new ticket for clarity.

Note: See TracTickets for help on using tickets.