Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Smack]

Hello all.

With great surprise I just saw that the new JRiver version include black bar detection.

Will my rtx3070 be fast enough for the feature?

How does it work? Will I got Coneheads because the picture will be stretched??

[lello]

Same info for me too.

So, if I understand correctly, at the moment the presence of the black bands is detected (excluding BDs) but no cropping is done, right?

Will it be implemented in future builds?

Numbers are right. Currently AFAIK they are not utilized yet

[Smack]

Thanks for your reply. But I don’t understand.

Is my rtx 3070 strong enough for the feature? Will the image be cropped or will I have coneheads instead?

Next question would be will movies with changing aspect ratio like maverick also work??

[mattkhan]

It is just an offline analysis of the file to store a single value (the detected image size), it is not live analysis of the video stream (so changing aspect ratio is irrelevant, typically reacting to this by changing the scaling is unwelcome anyway) and is not currently used at playback time at all. I believe the intent is to help jrvr have the option to automatically zoom to eliminate black bars based on that value recorded in a tag (which is ultimately just a scaling of the image).

[Hendrik]

It was already said above, but just to confirm, we try to detect black bars during video import, not during playback. This means only one value will be stored, which is the "biggest" active image rectangle found at the spots we are checking (which is random spots within the first 30 minutes of the video, I believe).

This is mostly only relevant if you have a ultrawide screen setup, either with eg. a 21:9 display, or a projector with an anamorphic lens to achieve it.

JRVR will use this data in a future update to automatically take the black bars off, and allow the image to fill such a ultrawide screen. For now we're only gathering data for future use.

"Live" black bar detection might come in the future, but as mattkhan said above, changing the rendering based on a live detection change might be rather jarring and unwanted.

[Smack]

So this feature make no sense on a 16:9 screen? I do have a 16:9 Screen (3,20 m x 2 m).

[Hendrik]

Nearly all video is designed to natively work on 16:9 screens, so further processing is not required.

[mattkhan]

I ran this against my library and, after some time, it crashed

not much to go on in logs but the dump (via windbg) says

Code: [Select]


SYMBOL_NAME:  Media_Center_30+b9d986

MODULE_NAME: Media_Center_30

IMAGE_NAME:  Media Center 30.exe

STACK_COMMAND:  ~11s; .ecxr ; kb

FAILURE_BUCKET_ID:  NULL_POINTER_READ_c0000005_Media_Center_30.exe!Unknown

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

IMAGE_VERSION:  30.0.91.0

I'll retry and see if it recurs

possibly related...  I deleted some library items after kicking this off so I wonder if it had queued up those for analysis and then blew up when it reached a deleted library item?

[Hendrik]

Black bar detection runs in JRWorker, that might not be related, or only tangentially.

A crash dump would be useful, can mail it to me if it generated one (hendrik at jriver)

[mattkhan]

sent (nb: I edited my previous post to add some possibly related info)

[Hendrik]

Deleting them causing this seems likely, I have added some checks to prevent it.