644 replies to this topic

[Rob van der Does]

VU has added the 4k to it's git; see http://code.vuplus.c...9dc238e461781ef

 

The e-manual for the box is attached:  Manual solo-4k.zip   9.27MB   240 downloads

[Erik Slagter]

Not in the OpenPLi BSP (yet).

 

Anyway, even when it does show up, don't expect images to be build immediately.

Edited by Erik Slagter, 15 October 2015 - 15:41.

[Rob van der Does]

The first test:  Solo 4k.pdf   623.15KB   296 downloads

[Erik Slagter]

The thing that's truly interesting about the 4k is not the "4k" but the new approach to tuners, which gets you four looped-through virtual tuners per physical tuner. If you replace your LNB's with especially suited ones, you even get four individual virtual tuners per physical tuner.

Edited by Erik Slagter, 23 October 2015 - 09:10.

[Rob van der Does]

The tuner part is indeed interesting. Also interesting would be to know how E2 is being made aware of this: via the drivers or via a (huge??) change?

 

Nevertheless the support of the h265 codec is interesting as well. Not for satelite reception in the near future, but for streaming. There is already a growing number of '4k-streams' available (YouTube). Due to the better compression I wouldn't be surprised if this is going to be used more and more (same as MP4 is being used for SD).

[blzr]

FWIW, this commit includes changes in vuplus' e2 to implement FBC tuners and hevc support:
http://code.vuplus.c...79f738a9ebfd11f

[Rob van der Does]

Yes, I've seen that. But way over my head to see the impact on E2 of the specific tuner.

[littlesat]

A pitty that this is a mega patch with things included that are not described... So it really hurts to port to a different environment...

But I agree the new tuner functionality and hevc stuff should be added in enigma2 and is something that could not be "added" to a bsp layer...

Edited by littlesat, 23 October 2015 - 16:56.

[Erik Slagter]

I was actually hoping they would have implemented this completely adhering to linuxdvb standards, then there would have to be no changes in enigma.

[betacentauri]

Erik e2 changes are necessary also when they adhere linux dvb standards. Look here https://github.com/O...ecoder.cpp#L303 h265 streamtype has to be added. Maybe more things have to be adapted...

[athoik]

Littlesat is right, it would be better if there were more commits with proper description.

 

Although looking on the code (and yes there is a code to look at )

 

1. Add support for H265 HEVC

 

http://code.vuplus.c...f968db25bf63f81

http://code.vuplus.c...f968db25bf63f81

http://code.vuplus.c...f968db25bf63f81

http://code.vuplus.c...f968db25bf63f81
http://code.vuplus.c...f968db25bf63f81

 

2. Add Full Bandwidth Capture Tuner Manager

 

http://code.vuplus.c...79f738a9ebfd11f

http://code.vuplus.c...79f738a9ebfd11f

http://code.vuplus.c...f968db25bf63f81

http://code.vuplus.c...f968db25bf63f81

...

 

3. Add 2160p resolution (hehe now skins should adapt?)

 

http://code.vuplus.c...f968db25bf63f81

 

4. ServiceMp3 update for GStreamer 1.0

 

http://code.vuplus.c...f968db25bf63f81

http://code.vuplus.c...f968db25bf63f81

 

5. Others..

 

Adding H265 HEVC is just a minor update to enigma2 in order to support.

 

The most important update is FBC capability on tuners and I guess you can have H265 HEVC without having FBC.

 

What do you think about VU FBC implementantion? Is it abstract enough? Or it can get better (the OpenPLi way)..

Edited by athoik, 24 October 2015 - 12:27.

[athoik]

Here are the OpenPLi changes to support h265 hevc. I can create a pull request, altough currently it just cosmetic change..

 

diff --git a/lib/dvb/decoder.cpp b/lib/dvb/decoder.cpp
index e194cc3..4a6eafc 100644
--- a/lib/dvb/decoder.cpp
+++ b/lib/dvb/decoder.cpp
@@ -299,6 +299,7 @@ eDVBVideo::eDVBVideo(eDVBDemux *demux, int dev)
 #define VIDEO_STREAMTYPE_MPEG4_Part2 4
 #define VIDEO_STREAMTYPE_VC1_SM 5
 #define VIDEO_STREAMTYPE_MPEG1 6
+#define VIDEO_STREAMTYPE_H265_HEVC 7

 int eDVBVideo::startPid(int pid, int type)
 {
@@ -325,6 +326,9 @@ int eDVBVideo::startPid(int pid, int type)
                case VC1_SM:
                        streamtype = VIDEO_STREAMTYPE_VC1_SM;
                        break;
+               case H265_HEVC:
+                       streamtype = VIDEO_STREAMTYPE_H265_HEVC;
+                       break;
                }

                eDebugNoNewLineStart("[eDVBVideo%d] VIDEO_SET_STREAMTYPE %d - ", m_dev, streamtype);
diff --git a/lib/dvb/decoder.h b/lib/dvb/decoder.h
index e179991..2db6282 100644
--- a/lib/dvb/decoder.h
+++ b/lib/dvb/decoder.h
@@ -40,7 +40,7 @@ private:
        int m_width, m_height, m_framerate, m_aspect, m_progressive;
        static int readApiSize(int fd, int &xres, int &yres, int &aspect);
 public:
-       enum { MPEG2, MPEG4_H264, MPEG1, MPEG4_Part2, VC1, VC1_SM };
+       enum { MPEG2, MPEG4_H264, MPEG1, MPEG4_Part2, VC1, VC1_SM, H265_HEVC };
        eDVBVideo(eDVBDemux *demux, int dev);
        void stop();
        int startPid(int pid, int type=MPEG2);
diff --git a/lib/dvb/pmtparse.cpp b/lib/dvb/pmtparse.cpp
index 91d89fd..7864a37 100644
--- a/lib/dvb/pmtparse.cpp
+++ b/lib/dvb/pmtparse.cpp
@@ -96,6 +96,12 @@ int eDVBPMTParser::getProgramInfo(program &program)
                                        video.type = videoStream::vtMPEG4_H264;
                                        isvideo = 1;
                                        //break; fall through !!!
+                               case 0x24: // H265 HEVC
+                                       if (!isvideo)

+                                       {
+                                               video.type = videoStream::vtH265_HEVC;
+                                               isvideo = 1;
+                                       }
                                case 0x10: // MPEG 4 Part 2
                                        if (!isvideo)
                                        {
diff --git a/lib/dvb/pmtparse.h b/lib/dvb/pmtparse.h
index 78ecf1b..ce27862 100644
--- a/lib/dvb/pmtparse.h
+++ b/lib/dvb/pmtparse.h
@@ -23,7 +23,7 @@ public:
        {
                int pid;
                int component_tag;
-               enum { vtMPEG2, vtMPEG4_H264, vtMPEG1, vtMPEG4_Part2, vtVC1, vtVC1_SM };
+               enum { vtMPEG2, vtMPEG4_H264, vtMPEG1, vtMPEG4_Part2, vtVC1, vtVC1_SM, vtH265_HEVC };
                int type;
        };

diff --git a/lib/dvb/scan.cpp b/lib/dvb/scan.cpp
index f295a89..943583a 100644
--- a/lib/dvb/scan.cpp
+++ b/lib/dvb/scan.cpp
@@ -381,6 +381,7 @@ void eDVBScan::PMTready(int err)
                                switch ((*es)->getType())
                                {
                                case 0x1b: // AVC Video Stream (MPEG4 H264)
+                               case 0x24: // H265 HEVC
                                case 0x10: // MPEG 4 Part 2
                                case 0x01: // MPEG 1 video
                                case 0x02: // MPEG 2 video

[littlesat]

When all the images are fine it is nice to have this patched... But because we do not have such VU4K yet there is nothing to test...

But in between it could be helpfull... e.g. then this is already done As far I can see there is no harm at all....

 

Let us at least push it as step-by-step commits

Even the new tuner support looks smooth the way you split the patches....

Edited by littlesat, 24 October 2015 - 13:46.

[Erik Slagter]

Git repo ATV-style :-( Checkout, make all the changes you like and then push everything in one go, even though it's not even related.

 

Nice work Athoik to find out what's really necessary. Yes, I understand we need added support for h265 etc. But as we know VU+ a bit, new hardware comes with new workarounds in enigma, because they often to abstract the hardware in the drivers, that is what I mean.

 

I think it's best to apply these to master-next.

[athoik]

The eTSMPEGDecoder::showSinglePic function also requires changes (if we still use it).

RESULT eTSMPEGDecoder::showSinglePic(const char *filename)
...
                                if (iframe[0] == 0x00 && iframe[1] == 0x00 && iframe[2] == 0x00 && iframe[3] == 0x01 && (iframe[4] & 0x0f) == 0x07)
                                        streamtype = VIDEO_STREAMTYPE_MPEG4_H264;
                                else
                                        streamtype = VIDEO_STREAMTYPE_MPEG2;
...

VU haven't patch this yet.

[Erik Slagter]

This is for backdrops in hevc? Hmmm, not prio #1 I guess

[Pedro_Newbie]

Does anyone have an educated guess about the possible difficulties about implementing the Vu+ Solo 4K into the BackupSuite?

Are there other requirements to be able to back-up a running system?

I see the original image is build with the use of bzip2 to create the root part of the image and is named rootfs.tar.bz2
They also changed to naming of the files, now they are: rootfs.tar.bz2 & kernel_auto.bin and before it was (mostly) root_cfe_auto.bin & kernel_cfe_auto.bin

[athoik]

Now they are using ARM arch and most probably ARM uses another second stage (not CFE based).

Regarding the root part I think it uses ext4 root filesystem, so backup will be like any other normal linux machine.

[MiLo]

ext4? That would require eMMC or so instead of regular NAND flash.

[Pedro_Newbie]

They are using eMMC according to the specs
http://vuplus.com/sub/sub0113.php