Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#4567 closed patch (fixed)

Internal Player shows a pixelated line at bottom of videos

Reported by: anonymous Owned by: danielk
Priority: minor Milestone: 0.21
Component: mythtv Version: head
Severity: low Keywords:
Cc: Ticket locked: no

Description

The Internal player shows a pixelated line at the bottom of the videos I have encoded as h.264 anamorphic. This artifact does not appear in ffplay, mplayer, xine or VLC.

Attachments (4)

screenshot-1.jpg (48.9 KB) - added by paulh 6 years ago.
Part of a screenshot showing the problem
4567-v1.patch (6.2 KB) - added by danielk 6 years ago.
potential fix, needs more testing..
4567-v2.patch (8.8 KB) - added by danielk 6 years ago.
Little tweaks to previous patch
4567-v3.patch (34.0 KB) - added by danielk 6 years ago.
Patch that also makes sure that the NVP and videoouput classes use the right video frame size (buffer vs. displayed).

Download all attachments as: .zip

Change History (19)

comment:1 Changed 6 years ago by anonymous

comment:2 Changed 6 years ago by awithers

  • Component changed from mythvideo to mythtv
  • Owner changed from awithers to ijr
  • Status changed from new to assigned

Changed 6 years ago by paulh

Part of a screenshot showing the problem

comment:3 Changed 6 years ago by paulh

I can reproduce this with the sample file. I've attached part of a screen shot showing the problem. It looks almost like the last line of video is repeated for several lines beyond the bottom of the frame. I've no idea where to start looking at this but hope someone who does will find this info useful.

comment:4 Changed 6 years ago by martin.norden@…

I can confirm this as well. I'm using 0.20.

comment:5 Changed 6 years ago by mharbudd@…

This problem also exhibits itself with avi files, and thus is not limited to h.264. I am using trunk from around December 30, 2007.

comment:6 Changed 6 years ago by ijr

  • Owner changed from ijr to danielk

Daniel - this issue is that the stream height is 360, but our aligned height is 368. I'm not seeing an easy way to reconcile the difference in the current videooutput classes..

comment:7 Changed 6 years ago by danielk

Can you attach the "mythtv -v playback Test.avi" log? I can't reproduce this here..

comment:8 Changed 6 years ago by danielk

never mind, I can reproduce this here...

Changed 6 years ago by danielk

potential fix, needs more testing..

Changed 6 years ago by danielk

Little tweaks to previous patch

comment:9 Changed 6 years ago by ijr

Patch doesn't look correct - won't that discard the alignment?

comment:10 Changed 6 years ago by danielk

  • Type changed from defect to patch

comment:11 Changed 6 years ago by danielk

It will fail for these ffmpeg output formats: YUV411P, UYYVYY411, YUV410P
But we don't support these... all other formats have a minimum buffer size alignment of 16 pixels in avformatdecoder, which is what we enforce in videoutbase.cpp when setting video_dim.

comment:12 Changed 6 years ago by danielk

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [16424]) Fixes #4567. Moves video buffer alignment code out of avformatdecoder to videooutbase (closer to where the buffers are actually allocated.)

When the avformatdecoder did the alignment, the videoout methods were forced to show the whole buffer which resulted in dandruff being displayed when the video dimensions were not evenly divisible by the alignment requirement now we only display the portion of the video buffer that ffmpeg tells us has valid video data.

comment:13 Changed 6 years ago by danielk

  • Resolution fixed deleted
  • Status changed from closed to new

(In [16425]) Refs #4767. Reverts [16424], VideoOutputNull?? isn't using the aligned values. Need to review it and some other VideoOutput?? classes before recommitting the fix.

Changed 6 years ago by danielk

Patch that also makes sure that the NVP and videoouput classes use the right video frame size (buffer vs. displayed).

comment:14 Changed 6 years ago by danielk

  • Resolution set to fixed
  • Status changed from new to closed

(In [16434]) Fixes #4567. Fixes rendering of chaff in XVideo renderer when the video buffer size != video frame size.

This is the same as the earlier reverted commit, except that I made sure that the NVP and classes using it don't use the real video frame size unless they know how to handle it. All others use the video buffer size, which is what was being used before this changeset. They are usually the same thing, but when they are not the same you can get rendering artifacts, and if the video frame size is used for buffer allocations you can overwrite memory or if lucky get a segfault.

The earlier reverted commit caused a a portion of the preview videos of videos with a frame size not divisible by 16 in both dimensions to have a green hue over a portion of the image.

comment:15 Changed 6 years ago by danielk

(In [16483]) Fixes #4897. Refs #4567. This fixes a DVD menu handling problem introduced by [16434].

When stream parameters were updated but a new video size was not passed to NVP::SetVideoParams?() an invalid video size was sent to the video output classes.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.