[mythtv-users] 0.27.6 Release Notes clipped

Peter Bennett (cats22) cats22 at comcast.net
Tue May 3 14:09:54 UTC 2016


On 05/02/2016 09:30 PM, Jerome Yuzyk wrote:
> In https://www.mythtv.org/wiki/Release_Notes_-_0.27.6 it says:
>
> faginbagin (5):
>      Mythcommflag assumed that the number of bytes per scan line for the luma
>      Many years before the lowres option was added to improve performance, a
>      The CommDetectBorder? setting did dual duty, as it was also used to limit
>      Logo detection required a minimum number of pixels in a mask found by
>      Mythcommflag assumed that video can be either normal, letter-boxed...
>
>
> Each line has been clipped. How can I read the full text?
>
commit 125f6fe5796495634efb13dd14468da2fa9b8df1
Author: faginbagin <mythtv at hbuus.com>
Date:   Sun Oct 26 14:01:04 2014 -0600

    Mythcommflag assumed that video can be either normal, letter-boxed or
    pillar-boxed, but not both letter-boxed and pillar-boxed. I have
found there
    are often instances where it can be both letter-boxed and pillar-boxed,
    especially in commercials found in SD recordings and on the SD
version of
    our PBS channel. The patch, mcf-letter-pillar.patch changes the enum
    frameFormat into a bit mask allowing the detection of video that's both
    letter and pillar-boxed. This patch did not make any overall change to
    accuracy, at least not with the set of recordings I chose to measure
    results. But it didn't make things worse, and I do have other recordings
    where it helps. I just wasn't prepared to go back and repeat all the
tests
    with a different set of recordings.
   
    Signed-off-by: John Poet <jpoet at mythtv.org>

commit 90e378a8ed65c291053523956d198c3088f6f0df
Author: faginbagin <mythtv at hbuus.com>
Date:   Sun Oct 26 14:01:04 2014 -0600

    Logo detection required a minimum number of pixels in a mask found by
    examining several video frames to be greater than 50 to be considered a
    valid logo mask. No consideration of the variety of video
resolutions was
    taken into consideration. And the 50 pixel minimum was not adjusted when
    lowres decoding was implemented. The patch, mcf-logo-pixInMask.patch,
    assumes the 50 pixel value was established for 1280x720 video and
uses that
    area to compute a minimum pixel value using this formula: 50 *
    (width*height) / (1280*720 / 16). It improves accuracy to 75%.
   
    Signed-off-by: John Poet <jpoet at mythtv.org>

commit 117af1f1f7a9195cb1a933f08c3c98082190945f
Author: faginbagin <mythtv at hbuus.com>
Date:   Sun Oct 26 14:01:04 2014 -0600

    The CommDetectBorder? setting did dual duty, as it was also used to
limit
    the area examined by logo detection. The mcf-border.patch for
problem 2) did
    not help a number of SD recordings, because it allowed logo detection to
    examine letter-boxed areas of SD video and caused logo detection to
fail on
    recordings where it used to work. To detect logos, we need to exclude
    letter-boxed areas from SD video, but if we exclude too much from HD
video,
    we'll miss the logo. Using the same border of 16 for both SD & HD
with no
    scaling seems to be a good compromise. The patch, mcf-logo-border.patch,
    adds a new setting, CommDetectLogoBorder? with a default value of 16 and
    uses it as the border for logo detection. It improves accuracy to 72%.
   
    Signed-off-by: John Poet <jpoet at mythtv.org>

commit 7da9166e9d7cd62b68cd799e68411c8811e81446
Author: faginbagin <mythtv at hbuus.com>
Date:   Sun Oct 26 14:01:04 2014 -0600

    Many years before the lowres option was added to improve performance, a
    default value for the CommDetectBorder? setting was set to 20. It is
used to
    exclude CommDetectBorder? pixels from the top, bottom, left and
right of the
    frame from examination. It should, for example, exclude any VBI data
that
    might be visible at the top of a frame or parts of the video that
would be
    hidden due to overscan. The default value was never adjusted to
account for
    lowres decoding, nor did it take into consideration the variety of video
    widths and heights that exist today. The patch, mcf-border.patch,
assumes
    the CommDetectBorder? setting was established for 720 height video
and uses
    those two numbers and the lowres video height to compute the border
    used. For example: If video source height = 480 then border = 20 *
480 / 4 /
    720 = 2 If video source height = 720 then border = 20 * 720 / 4 /
720 = 5 If
    video source height = 1080 then border = 20 * 1080 / 4 / 720 = 7
    mcf-border.patch improves accuracy to 67%.
   
    Signed-off-by: John Poet <jpoet at mythtv.org>

commit c2d0e1cdd1411daa31b485466d0e51413256d176
Author: faginbagin <mythtv at hbuus.com>
Date:   Sun Oct 26 14:01:04 2014 -0600

    Mythcommflag assumed that the number of bytes per scan line for the luma
    array equals the video width. That may have been true before
mythcommflag
    was changed to use ffmpeg's lowres decoding option, but it is not
true when
    the CommDetectBorder? setting was established for 720 height video
and uses
    those two numbers and the lowres video height to compute the border
    used. For example: If video source height = 480 then border = 20 *
480 / 4 /
    720 = 2 If video source height = 720 then border = 20 * 720 / 4 /
720 = 5 If
    video source height = 1080 then border = 20 * 1080 / 4 / 720 = 7
    mcf-border.patch improves accuracy to 67%.
   
    Signed-off-by: John Poet <jpoet at mythtv.org>

commit c2d0e1cdd1411daa31b485466d0e51413256d176
Author: faginbagin <mythtv at hbuus.com>
Date:   Sun Oct 26 14:01:04 2014 -0600

    Mythcommflag assumed that the number of bytes per scan line for the luma
    array equals the video width. That may have been true before
mythcommflag
    was changed to use ffmpeg's lowres decoding option, but it is not
true when
    the lowres option is used. The bytes per scan line are actually the
width
    rounded up to a multiple of 16. Some of the SD resolutions, when
divided by
    4 (as is the case for the lowres option), are not multiples of 16. The
    patch, mcf-bytesPerLine.patch, fixes this problem, and improved accuracy
    from 51% to 54%.
   
    Signed-off-by: John Poet <jpoet at mythtv.org>

 ESCOD
    the CommDetectBorder? setting was established for 720 height video
and uses
    those two numbers and the lowres video height to compute the border
    used. For example: If video source height = 480 then border = 20 *
480 / 4 /
    720 = 2 If video source height = 720 then border = 20 * 720 / 4 /
720 = 5 If
    video source height = 1080 then border = 20 * 1080 / 4 / 720 = 7
    mcf-border.patch improves accuracy to 67%.
   
    Signed-off-by: John Poet <jpoet at mythtv.org>

commit c2d0e1cdd1411daa31b485466d0e51413256d176
Author: faginbagin <mythtv at hbuus.com>
Date:   Sun Oct 26 14:01:04 2014 -0600

    Mythcommflag assumed that the number of bytes per scan line for the luma
    array equals the video width. That may have been true before
mythcommflag
    was changed to use ffmpeg's lowres decoding option, but it is not
true when
    the lowres option is used. The bytes per scan line are actually the
width
    rounded up to a multiple of 16. Some of the SD resolutions, when
divided by
    4 (as is the case for the lowres option), are not multiples of 16. The
    patch, mcf-bytesPerLine.patch, fixes this problem, and improved accuracy
    from 51% to 54%.
   
    Signed-off-by: John Poet <jpoet at mythtv.org>

:
    the CommDetectBorder? setting was established for 720 height video
and uses
    those two numbers and the lowres video height to compute the border
    used. For example: If video source height = 480 then border = 20 *
480 / 4 /
    720 = 2 If video source height = 720 then border = 20 * 720 / 4 /
720 = 5 If
    video source height = 1080 then border = 20 * 1080 / 4 / 720 = 7
    mcf-border.patch improves accuracy to 67%.
   
    Signed-off-by: John Poet <jpoet at mythtv.org>

commit c2d0e1cdd1411daa31b485466d0e51413256d176
Author: faginbagin <mythtv at hbuus.com>
Date:   Sun Oct 26 14:01:04 2014 -0600

    Mythcommflag assumed that the number of bytes per scan line for the luma
    array equals the video width. That may have been true before
mythcommflag
    was changed to use ffmpeg's lowres decoding option, but it is not
true when
    the lowres option is used. The bytes per scan line are actually the
width
    rounded up to a multiple of 16. Some of the SD resolutions, when
divided by
    4 (as is the case for the lowres option), are not multiples of 16. The
    patch, mcf-bytesPerLine.patch, fixes this problem, and improved accuracy
    from 51% to 54%.
   
    Signed-off-by: John Poet <jpoet at mythtv.org>




More information about the mythtv-users mailing list