Opened 16 years ago
Closed 16 years ago
Last modified 16 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)
Change History (19)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
Component: | mythvideo → mythtv |
---|---|
Owner: | changed from Anduin Withers to Isaac Richards |
Status: | new → assigned |
Changed 16 years ago by
Attachment: | screenshot-1.jpg added |
---|
Part of a screenshot showing the problem
comment:3 Changed 16 years ago by
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:5 Changed 16 years ago by
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 16 years ago by
Owner: | changed from Isaac Richards 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 16 years ago by
Can you attach the "mythtv -v playback Test.avi" log? I can't reproduce this here..
comment:10 Changed 16 years ago by
Type: | defect → patch |
---|
comment:11 Changed 16 years ago by
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 16 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → 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 16 years ago by
Resolution: | fixed |
---|---|
Status: | closed → 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 16 years ago by
Attachment: | 4567-v3.patch added |
---|
Patch that also makes sure that the NVP and videoouput classes use the right video frame size (buffer vs. displayed).
comment:14 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | new → 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 16 years ago by
(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.
Here is an example file: http://iw.net/~brfransen/myth/Test.avi