Thread Closed
v17 LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)
(2016-10-20, 15:58)MONSTA Wrote:
(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 Smile
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.
  Thread Closed
 
Thread Rating:
  • 19 Vote(s) - 4.63 Average


Messages In This Thread
RPi2: no DV-codec? - by bubi - 2016-07-10, 10:30
DV-video not working - by bubi - 2016-07-15, 19:48
RE: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0) - by popcornmix - 2016-10-20, 18:18


Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)4.6319