2012-01-10, 19:26
Glad to hear some progress. I've been watching that ticket# but haven't seen any notes to it.
2012-01-10, 20:20
Pardon my ignorance here:p
Has this been merged yet?
Has this been merged yet?
2012-01-10, 20:31
This one has been merged:
https://github.com/xbmc/xbmc/commit/1adf...eef1d45cb1
Discussion about stuttering is here: please don't comment there, it's a dev space:
606 (PR)
https://github.com/xbmc/xbmc/commit/1adf...eef1d45cb1
Discussion about stuttering is here: please don't comment there, it's a dev space:
606 (PR)
2012-01-15, 06:46
Fernet.
Just applied your commit for the corruption to my openelec build.
this gets rid of it! Thanks a bunch for all the work!
Now, off to fix the damn livetv from my hdpvr/mythtv0.24!
Just applied your commit for the corruption to my openelec build.
this gets rid of it! Thanks a bunch for all the work!
Now, off to fix the damn livetv from my hdpvr/mythtv0.24!
2012-01-15, 20:05
any sign of the stuttering fix making it to a point where I could try it out?
2012-01-22, 19:19
We have not figured out yet what messes up the timestamps. I guess the problem is related to ffmpeg. As I said earlier the problem has been there in Dharma as well but did not show that much.
This patch does not really fix the problem it only alleviates the symptoms a bit.
https://github.com/FernetMenta/xbmc/comm...f2488de037
You can compile from source and apply this patch until we have found the root cause.
This patch does not really fix the problem it only alleviates the symptoms a bit.
https://github.com/FernetMenta/xbmc/comm...f2488de037
You can compile from source and apply this patch until we have found the root cause.
2012-01-22, 22:33
FernetMenta Wrote:We have not figured out yet what messes up the timestamps. I guess the problem is related to ffmpeg. As I said earlier the problem has been there in Dharma as well but did not show that much.
This patch does not really fix the problem it only alleviates the symptoms a bit.
https://github.com/FernetMenta/xbmc/comm...f2488de037
You can compile from source and apply this patch until we have found the root cause.
@FernetMenta
ty for the update.. self compiling is not in my skill set
so I'll just wait.. gladt to know it's still being hunted down
2012-01-23, 17:18
Quote:We have not figured out yet what messes up the timestamps. I guess the problem is related to ffmpeg.
Just though of something...
On atsc, I've seen some channels change framerates on the fly.
Ie: a prgram can be 23.976 and the the ads come up and they're 59.94 for example.
Related? How does xbmc cope with that?
Fernet,
Applied this patch to my custom openelec distro
https://github.com/FernetMenta/xbmc/comm...f2488de037
Playback of hdhomerun atsc mpeg2 1080i is really really solid.
On my setup with modelines it LOCKS @59.94 and doesn't seem to move. Stared at that number and eventually got bored it stayed locked so long
A different thing can be said about the h.264 I record off the hdpvr.
The fps flutter kinda weirdly actually, I'm used to seeing flutter, but it's a predictable sequence, with this patch, now applied to beta2, the fps kinda oscillate. Can you test the patch against the sample I included or am I crazy?
Playback ain't that bad though, the wife wouldn't see the diff, but I'm an OCD pro visual effects nerd, so I'm cursed
Will your patches hit stock eden like the "pink line" patch?
Thx!
Applied this patch to my custom openelec distro
https://github.com/FernetMenta/xbmc/comm...f2488de037
Playback of hdhomerun atsc mpeg2 1080i is really really solid.
On my setup with modelines it LOCKS @59.94 and doesn't seem to move. Stared at that number and eventually got bored it stayed locked so long
A different thing can be said about the h.264 I record off the hdpvr.
The fps flutter kinda weirdly actually, I'm used to seeing flutter, but it's a predictable sequence, with this patch, now applied to beta2, the fps kinda oscillate. Can you test the patch against the sample I included or am I crazy?
Playback ain't that bad though, the wife wouldn't see the diff, but I'm an OCD pro visual effects nerd, so I'm cursed
Will your patches hit stock eden like the "pink line" patch?
Thx!
2012-01-25, 23:39
The sample from ialand I inspected shows a weird pattern in the input stream. Every approx. 12th field is missing. Then fmpeg tries to fill the gaps with other fields since it can't leave one half of a frame blank. This I think is the reason for the messed up timestamps after decoding. XBMC's pattern detector needs a length of 32 timestamps to detect a repeatable pattern. With vdpau de-interlacer engaged it bails out becuase it can't detect a pattern.
The patch does not fix this, it just excludes the timestamps of every second field from the pattern detector. The source of the problem is the input stream. Why has it those gaps? It might be a problem of your HDPVR. I don't think that the stream is broadcasted this way. Do you have a chance to record the same channel with your HDPVR and a different device?
XBMC would detect a changing framerate as well as other stream parameters and act accordingly. Once the patern detector has given up due to messed up timestamps it won't detect any change of refresh rate.
The patch does not fix this, it just excludes the timestamps of every second field from the pattern detector. The source of the problem is the input stream. Why has it those gaps? It might be a problem of your HDPVR. I don't think that the stream is broadcasted this way. Do you have a chance to record the same channel with your HDPVR and a different device?
Quote:On atsc, I've seen some channels change framerates on the fly.
Ie: a prgram can be 23.976 and the the ads come up and they're 59.94 for example.
Related? How does xbmc cope with that?
XBMC would detect a changing framerate as well as other stream parameters and act accordingly. Once the patern detector has given up due to messed up timestamps it won't detect any change of refresh rate.
2012-01-26, 00:35
FernetMenta Wrote:The patch does not fix this, it just excludes the timestamps of every second field from the pattern detector. The source of the problem is the input stream. Why has it those gaps? It might be a problem of your HDPVR. I don't think that the stream is broadcasted this way. Do you have a chance to record the same channel with your HDPVR and a different device.
No, I only have one HDPVR and thats' all I can record with, the problem is only when I'm recording 1080i, 720p works just fine. And I'm recording from a HD-DVR so I have tried re-recording several times the same program, always goes wacky on 1080i. At least 2 dozen things still on the HD-DVR that I'm waiting to see how this pans out... but things I've recorded over the past 3 years that (yeah, this is starting to sound like a broken record) played fine on previous versions are crapping out also. I've tried several different versions of the HDPVR drivers, all with the same result.. I WISH I could say this is a recent development, but it's not
EDIT: ok I just have to ask this.. what changed between Dharma and Eden? You said the problem was there in Dharma before but not as pronounced (I never saw it, but that's just me). So what changed?
2012-02-08, 08:46
I am having the same problem with the Windows version and got linked to this thread here. I'm 99% sure I am having the same studdering issue as the original poster, and it is due to the 29/59 bug that effects Windows Media Center as well. It happens with interlaced content that has been incorrectly flagged as progressive, which causes the deinterlacer to keep switching on and off as the framerate changes from 59 to 29 rapidly. I posted a sample in my other thread.
http://forum.xbmc.org/showthread.php?tid=113789&page=2
In this clip with deinterlacing set to off or auto there is extreme hitching in the video as the guy is walking around the office. This is exactly the way it looks in Windows Media Center as well. Now, change deinterlacing to On in xbmc and the file plays smoothly. This is a video that has the 29/59 framerate switching problem embedded in it. When deinterlacing is set to auto it goes crazy trying to keep up with the constant framerate change. This is only fixed by changing deinterlacing to On every time you want to play an interlaced video with the 29/59 bug.
http://www.mediafire.com/?w5nqkrn7trwsbcx
http://support.microsoft.com/kb/2658140
http://forum.xbmc.org/showthread.php?tid=113789&page=2
In this clip with deinterlacing set to off or auto there is extreme hitching in the video as the guy is walking around the office. This is exactly the way it looks in Windows Media Center as well. Now, change deinterlacing to On in xbmc and the file plays smoothly. This is a video that has the 29/59 framerate switching problem embedded in it. When deinterlacing is set to auto it goes crazy trying to keep up with the constant framerate change. This is only fixed by changing deinterlacing to On every time you want to play an interlaced video with the 29/59 bug.
http://www.mediafire.com/?w5nqkrn7trwsbcx
Quote:This occurs due to Windows Media Center resetting the video pipeline when a frame rate change occurs. Each time a frame rate change occurs, it may take a few frames for the video to recover. However, when frequent frame rate changes occur, video appear to constantly stutter or "glitch" without smoothing out.
This problem occurs when broadcasts frequently switch between interlaced and progressive content. Progressive content is shown at 59.94 frames per second (fps) while interlaced content is shown at 29.97 fps. This problem has also been seen when a broadcaster incorrectly flags their content. For instance, interlaced content is incorrectly flagged as progressive content.
http://support.microsoft.com/kb/2658140
2012-02-08, 22:45
I just upgraded after over a year, from 9.10 to 10.10 Ubuntu and moving from my old Dharma release and onto the eden beta 3. I noticed that half my files don't work properly (stuttering) although they worked fine before I upgraded. Luckily I can roll back (clonezilla image) but thought i'd mention this fact, in case it helps with the problem.
