Bug reports for version 2.0.1 (1 Viewer)

[SpudR]

That's just what I did - updated through the MPEI
Just got back myself - testing...


#EDIT#
That fixes it

 

[hirscho]

Hi Marvman

Again thanks for the new version of IFC. I am using IFC since the beginning but I am still on IFC 1.x, as I am not able to configure IFC 2.0.1 according to my requirements and maybe you can give me a hint.

What I can see is, that IFC 2.0.1 is cropping even small bars on all sides of a video taking into account the stabilzation factor. These small black lines of just a few pixel do not disturb me. And isn't it destroying the original AR of the video if you crop the sides taken into account the stabilization factor and strech the video?

I would like to have IFC just to react on (real) black bars resulting from a transmission in a wrong format like 16:9 video in a 4:3 picture.

Is there a way to configure IFC that it crops only if a black bar is bigger then x % of the video?
Would it be possible to forbid cropping at all and just decide on the zoom factor based on the detection of a (real) black bar?

Could you also explain, what the impact of the "stabilzation tolerance" is?

Best Regards

Oliver

 

[Paranoid Delusion]

Hi Marvman

A bit of a issue with 2.1, which does not exist with 2.0 is that MP crashes.

Steps to produce.

1. watch live tv
2. use remote "recorded tv" button to go to recordings.
3. select a recording to play, nothing happens, but tv carries on playing in window.
4. MP is now totally unresponsive

ps. also the MPEI does not uninstall all components when used screenshots below.



This was a new MP1RC5 install with StreamedMP and its collection of goodies , but just so you are certain there is no problem doing the above steps without IFC installed or with version 2.0, only 2.1 shows this behaviour.

View attachment 64239

Regards

 

[Paranoid Delusion]

Put above on hold, just tried chemelli's Core.dll fix for thumbs not being produced and now cannot repeat above, will confirm no issues tomorrow after a bit more testing.

After 48 hours no problems seen, so it looks like there was a conflict which the new core.dll fixed

 

[Marvman]

Hi Marvman

Again thanks for the new version of IFC. I am using IFC since the beginning but I am still on IFC 1.x, as I am not able to configure IFC 2.0.1 according to my requirements and maybe you can give me a hint.

What I can see is, that IFC 2.0.1 is cropping even small bars on all sides of a video taking into account the stabilzation factor. These small black lines of just a few pixel do not disturb me. And isn't it destroying the original AR of the video if you crop the sides taken into account the stabilization factor and strech the video?

I would like to have IFC just to react on (real) black bars resulting from a transmission in a wrong format like 16:9 video in a 4:3 picture.

Is there a way to configure IFC that it crops only if a black bar is bigger then x % of the video?
Would it be possible to forbid cropping at all and just decide on the zoom factor based on the detection of a (real) black bar?

Could you also explain, what the impact of the "stabilzation tolerance" is?

Best Regards

Oliver

Hi Oliver,

version 2.0.1 has some serious issues (sorry guys for that). Try the attached beta version.
To your questions:

The stabilizer only kicks in when small black bars/edges were detected. And to prevent a cropping behavior like this 1-4-3-0-3 ... and so. the set stabilizer of 10 (default) crops when more than 0 pixel are found.

example:
1-10 = 10
11-20 = 20
...

The stabilizer tolerance works like this:

to prevent the following:

without stabilizer tolerance:

9 pixel (detected) = 10 (stabilized)
11 pixel (detected) = 20 (stabilized)
8 pixel (detected) = 10 (stabilized)

with stabilizer tolerance (default is 7)

9 pixel (detected) = 10 (stabilized)
11 pixel (detected) = 20 (stabilized)
8 pixel (detected) = 20 (stabilized)
6 pixel (detected) = 20 (stabilized)
5 pixel (detected) = 20 (stabilized)
4 pixel (detected) = 20 (stabilized)
3 pixel (detected) = 10 (stabilized)
4 pixel (detected) = 10 (stabilized)
5 pixel (detected) = 10 (stabilized)
9 pixel (detected) = 10 (stabilized)

as you can see the stabilizer consider the last set stabilizer and if the difference to the stabilizer is more than 7, then the stabilizer is changed (only backwards).

Hope you understand the logic behind.


And isn't it destroying the original AR of the video if you crop the sides taken into account the stabilization factor and strech the video?

Not really only some pixel.

Is there a way to configure IFC that it crops only if a black bar is bigger then x % of the video?

No sorry

Would it be possible to forbid cropping at all and just decide on the zoom factor based on the detection of a (real) black bar?

No, but it sound interesting, I'll take it into considering.

For me it sounds that the "old lady" do exactly what do you want, cause it crops exactly (but in some situations you will see leftovers)

 

[flokel]

Hi Marvman,

is this issue reproducible on your side ?

https://forum.team-mediaportal.com/general-support-51/click-stop-button-rc6-84243/

 

[Marvman]

Hi Marvman,

is this issue reproducible on your side ?

https://forum.team-mediaportal.com/general-support-51/click-stop-button-rc6-84243/

Hi Flokel,

no it isn't, requested some log from this guy.

 

[cYbton]

Hey,

for me IFC doesn't work very well. For e.g. it always crops just one black bar or stretches the picture on a channel a few times.

So I disabled the IFC autostart and set the default videomode in MP to stretch.
Then I set the F4 shortcut to the yellow button on my MCE remote.
When playing a movie in 21:9 I just have to press the yellow button to switch to normal view.
In TV-Mode since today I've never had a reason to crop anything.
Sometimes it's useful when playing bad recorded videos with black borders left and right. That's works good.

The only problem I got is that the picture stretches while switching channels (for 1-2 seconds, then it's perfect, still having disabled the autostart)
When IFC is deactivated this issue is gone. I'm using the Intel HD Graphic with Core-i3 processor.

Do you have a explanation for this? Or maybe a few tips to config IFC much better?

 

[mironto]

Hello Marvman,

first thanks for this great plugin. I have a following problem with it though.

I have 16:9 TV and the default zoom in MP is set to normal. I have some series in 4:3 format, so I want to automatically zoom the videos when watching it.

In I.F.C. 2.0.1 I set all the overscan to 0 and cropping off (I don't need to remove black bars, as I have almost no videos with bars) and set general->advanced video mode the zoom levels for each content. I have 4:3 set to non-linear stretch and 4:3 letterbox to zoom, all other modes are set to normal. Since all my HD videos are 16:9, I turned off I.F.C. for HD.

The problem is once I watch some 4:3 content (which is correctly set to non-linear stretch), the default mode in MP changes to non-linear stretch. Thus once I start watching HD, all videos get non-linear stretched and I have to manually set it back to normal. If I do not watch any 4:3 content, the default mode in MP stays normal. As a temporary fix I have to enable I.F.C. for HD as well, then it correctly changes the zoom to normal (however, I would rather turn it off for HD, as it's really not needed for my HD videos and uses my CPU's cycles delaying the video playback).

Can you have a look at this and try to reproduce the scenario? It would be better if I.F.C. just changed the zoom for actual video and left the default zoom mode in MP to user preferred setting.

 

[Marvman]

Hey,

for me IFC doesn't work very well. For e.g. it always crops just one black bar or stretches the picture on a channel a few times.

So I disabled the IFC autostart and set the default videomode in MP to stretch.
Then I set the F4 shortcut to the yellow button on my MCE remote.
When playing a movie in 21:9 I just have to press the yellow button to switch to normal view.
In TV-Mode since today I've never had a reason to crop anything.
Sometimes it's useful when playing bad recorded videos with black borders left and right. That's works good.

The only problem I got is that the picture stretches while switching channels (for 1-2 seconds, then it's perfect, still having disabled the autostart)
When IFC is deactivated this issue is gone. I'm using the Intel HD Graphic with Core-i3 processor.

Do you have a explanation for this? Or maybe a few tips to config IFC much better?

The switching issue is fixed in the latest beta.
The cropping behavior is overworked a lil bit (I introduced because of a rework of the stabilizer) in beta too

Hello Marvman,

first thanks for this great plugin. I have a following problem with it though.

I have 16:9 TV and the default zoom in MP is set to normal. I have some series in 4:3 format, so I want to automatically zoom the videos when watching it.

In I.F.C. 2.0.1 I set all the overscan to 0 and cropping off (I don't need to remove black bars, as I have almost no videos with bars) and set general->advanced video mode the zoom levels for each content. I have 4:3 set to non-linear stretch and 4:3 letterbox to zoom, all other modes are set to normal. Since all my HD videos are 16:9, I turned off I.F.C. for HD.

The problem is once I watch some 4:3 content (which is correctly set to non-linear stretch), the default mode in MP changes to non-linear stretch. Thus once I start watching HD, all videos get non-linear stretched and I have to manually set it back to normal. If I do not watch any 4:3 content, the default mode in MP stays normal. As a temporary fix I have to enable I.F.C. for HD as well, then it correctly changes the zoom to normal (however, I would rather turn it off for HD, as it's really not needed for my HD videos and uses my CPU's cycles delaying the video playback).

Can you have a look at this and try to reproduce the scenario? It would be better if I.F.C. just changed the zoom for actual video and left the default zoom mode in MP to user preferred setting.

Thanks for your detailed report and I think I know where the problem is, I'll fix that in the next version.