New AVR - and some blank screen issues

[ac16161]

If a GUI-level toggle could be provided for the Vero, just as it is for the Pi, under in-playback video settings, that would be enough. Then, on a file-specific basis, deinterlacing could be bypassed. At present the option is there on the Vero, but greyed as not user-modifiable. If the hardware doesn’t allow that, that’s a shame.

There is a really simple test anyone with a Vero and a Pi can do if they have access to an interlace-encoded progressive source (a typical BBC bluray from the last 10 years, e.g. Sherlock, Dr Who season 5+). Whitelist 1080/25p as the only output resolution, and disable in-playback deinterlacing on the Pi. Watch how the Pi delivers perfect motion at 25p output, not a hint of a stutter, not a hint of moire. Now test the Vero - even with h264, it fails the 25p test, which seems conclusive that it is not getting the weave correct?

[jahutchi]

@sam_nazarko

I was not aware you were still having issues

That’s fair enough…it kinda got lost in the midst of the previous thread…here:

Problems with LiveTV stuttering on Vero 4k+

Not sure yet — need to check. I know this caused some problems for others. You seem to be the only one affected by this problem, and you have a solution, albeit via command line. Does your problem only occur for HD live tv?

A gui option is probably the way to go.

[ac16161]

@sam_nazarko

Other devices, like the Pi, have different HW IP blocks for decoding. Going from one device to another will usually give a deviation in picture quality which some will prefer and some won’t. One person’s reference standard is not another person’s.

did you get a chance to look at the screenshots I posted yesterday? It’s not a question of subjectivity, on some material the Vero has bad moire that is simply not supposed to be there. Please see also this post.

New AVR - and some blank screen issues

By hacking the kernel to force deinterlace off I can change this [image] to this [image] Now just need to figure out if we can recognise when deinterlacing should be turned off or else bring a setting out to the GUI. Is this something unique to VC-1 @ac16161 @angry.sardine?

[sam_nazarko]

A GUI option is doable, but I want to find a more elegant way to do this and avoid the plane cockpit approach.

@ac16161 I can see your images but hopefully I can get some samples (VC1 and h264), so that I can test some changes and improve things.

Obviously we want to make it as good as possible, so I appreciate the feedback. H264 is certainly doable. VC1 might be a pain / not possible to resolve, but I have some ideas to make things look a bit more appealing at least.

Sam

[sam_nazarko]

From what I can see, the CE patch is only used for 3.14.

4.9 gives different results.
Are you both able to use 4.9 for testing improvements?

[jahutchi]

@sam_nazarko

Are you both able to use 4.9 for testing improvements?

Is it possible to switch back and forth between 3.14<->4.9. I was holding off 4.9 until its stable as our family all use the vero for livetv on a daily basis.

[sam_nazarko]

I can produce some 4.9 USB/SD builds. I’d like some testing in that area before we embark on any changes however. The h264 changes might not be needed on 4.9

[angry.sardine]

@sam_nazarko

Are you both able to use 4.9 for testing improvements?

I’m on 4.9, and happy to help out with testing. I also have a Pi I can use for comparison purposes.

[ac16161]

@sam_nazarko

Are you both able to use 4.9 for testing improvements?

Yep, I have 4.9 testing Vero alongside my 3.14 box.

[angry.sardine]

@sam_nazarko

echo 0 > /sys/module/di/parameters/di_debug_flag

Btw, I just tried executing that during playback of a couple of VC-1 files, and it had no discernable effect.

[ac16161]

@angry.sardine

Btw, I just tried executing that during playback of a couple of VC-1 files, and it had no discernable effect.

likewise.

[jahutchi]

@sam_nazarko

I can produce some 4.9 USB/SD builds.

I have a spare usb stick so would be happy to take you up on that.

[sam_nazarko]

You would need to cat afterwards and check dmesg to verify it’s active.

@jahutchi – I’ll send you some test builds shortly, if you can send me some samples.

Sam

[jahutchi]

@sam_nazarko

if you can send me some samples

I’ll try to capture a sample…leave this with me.

[sam_nazarko]

Cool – if you need an upload link, let me know.

[jahutchi]

@jahutchi

I’ll try to capture a sample

This is proving tricky…

I was seeing frame skips just now in LiveTV: 1080i h264 ITV HD (with bypass_all=0).

To confirm I put the PlayerDebug info on-screen and could see the #skipped frames increasing at quite a rate. I hit record to try and capture this for you, but when I playback the resulting .TS or .MKV file it plays just fine and #skipped frames stays at 0.

I also find that if I stop and restart LiveTV on the same channel then the frame skips cease - so it almost seems like some sort of timing issue.

I checked in the logfiles (kodi.log and dmesg) but nothing is reported regarding the dropped frames: https://paste.osmc.tv/oheyayaqup if you want to take a look. The skips were happening frequently between 12:44-12:49 (when I hit stop) - the #skipped frames in kodi PlayerDebug was ~300!

I’ve been running for several months with my patch to set bypass_all=1 for h264 content and never once had frame skips, so the issue does certainly seem to be in that area.

Would be happy to do further testing against the 4.9 kernel if this can be ran separately on a USB/SD card as promised… for now I think it’s back to my custom build to set bypass_all=1 for h264

[sam_nazarko]

I’ve sent you some 4.9 test images.

[jahutchi]

Thanks - I’ll do some testing.

Is there an bypass_all equivalent parameter in 4.9, so I can try disabling di should I see frame skips during my testing.

[sam_nazarko]

Should still be there.

[angry.sardine]

Can I help with testing at all, Sam?