Internal Player shows a pixelated line at bottom of videos

[anonymous]

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.

[anonymous]

Here is an example file: ​http://iw.net/~brfransen/myth/Test.avi

[paulh]

Part of a screenshot showing the problem

[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.

[martin.norden@…]

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

[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.

[Isaac Richards]

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..

[danielk]

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

[danielk]

never mind, I can reproduce this here...

[danielk]

potential fix, needs more testing..

[danielk]

Little tweaks to previous patch

[Isaac Richards]

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

[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.

[danielk]

(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.

[danielk]

(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.

[danielk]

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

[danielk]

(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.

[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.