Intelligent Frame Correction - PlugIn (2 Viewers)

[Owlsroost]

HD is detected only when the video has a hight above 600 lines, but i would prefer to detect the x264 or similar codec instead, cause this use more cpu time. But i wait until some one complain about it

There is quite a lot of MPEG-2 HD around - US ATSC HDTV can be MPEG-2, as is HDV camcorder material - so I think frame height is probably the best way since it should work with all codecs.

Back to your previous problem, the latest version show me, that the CPU spikes came from the mp frame grabber and not from the plug in, right?

Yes, correct. I wonder why the frame grabbing causes such big spikes (with Vista+EVR+DXVA+nVidia at least) ?

Tony

 

[Marvman]

There is quite a lot of MPEG-2 HD around - US ATSC HDTV can be MPEG-2, as is HDV camcorder material - so I think frame height is probably the best way since it should work with all codecs.

OK, we will observe this

Yes, correct. I wonder why the frame grabbing causes such big spikes (with Vista+EVR+DXVA+nVidia at least) ?

Tony

Maybe you can play a lil bit with VMR9 and EVR and codecs, maybe you notice a difference.

 

[bazzz]

HD is detected only when the video has a hight above 600 lines, but i would prefer to detect the x264 or similar codec instead, cause this use more cpu time. But i wait until some one complain about it

720p movies with a cinematic aspect ratio (2.39:1 ?) will have less than 600 lines - maybe you should measure the width of the image instead? I think HD is usually above 1200 pixels across.

 

[Owlsroost]

If it really is a '720p' file then it should be just that - 720 lines vertically (with black bars top & bottom as part of the video frame).

But yes, downloaded files can be all sorts of wierd and wonderful aspect ratios - that's why ViewModeSwitcher has a configurable 'decision table' where you can setup multiple frame size/aspect ratio combinations and how to handle each combo......but it makes it hard to set up, and I think Marvman is trying to keep IFC simple to use.

Tony

 

[hirscho]

Hi Marvman,

Thanks a lot for adding the "4:3 Letterbox" mode. It works quite well here!.

I did some further testing and must admit that I do not fully understand the logic of IFC black bar detection. Pleas find two extracts of the log:

1)
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: perform I.F.C.: g_vmr: 1,777778 (used) ; TV AspectRatio: 1,777778 ; Picture AspectRatio: 1,25 ; g_Player.GetVideoFormat(): 16:9
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: scanning for black areas...
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in pixel: 2,9,84,9
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in %: 14,51,483,64
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Median: 91
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Max: 251

2)
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: perform I.F.C.: g_vmr: 1,333333 (used) ; TV AspectRatio: 1,777778 ; Picture AspectRatio: 1,25 ; g_Player.GetVideoFormat(): 4:3
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: scanning for black areas...
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in pixel: 41,46,10,10
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in %: 295,264,57,72
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Median: 58
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Max: 120
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: scanning for black areas...
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in pixel: 31,2,9,30
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in %: 223,11,51,216
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Median: 26
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Max: 156


In both cases the video is a standard PAL transmission with a resolution of 720:576 which results in an "Picture AspectRatio" of 1,25. That is lower than the screen AR of 16:9 and black bar detection is initiated. I does not harm, but in case 1) it is just not necessary as there is never a black bar to crop in an 720:576 PAL movie with an "Video Format" of 16:9. At least not on a 16:9 flat screen. So maybe it could be a good idea to take the "VideoFormat" into account instead of the calculated PictureAR at least if the VideoFormat is available. To what I know some codecs will deliver a "0:0" here.


May I also suggest that you improve the logging. It would be nice to know which bar exactly is analyzed (upper bar, middle bar) and I assume you switched the "pixel" and "%" scan area.

Oliver


Edit:

Oh, I am sorry. Everything seems to be fine here. In the first case the black bar detection refers to the HD detection. Numbers are a little bit confusing here as I am used to read it as (xPos, yPos, xWidth, yWidth). By the way: I cannot turn off HD bar detection completely by unflagging it in the config screen. It is still used in an SD video (see above).

 

[Marvman]

HD is detected only when the video has a hight above 600 lines, but i would prefer to detect the x264 or similar codec instead, cause this use more cpu time. But i wait until some one complain about it

720p movies with a cinematic aspect ratio (2.39:1 ?) will have less than 600 lines - maybe you should measure the width of the image instead? I think HD is usually above 1200 pixels across.

If it really is a '720p' file then it should be just that - 720 lines vertically (with black bars top & bottom as part of the video frame).

But yes, downloaded files can be all sorts of wierd and wonderful aspect ratios - that's why ViewModeSwitcher has a configurable 'decision table' where you can setup multiple frame size/aspect ratio combinations and how to handle each combo......but it makes it hard to set up, and I think Marvman is trying to keep IFC simple to use.

Tony

We will see if someone has a problem with the 600 lines, I can make it configurable than.
And btw. cinema-scope is 2.35:1.

Hi Marvman,

Thanks a lot for adding the "4:3 Letterbox" mode. It works quite well here!.

I did some further testing and must admit that I do not fully understand the logic of IFC black bar detection. Pleas find two extracts of the log:

1)
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: perform I.F.C.: g_vmr: 1,777778 (used) ; TV AspectRatio: 1,777778 ; Picture AspectRatio: 1,25 ; g_Player.GetVideoFormat(): 16:9
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: scanning for black areas...
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in pixel: 2,9,84,9
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in %: 14,51,483,64
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Median: 91
2009-10-19 19:32:56.171875 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Max: 251

2)
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: perform I.F.C.: g_vmr: 1,333333 (used) ; TV AspectRatio: 1,777778 ; Picture AspectRatio: 1,25 ; g_Player.GetVideoFormat(): 4:3
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: scanning for black areas...
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in pixel: 41,46,10,10
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in %: 295,264,57,72
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Median: 58
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Max: 120
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: scanning for black areas...
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in pixel: 31,2,9,30
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: ScanArea in %: 223,11,51,216
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Median: 26
2009-10-19 19:36:20.078125 [Debug][I.F.C.: processingThread]: I.F.C.: Gray Max: 156


In both cases the video is a standard PAL transmission with a resolution of 720:576 which results in an "Picture AspectRatio" of 1,25. That is lower than the screen AR of 16:9 and black bar detection is initiated. I does not harm, but in case 1) it is just not necessary as there is never a black bar to crop in an 720:576 PAL movie with an "Video Format" of 16:9. At least not on a 16:9 flat screen. So maybe it could be a good idea to take the "VideoFormat" into account instead of the calculated PictureAR at least if the VideoFormat is available. To what I know some codecs will deliver a "0:0" here.


May I also suggest that you improve the logging. It would be nice to know which bar exactly is analyzed (upper bar, middle bar) and I assume you switched the "pixel" and "%" scan area.

Oliver


Edit:

Oh, I am sorry. Everything seems to be fine here. In the first case the black bar detection refers to the HD detection. Numbers are a little bit confusing here as I am used to read it as (xPos, yPos, xWidth, yWidth). By the way: I cannot turn off HD bar detection completely by unflagging it in the config screen. It is still used in an SD video (see above).

Hi Oliver,

to be clear here are the tow cases PAL (non HD) transmissions?

In the first case you got a 16:9 transmission, top an bottom black bar detection is not necessary, but it scans only for left and right black bars (was suggested by the community), and that's happens (2,9,84,9).

In the second case you got a 4:3 transmission, left and right black bar detection is not necessary, it scans only for top and bottom. The order of scans are "Check Area" ->"Black Area One".

You can disable the black bar scanner globally by the unchecked flag "Black Bar Detection", you can disable the black bar scanner only for HD content by the unchecked flag "Black Bar Detection 4 HD".

If you have Videos/Stream in HD, and IFC scans though, let me please know.

I hope I could helped you.

Regards,
Martin

 

[hirscho]

Hi Oliver,

to be clear here are the tow cases PAL (non HD) transmissions?

In the first case you got a 16:9 transmission, top an bottom black bar detection is not necessary, but it scans only for left and right black bars (was suggested by the community), and that's happens (2,9,84,9).

In the second case you got a 4:3 transmission, left and right black bar detection is not necessary, it scans only for top and bottom. The order of scans are "Check Area" ->"Black Area One".

You can disable the black bar scanner globally by the unchecked flag "Black Bar Detection", you can disable the black bar scanner only for HD content by the unchecked flag "Black Bar Detection 4 HD".

If you have Videos/Stream in HD, and IFC scans though, let me please know.

I hope I could helped you.

Regards,
Martin

Hi Martin

Thanks a lot for the fast reply. Things getting clearer now. I thought by "Black Bar Detection 4 HD" only the left bar is meant for HD transmission where an 4:3 picture is embedded in an 16:9 video. Isn't HD material always transmitted in 16:9 (1280x720, 1920x1080p, 1920x1080i)? So why checking for blach bars on the top/bottom there? The most common matroska movies I know have an width of 1080 or 1920 pixel and dependent on the format a variable high, but you do not need to detect bars there on the top/bottom.

On the other side I cannot image any (SD-)video format, where you got left/right bars except for this special HD case. Of course in the internet you could find any format, even a bad transcoded DivX movie with a wrong AR, that you have to force manually in a 14:9 zoom. So, I would go for the 99% case with the lowest performance impact. ;-)


Oliver

Edit:
I like the idea of bazzz to go for the width (~1200) to differentiate between SD/HD as it is less variable.

 

[Marvman]

Hi Martin

Thanks a lot for the fast reply. Things getting clearer now. I thought by "Black Bar Detection 4 HD" only the left bar is meant for HD transmission where an 4:3 picture is embedded in an 16:9 video. Isn't HD material always sent in 16:9 (1280x720, 1920x1080p, 1920x1080i)? So why checking to crop bars on the top/buttom there? On the other side I cannot image any (SD-)video format, where you got left/right bars except for this special HD case. Of course in the internet you could find any format, even a bad transcoded DivX movie with a wrong AR, that you have to force manually in an 14:9 zoom. So, I would go for the 99% case with the lowest performance impact. ;-)



Oliver

For a 16:9 transmission IFC doesn't crop the top/bottom bars and it doesn't scans for. ONLY left/right scanning is active.
But you are absolutely right, 4:3 content embedded in 16:9 transmission should only appears in HD content.
I could/want to change that, want to hear more opinions. Whether someone had SD material (except crappy encoded stuff(cam rips etc.)) where black bars appears left and right.

 

[Owlsroost]

For a 16:9 transmission IFC doesn't crop the top/bottom bars and it doesn't scans for. ONLY left/right scanning is active.
But you are absolutely right, 4:3 content embedded in 16:9 transmission should only appears in HD content.
I could/want to change that, want to hear more opinions. Whether someone had SD material (except crappy encoded stuff(cam rips etc.)) where black bars appears left and right.

Some of the UK SD DVB-T content is 4:3 embedded in a 16:9 transmission, so you get left/right black bars....

Tony

 

[Marvman]

For a 16:9 transmission IFC doesn't crop the top/bottom bars and it doesn't scans for. ONLY left/right scanning is active.
But you are absolutely right, 4:3 content embedded in 16:9 transmission should only appears in HD content.
I could/want to change that, want to hear more opinions. Whether someone had SD material (except crappy encoded stuff(cam rips etc.)) where black bars appears left and right.

Some of the UK SD DVB-T content is 4:3 embedded in a 16:9 transmission, so you get left/right black bars....

Tony

That was fast, thanks Tony