Opened 12 years ago

Closed 12 years ago

#4159 closed defect (fixed)

On XvMCPutSlice error, frame is held by avlib and video/audio stutters

Reported by: mab893@… Owned by: danielk
Priority: minor Milestone: 0.21
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

I am running svn 14618 on a VIA CN400 (SP8000E), with a separate backend.

When watching an HD 1080i recording, after 2 minutes the video/audio begins to stutter and does not recover.

The stutter first occurs with the following log error repeated many times:

2007-11-08 22:10:48.473 VideoOutputXv? Error: XvMCPutSlice: 11

Subsequently the following error appears:

2007-11-08 22:10:48.839 VideoOutputXv?: Frame e is in use by avlib and so is being held for later discarding.

And stuttering gets worse as an additional frame is held:

2007-11-08 22:10:59.519 VideoOutputXv?: Frame e is in use by avlib and so is being held for later discarding. 2007-11-08 22:10:59.520 VideoOutputXv?: Frame H is in use by avlib and so is being held for later discarding.

Is it possible to release the frames so that they are not held after the error to the XvMCPutSlice2 call?

Additional (brief) log is attached; more detail is available if needed.

Attachments (2)

mythtv XvMCPutSlice error, frames held.log (2.9 KB) - added by mab893@… 12 years ago.
Brief log of: VideoOutputXv? Error: XvMCPutSlice: 11
libmythtv-videobuffers.cpp.patch (405 bytes) - added by mab893@… 12 years ago.
Correct avlib frame extra locking (caused by missing picture_start_code)

Download all attachments as: .zip

Change History (7)

Changed 12 years ago by mab893@…

Brief log of: VideoOutputXv? Error: XvMCPutSlice: 11

comment:1 Changed 12 years ago by mab893@…

Has anyone been able to duplicate this?

comment:2 Changed 12 years ago by mab893@…

Here is an example of a video with the problem (~22mb): http://home.comcast.net/~martin-glass/test.ts

It occurs a few seconds into the clip, and appears to be because the PICTURE_START_CODE start_code isn't encountered before the slices (SLICE_MIN_START_CODE-SLICE_MAX_START_CODE) are processed. This causes the decoder not to be initialized for this context, and for some reason the buffer is never unlocked after the slices are completed (although the frame does make it to release_avf_buffer_xvmc) ...

Changed 12 years ago by mab893@…

Correct avlib frame extra locking (caused by missing picture_start_code)

comment:3 Changed 12 years ago by davilla@…

I've also seen this but did not understand what has happening until now. I'm viewing ATSC OTA HD content using XvMC. Sometimes the signal glitches and frames get damaged. I'll lose frames as they become held until I run out and stall. Applying this patch resolved my stall/freeze problem.

comment:4 Changed 12 years ago by danielk

Milestone: unknown0.21
Owner: changed from Isaac Richards to danielk

comment:5 Changed 12 years ago by danielk

Resolution: fixed
Status: newclosed

(In [15124]) Fixes #4159. Removes delimboed frames from decoder ownership if ffmpeg fails to do it.

This shouldn't be needed but ffmpeg get's confused if it gets the slices for a frame without seeing the start code for that frame. There is no harm in doing this check in MythTV and it helps with XvMC, especially with DTV transmissions which can be mangled by the broadcaster at encode time or during transmission.

Note: See TracTickets for help on using tickets.