(REVIVED) Stuttering/jerky 1080i on pre-Eden and post-Eden
#31
sebj Wrote:Is there something really different to the macosx version? I don't seem to have the "last lines artifact" in macosx using auto-->bob deinterlacing

You see this corruption of the top and bottom lines because of a missing feature. The problem has always been there but after we have fixed a bug for NVidia GPUs it shows more obvious.
De-interlacing never works well for the top and bottom lines because you have to extrapolate in order to reconstruct the missing information. In case of h.264 1080i you have even more lines at the bottom, the coded height is in general 1088. When using vdpau, de-interlacing is before cropping which means that those extra lines, which are garbage, take part in de-interlacing and may ruin the last line a bit more.

TV sets use overscanning in order to cope with this. I think a better solution would be just not to render those lines.
Reply
#32
Just a data point, upgraded LIVE to Beta-1, 12/28 build thru the unstable PPA today... the 1080i problem still exists.
Reply
#33
Quote:The problem has always been there but after we have fixed a bug for NVidia GPUs it shows more obvious.

Thanks for the insight, good to know what's going on under the hood.

Is there any way this fix can coexist with making h.264 1080i material play nice again? Nod
Reply
#34
sebj Wrote:Is there any way this fix can coexist with making h.264 1080i material play nice again? Nod
I certainly hope so, this makes about 1/4 of my library unplayable and the thought of having to re-encode to another format makes me a wee queasy Oo
Reply
#35
You are discussing two topics is this thread.

1)
Corruption of top/bottom line
As already said, this problem has always been around. I have already a prototype of a fix for this in a local branch.

2)
Stuttering
I rolled back my repo and could not proof ialand's statement that this would be a new problem. I don't see any changes in the code after Feb 2011 which could have led this this problem. This was the date ffmpeg was upgraded. The sample file I got plays ok without vdpau which does de-interlacing before rendering. It does also play fine with some experimental code which does bypass vdpau de-interlacer and allows normal bob de-interlacing.
But I still do think that the source of this problem is related to ffmpeg.
Reply
#36
FernetMenta Wrote:You are discussing two topics is this thread.

Stuttering
I rolled back my repo and could not proof ialand's statement that this would be a new problem. I don't see any changes in the code after Feb 2011 which could have led this this problem. This was the date ffmpeg was upgraded. The sample file I got plays ok without vdpau which does de-interlacing before rendering. It does also play fine with some experimental code which does bypass vdpau de-interlacer and allows normal bob de-interlacing.
But I still do think that the source of this problem is related to ffmpeg.

@FernetMenta

Well updating ffmpeg in the XBMC would TECHNICALLY be a new problem, just not a new problem with XBMC but it's support programs. Is there a way to install the older version of ffmpeg to check that?
Reply
#37
Fernementa

10-4 about the two specific issues, thx for making it clear after looking into it Big Grin

Quote:Corruption of top/bottom line
As already said, this problem has always been around. I have already a prototype of a fix for this in a local branch.

As you seem to be on top of this issue, can this be rolled into eden or is this too dangerous of a fix, as beta1 is already out.

I mean, I understand feature freeze and all, but wouldn't you say this is a regression fix?

here's to hoping my totaly xbmc eden experience will not be viewed at 1.01 scale!

thx for checking!
Reply
#38
sebj Wrote:I mean, I understand feature freeze and all, but wouldn't you say this is a regression fix?
I would certainly hope so, even if this if a ffmpeg problem (which I have no doubt FernetMenta knows what they are talking about) this seems to be something that is a real no-no in product development... you don't break existing content. about 1/4 of my library is broken by my issue, things that played perfectly fine before and the thought of re-encoding just makes me ill No Boxee did this same thing they changed something that introduced a stutter in some MKV files and just would not fix it (that's when I dumped Boxee)

((that was not a dig to drop XBMC, this looks fixable and looks to have some willingness to do so))

CORRECTING MYSELF: It was NOT Boxee that mucked up some MKV files and didn't want to be bothered to fix it, it was POPCORN HOUR and the C-200 NMT. Boxee just never would make a stable release while I had one
Reply
#39
FYI: i have created a ticket for further investigation:
http://trac.xbmc.org/ticket/12414

(This is only for the stuttering)
Reply
#40
FernetMenta Wrote:FYI: i have created a ticket for further investigation:
http://trac.xbmc.org/ticket/12414

(This is only for the stuttering)

THX, I'll keep an eye on it Smile
Reply
#41
I have submitted fixes for both problems to mainline for review.
Reply
#42
You rock man.

Thanks for helping so much!

Will you keep us posted in this thread?
Reply
#43
FernetMenta Wrote:I have submitted fixes for both problems to mainline for review.
Outstanding... if there is a way I/we can help test it, please don't hesitate to ask (got lots of different files to try it with)
Reply
#44
Short update on this:

We have agreed on the fix for the bottom line artifact and its merged. But we are not happy with the other one because it does not fix the root cause. The problem has already been in Dharma but showed less.
We have not found the root cause yet.
Reply
#45
Quote:We have agreed on the fix for the bottom line artifact and its merged.

Awesome! can't wait to try it out! Going to compile a recent build.

About the other issue though Blush
Reply

Logout Mark Read Team Forum Stats Members Help
(REVIVED) Stuttering/jerky 1080i on pre-Eden and post-Eden0