172 replies to this topic

[littlesat]

I tried on ultimo4k and the pip's were not located on the correct place (in 1080p and 2160p mode). In 2160p VU has a big bug where VTi and VU's own image can work-a-round. In VU's quadpip plugin I do no observe this work-a-round... And the work-a-round is likely not accepted by us.

[Dimitrij]

littlesat

A simple check.
Install the original image from ultimo4k.

http://code.vuplus.c...odel=vuultimo4k

Check quadpip plugin.

[littlesat]

That does not really help... 

 

Do you have something working?

 

Attached the plugin I used to check it on Ultimo4K. Please note the QuadPiP screen is here included in the plugin (why put it on 'main' code?). Note VU's plugin is not one to one compatible with openpli as for quadpip they need to abort FCC and the animations.

 

Note that on OpenPLi it seems the procs to position the eVideo windows are not responsive....

 

probably somehow can see a mistake I made

 

I also saw VU has in between new drivers. I'm not sure if we're already using them. 

 

And still they need to solve their 2160p issue... In the orriginal plugin they also do not have the work-a-round for it included....

 

And it is really a pain VU still has their own image... meaning they cannot or are not forced to really support 'pli-based' teams...

Attached Files

•  QuadPip.rar   22.36KB   35 downloads

Edited by littlesat, 8 September 2017 - 07:59.

[betacentauri]

Up to 25% of the display canvas used for each window.

Maybe position is relative. I mean PiP 1 is e.g. always in the left upper corner. PiP2 e.g. in left lower corner... And if you specifiy a position for PiP2 you can only position the window in that lower left corner.
Only a guess. As I don't have the box I cannot test.

Edited by betacentauri, 8 September 2017 - 07:58.

[littlesat]

Up to 25% of the display canvas used for each window.

This is the 2160p output PIP bug VU had from the beginning and they never fixed..... 

[littlesat]

Maybe position is relative. I mean PiP 1 is e.g. always in the left upper corner. PiP2 e.g. in left lower corner... And if you specifiy a position for PiP2 you can only position the window in that lower left corner.
Only a guess. As I don't have the box I cannot test. 

The plugin does not indicate it... the plugin indicates that you can position the PIP windows on a 720x576 "Canvas"

[littlesat]

Up to 25% of the display canvas used for each window.

Does this mean the max size is one quarter of the canvas per eWidget?

[Erik Slagter]

On VTI QuadPiP works flawlessly on the Ultimo 4K (1080p) and pretty good on the Solo 4K. On the latter it takes sometimes a few tries until all pictures kick in, but eventually they will. This is not meant to praise that image in any way, just for info.

I wonder though if the VTI team actually needed or had the time to develop workarounds for this plugin as both the drivers/updates from VU+ as the image are dated 21/22nd and 22nd of August, so there must have been very little time if any to do that unless they got a heads up a while ago.

I know that the Openpli team is against plugins that should be part of the image and I'm all for that, too, but that may not be possible here as Erik keeps pointing out. One feature of this plugin is the possibility to save several 4-channel configurations (I don't even know how many of those or if there even is a limit) which is really helpful if you actually use the QuadPiP often enough. I have my doubts if this can be transferred into the image if the solution would be to enhance the existing PiP functionality as it may be planned. I'm still a big fan of how the current PiP solution was implemented at the time by Littlesat.

You're still keep missing the point. Whether we're going to copy plugin, make our own plugin or implement it into enigma internally is not the point. The point is that the required driver support has too many bugs to me want spending any time on it. As soon as they're addressed, we can go ahead.

[Erik Slagter]

i read in the bcm original doc

 

for 7439 chips boxmode 5

 

chip have a hw limit not all screens can use up to fit

 

this is the info for box mode 5 !

 

Window 0 (MAIN / UHD)
Up to full-screen display (smooth scaling)
10-bit support / 1080i60 10-bit de-interlacing
Multi-PIP mode (3x):
Up to 25% of the display canvas used for each window.
480i60 8-bit de-interlacing

Still the drivers have a bug that is unrelated where the main/first PiP cannot be positioned outside the first quarter - at least unless you double the coordinates and then suddenly it's possible.

[littlesat]

 at least unless you double the coordinates and then suddenly it's possible.

 

Even that is not possible... I did check it... You can not move the window to the most right bottom position...

Edited by littlesat, 8 September 2017 - 08:36.

[Erik Slagter]

 

Up to 25% of the display canvas used for each window.

This is the 2160p output PIP bug VU had from the beginning and they never fixed.....

It's however not a hardware limitation as I proved already.

[Erik Slagter]

For those of you who want to experiment; I have made a little script (needs bash) that helps setting PiP coordinates manually. Without parameters it shows the current location, with parameters it sets them; use four percentages.

Attached Files

•  pip.zip   582bytes   16 downloads

[littlesat]

We could consider al least to re-add the support in the e2 binary.... at this moment the patches are reverted *but they do not harm)... Maybe "someone" could help to get the plugin running...

[littlesat]

As far I can see your script is manipulating cd /proc/stb/vmpeg/1

 

As far I remember I did not have issues with this one.... I had issues with cd /proc/stb/vmpeg/0, cd /proc/stb/vmpeg/2 and cd /proc/stb/vmpeg/3.... These procs were non responsive....

 

#!/bin/bash
 
case $(cat /proc/stb/video/videomode_50hz) in
                1080*)
                               xsize=720
                               ysize=576
                               ;;
                2160*)
                               xsize=1920
                               ysize=1080
                               ;;
                *)
                               echo "unknown output resolution"
                               exit 1
                               ;;
esac
 
printf "Canvas dimensions: %dx%d\n" $xsize $ysize
 
cd /proc/stb/vmpeg/1
 
for i in top left height width apply; do
                h=$(cat dst_$i)
                d=$[0x$h]
 
                case $i in
                               height|top)
                                               p=$[100 * d / ysize]
                                               ;;
                               width|left)
                                               p=$[100 * d / xsize]
                                               ;;
                               *)
                                               p=0
                                               ;;
                esac
 
                printf "%-10s  %04x  %4d  %d%%\n" "$i" 0x$h $d $p
done
 
declare -A pos
 
if [ $# -gt 3 ]; then
                pos[top]=$[$1 * ysize / 100]
                pos[left]=$[$2 * xsize / 100]
                pos[height]=$[$3 * ysize / 100]
                pos[width]=$[$4 * xsize / 100]
fi
 
for i in left top width height; do
                printf "%08x" ${pos[$i]} > dst_$i
done
 
echo 1 |> dst_apply

Edited by littlesat, 8 September 2017 - 12:59.

[littlesat]

root@vuultimo4k:~# ./pip.sh
Canvas dimensions: 1920x1080
./pip.sh: line 39: aspect: not found
top         0000  bash: invalid number '$[0x00000000]'
   0  bash: invalid number ''
0%
./pip.sh: line 39: aspect: not found
left        0000  bash: invalid number '$[0x00000000]'
   0  bash: invalid number ''
0%
./pip.sh: line 39: aspect: not found
height      0000  bash: invalid number '$[0x00000000]'
   0  bash: invalid number ''
0%
./pip.sh: line 39: aspect: not found
width       0000  bash: invalid number '$[0x00000000]'
   0  bash: invalid number ''
0%
apply       0001  bash: invalid number '$[0x00000001]'
   0  0%
./pip.sh: line 41: declare: not found
./pip.sh: line 51: syntax error: bad substitution

[WanWizard]

You need bash...

[Erik Slagter]

You need bash...

Like I already mentioned.

 

opkg install bash

[Erik Slagter]

As far I can see your script is manipulating cd /proc/stb/vmpeg/1
As far I remember I did not have issues with this one.... I had issues with cd /proc/stb/vmpeg/0, cd /proc/stb/vmpeg/2 and cd /proc/stb/vmpeg/3.... These procs were non responsive....

If this one already isn't working correctly, the others are of no interest. The "normal" PiP is used as for second quadrant in QuadPiP, the "normal" "main viewport" is used for the first quadrant. Both need to be working correctly for quadpip, along with the third and fourth video decoder.

 

Also have a look at /proc/stb/video/decodermode. You'll probably need to set it to "mosaic" before the third and fourth decoder will even start doing anything.

[Erik Slagter]

We could consider al least to re-add the support in the e2 binary.... at this moment the patches are reverted *but they do not harm)... Maybe "someone" could help to get the plugin running...

No, the code I had to add to workaround the incompatibilities is ugly.

[littlesat]

But it does not harm and when it works in 1080p
I can make the plugin