(2016-10-18, 18:23)popcornmix Wrote: The VC-1 and MPEG-2 files are detected as deinterlaced correctly.
They look fine to me. The file is a deinterlace torture test, so it is intended to be hard to deinterlace.
We produce the same output as, say VLC using yadif x2 (which is considered a very good deinterlacer).

Yadif is something software? The quality corresponds to a average level. Something like hardware "adaptive" on amd. There is "motion-adaptive", which is much better and "vector-adaptive", which is very much better.
VLC never used, only tried. IMO this is the one of most bad players ever
Thank you for the answer.

BTW, I ran the file past our new codec expert and he replied:

Quote:OK - well I've pulled the stream apart. In general it looks progressive
(MBAFF can be progressive): TopFieldOrderCount == BottomFieldOrderCount
and the clockTimestamps for the two fields (from the Picture Timing SEI)
are the same. However pic_struct = 3 (Top field, Bottom Field) which
muddies the waters a bit.

You can make a strong case that this should be progressive. H.264 says
[D.2.2 clock_timestamp_flag[i]]:

When clockTimestamp is equal for two fields of opposite parity that are
consecutive in output order, both with ct_type equal to 0 (progressive)
or ct_type equal to 2 (unknown), the two fields are indicated to have
come from the same original progressive frame. Two consecutive fields in
output order shall have different values of clockTimestamp when
the value of ct_type for either field is 1 (interlaced).

In this stream ct_type = 2, the clockTimestamps are the same and the
above para is as definite as H.264 gets regarding display. As ct_type &
clockTimestamps are optional fields one might hope that they meant
something useful if included!

So, that's the reason we don't deinterlace it. We do what the spec says.

ffmpeg seems to diverge from the spec in this case and decides it is interlaced.
I've tried following ffmpeg's logic and running a number of test files through and
noting when there is a change in behaviour. I'll need to look more closely at the changes
and see if they seem to be desirable or undesirable.

Ok, I enabled debug log using Advanced Settings and restarted my Pi3 and went through the entire sequence of starting the movie and hitting "fast forward", etc. Here is the log - http://pastebin.com/H6jM1Dyc

Nothing in the log has been edited or snipped. Let me know if this works. Once again, thanks much for looking into this.

I just observed another strange thing - if I disable "Decode the stereo stream from 3D files", the movie plays in 2D, but I am able to "fast forward" without any issues. I find this really weird...

I have been trying various combinations but nothing seems to work when the movie is played in 3D mode, which leads me to believe that it's the 3D MVC rendering that might be causing the issue. I see a few errors in my debug log and have Googled around, but haven't been to find anything concrete. Please help.

(2016-10-17, 22:13)Knochen1981 Wrote: I have the same problem while playing Files from a local drive. The picture freezes for aboout 5 Seconds - audio is playing. Build used 1015 but it happened with 1014 and 1013 too. 1004 was fine.

I went back to 1004 and had this freezing too. Still no idea when it started. It is hard to figure out since I can go 60 minutes without it happening and then it happens 3 times every 5 minutes or so. I don't have the time to watch that many movies (Again, no issues with OMX)

(2016-10-19, 13:35)DaveBlake Wrote: Experienced some sutter on video playback (mp4) - picture freezes for 2s while sound continues. Various episodes from a series exhibit this behaviour.

Happens with build 1018(y) on RPi3, also with LE7.90.007 but not noticed on LE 7.90.005.

Sorry no debug logs yet, it is the family system so debug gets turned off to see the picture rather than have the status stuff in to left corner. I know that is not enough to work with, but seems worth mentioning in case it was a known issue.

Edit: discovered <logfile>1</logfile>, will try to gather some more useful info tonight

Perhaps this is better described as video getting out of sync. It doesn't seem to matter what file is playing as how long it is playing for. When I wind-back and replay the piece of video it plays perfectly. Also I notice that the hic-up happens at about the same time from start of playback, i.e. 18mins approx, on each video.

Maybe this is just down to system settings? I am just using the defaults. Family use not making this easy to catch or adjust, but hoping to be helpful. Log also full of CEC log too as trying to debug that as well (I don't think there is any interaction between issues).

(2016-10-21, 19:36)DaveBlake Wrote: Perhaps this is better described as video getting out of sync. It doesn't seem to matter what file is playing as how long it is playing for. When I wind-back and replay the piece of video it plays perfectly. Also I notice that the hic-up happens at about the same time from start of playback, i.e. 18mins approx, on each video.

Maybe this is just down to system settings? I am just using the defaults. Family use not making this easy to catch or adjust, but hoping to be helpful. Log also full of CEC log too as trying to debug that as well (I don't think there is any interaction between issues).

I've seen one other report that could be the same issue, but I'm not seeing any stuttering or sync issues.

Looks like you've got "PLL adjust" enabled in system/audio settings which is not a default option. Can you try disabling that?

(2016-10-21, 19:36)DaveBlake Wrote: Perhaps this is better described as video getting out of sync. It doesn't seem to matter what file is playing as how long it is playing for. When I wind-back and replay the piece of video it plays perfectly. Also I notice that the hic-up happens at about the same time from start of playback, i.e. 18mins approx, on each video.

Maybe this is just down to system settings? I am just using the defaults. Family use not making this easy to catch or adjust, but hoping to be helpful. Log also full of CEC log too as trying to debug that as well (I don't think there is any interaction between issues).

I've seen one other report that could be the same issue, but I'm not seeing any stuttering or sync issues.

Looks like you've got "PLL adjust" enabled in system/audio settings which is not a default option. Can you try disabling that?

I'm having the same issue with Passthrough and "PLL adjust" disabled. Will post a log if I find the time.

There is also an option build into libreelec settings, although I have not tried this option in a while. 2360115(post) (Also explained in 1st post in thread, point 7 - LibreELEC Settings add-on Development Updates)

Quick question: is there any way to disable the messages to 'keep or remove add-ons' after cleaning the library. I get the message EVERY time it cleans the library (which happens after adding, changing or removing content).

(2016-10-21, 19:36)DaveBlake Wrote: Perhaps this is better described as video getting out of sync. It doesn't seem to matter what file is playing as how long it is playing for. When I wind-back and replay the piece of video it plays perfectly. Also I notice that the hic-up happens at about the same time from start of playback, i.e. 18mins approx, on each video.

Maybe this is just down to system settings? I am just using the defaults. Family use not making this easy to catch or adjust, but hoping to be helpful. Log also full of CEC log too as trying to debug that as well (I don't think there is any interaction between issues).

I've seen one other report that could be the same issue, but I'm not seeing any stuttering or sync issues.

Looks like you've got "PLL adjust" enabled in system/audio settings which is not a default option. Can you try disabling that?

OK, will try that tonight.

Some more detail. In the log I posted here 2441242(post) "adjust display refresh to match" was disabled. Last night I enabled it as you recommended elsewhere, still got out of sync moments but a little later in the video (21 mins of play). However, unlike previously where there were a flurry of CDVDPlayerAudio::SyncStream messages, the log shows very little at the time sutter occurs. Just after the issue I hit pause on the remote, as I have CEC debug enabled this makes it easy to find these points in the log. My log is huge as I didn't reboot, so here a small extract so you can se what I mean,

Quick Links

About Kodi

Kodi is a free and open source media player application developed by the XBMC Foundation, a non-profit technology consortium.

Kodi is available for multiple operating-systems and hardware platforms, featuring a 10-foot user interface for use with televisions and remote controls. It allows users to play and view most videos, music, podcasts, and other digital media files from local and network storage media and the internet.