644 replies to this topic

[Erik Slagter]

Only oscam works, nothing else. It's not only CCcam, there are many other emus with various uses and of course none works. While this is almost obvious (since VU+ Solo 4K is a new architecture), a review should at least mention it!

Well I don't think it's "BIG NEWS", this is bound to happen with binary-only closed-source binaries. One of the reasons why that is evil.

[malakudi]

It's not big news. But people need to know, a review should mention it.

 

Another one: AVC/H264 Level 5.1 with 9 reference frames doesn't play (like all previous boxes). You would expect a 4K box to play anything from AVC. It doesn't. It is played back with corrupted frames.

 

Video

ID                                       : 1

Format                                   : AVC

Format/Info                              : Advanced Video Codec

Format profile                           : High@L5.1

Format settings, CABAC                   : Yes

Format settings, ReFrames                : 9 frames

Edited by malakudi, 12 November 2015 - 11:54.

[Rob van der Does]

The Blackhole review is hiding all issues. I found many issues just by testing it for half an hour, they don't mention anything.

No surprise there
BH = 100% VU (just as VTi). How could they possibly bark against their own tree?

[Erik Slagter]

Another one: AVC/H264 Level 5.1 with 9 reference frames doesn't play (like all previous boxes). You would expect a 4K box to play anything from AVC. It doesn't. It is played back with corrupted frames.

I've been making my own h264 streams since about 2006 I think. When I had my first h264-capable STB, which was a dm800, I was quite surprised it played just everything. It was only required to play 4.1 "main" without b-pyramid and without 8x8dct according to the DVB requirements, but it played them without problems anyway.

 

AFAIK almost "nothing" (hardware) can play media with more than about 4 reference frames. I guess it's also restricted by the profile, I'd have to check that.

Edited by Erik Slagter, 12 November 2015 - 12:03.

[Erik Slagter]

According to wikipedia https://en.wikipedia....264/MPEG-4_AVC, one can only use one 1 reference frames, 2 reference frames when b frames are used...

[malakudi]

According to wikipedia https://en.wikipedia....264/MPEG-4_AVC, one can only use one 1 reference frames, 2 reference frames when b frames are used...

 

Not really. From the link you quoted:

• Using previously encoded pictures as references in a much more flexible way than in past standards, allowing up to 16 reference frames (or 32 reference fields, in the case of interlaced encoding) to be used in some cases. This is in contrast to prior standards, where the limit was typically one; or, in the case of conventional "B pictures" (B-frames), two. This particular feature usually allows modest improvements in bit rate and quality in most scenes.^{[citation needed]} But in certain types of scenes, such as those with repetitive motion or back-and-forth scene cuts or uncovered background areas, it allows a significant reduction in bit rate while maintaining clarity.

[athoik]

Please note that our dvbmediasink modifies patch level to 4.1 ...

if (level_org > 0x29)
{
	GST_INFO_OBJECT (self, "H264 %s profile@%d.%d patched down to 4.1!", profile_str[i], level_org / 10 , level_org % 10);
	tmp[tmp_len+3] = 0x29; // level 4.1
}
else
{
	GST_INFO_OBJECT (self, "H264 %s profile@%d.%d", profile_str[i], level_org / 10 , level_org % 10);
}

So it might be possible that drivers never expect to get a profile greater than 4.1

[malakudi]

@athoik: I review VU+ Solo 4K with Blackhole, since there are no other images available (VTi should be the same).

 

edit: the problem hardware video decoders have with many reference frames in HD is the memory required. 16 frames of 1920*1080 requires 100MB of RAM. I would expect a 4K box to not have such limitations, that's why I am mentioning it. It could be possible that this memory could be configurable and newer drivers to enable support.

Edited by malakudi, 12 November 2015 - 12:25.

[athoik]

@athoik: I review VU+ Solo 4K with Blackhole, since there are no other images available (VTi should be the same).

They are using OpenPLi dvbmediasink (generally VU switch to OpenPLi dvbmediasink long time ago).

[Erik Slagter]

 

According to wikipedia https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC, one can only use one 1 reference frames, 2 reference frames when b frames are used...

 

Not really. From the link you quoted:

• Using previously encoded pictures as references in a much more flexible way than in past standards, allowing up to 16 reference frames (or 32 reference fields, in the case of interlaced encoding) to be used in some cases. This is in contrast to prior standards, where the limit was typically one; or, in the case of conventional "B pictures" (B-frames), two. This particular feature usually allows modest improvements in bit rate and quality in most scenes.^{[citation needed]} But in certain types of scenes, such as those with repetitive motion or back-and-forth scene cuts or uncovered background areas, it allows a significant reduction in bit rate while maintaining clarity.

They are referring here to multi-stream AVC and I guess they're comparing it to single-stream ("normal") AVC. Not to actual "previous" standards like mpeg4-vc.

[Erik Slagter]

Please note that our dvbmediasink modifies patch level to 4.1 ...
 

if (level_org > 0x29)
{
	GST_INFO_OBJECT (self, "H264 %s profile@%d.%d patched down to 4.1!", profile_str[i], level_org / 10 , level_org % 10);
	tmp[tmp_len+3] = 0x29; // level 4.1
}
else
{
	GST_INFO_OBJECT (self, "H264 %s profile@%d.%d", profile_str[i], level_org / 10 , level_org % 10);
}

So it might be possible that drivers never expect to get a profile greater than 4.1

That should be test-able using a transport stream, bypassing gstreamer altogether. But I think gstreamer passes the video stream transparently to the decoder anyway, I don't think it matters.

[Erik Slagter]

@athoik: I review VU+ Solo 4K with Blackhole, since there are no other images available (VTi should be the same).

 

edit: the problem hardware video decoders have with many reference frames in HD is the memory required. 16 frames of 1920*1080 requires 100MB of RAM. I would expect a 4K box to not have such limitations, that's why I am mentioning it. It could be possible that this memory could be configurable and newer drivers to enable support.

Memory indeed, but previous SoC also have lots of memory for the decoder, already. I don't think it's a memory-only limitation.

[malakudi]

 

 

According to wikipedia https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC, one can only use one 1 reference frames, 2 reference frames when b frames are used...

 

Not really. From the link you quoted:

• Using previously encoded pictures as references in a much more flexible way than in past standards, allowing up to 16 reference frames (or 32 reference fields, in the case of interlaced encoding) to be used in some cases. This is in contrast to prior standards, where the limit was typically one; or, in the case of conventional "B pictures" (B-frames), two. This particular feature usually allows modest improvements in bit rate and quality in most scenes.^{[citation needed]} But in certain types of scenes, such as those with repetitive motion or back-and-forth scene cuts or uncovered background areas, it allows a significant reduction in bit rate while maintaining clarity.

They are referring here to multi-stream AVC and I guess they're comparing it to single-stream ("normal") AVC. Not to actual "previous" standards like mpeg4-vc.

 

 

They are referring to the standard, H.264/AVC/MPEG-4 Part 10. And the standard can support up to 16 reference frames. x264 (the software encoder for H.264) does too. Most STBs are only limited to 4 reference frames on HD, but this is not a limitation of the standard. It is a limitation of hardware requirements of the decoder (mostly memory).

Edited by malakudi, 12 November 2015 - 14:29.

[malakudi]

Update: Same files play fine on VU+ Solo2. Last time I checked them they were not playing (long time ago). So I guess it is either a gstreamer issue on VU+ Solo 4K or a driver issue.

[Erik Slagter]

If you say "driver issue" in one sentence with "VU+", then I say, "very well possible"

 

But as said before, I've never had issues with all sorts of h264 "tools" parameters on set-top-boxes, making it profile high@5.2. But maybe I didn't try on VU+

 

I use ref = 4 because some (other) hardware may not play more, including brain-dead bluray players, apparently 6 is default for libx264.

[malakudi]

And some good findings:

Managed to use all 8 tuners, even with just one cable. Of course with one cable I could only tune 1 satellite and one quadrant of the possible transponders (I don't have unicable). I tuned eight different transponders. I managed to record up to seven (7) encrypted streams. When trying to record or playback an 8th stream, it couldn't. I could record additionaly another 8 fta streams, for a total number of 15.

[athoik]

Can you post the following?
 

ls -1  /dev/dvb/adapter*/* | sort

Edited by athoik, 12 November 2015 - 16:11.

[Erik Slagter]

And some good findings:

Managed to use all 8 tuners, even with just one cable. Of course with one cable I could only tune 1 satellite and one quadrant of the possible transponders (I don't have unicable). I tuned eight different transponders. I managed to record up to seven (7) encrypted streams. When trying to record or playback an 8th stream, it couldn't. I could record additionaly another 8 fta streams, for a total number of 15.

This is strange, because all current SoC have all CA-demuxers. I'd rather think of yut another bug.

[malakudi]

@Erik: could it be a limit of oscam? Or the camd.socket? If I remember well, emus could never decode above 7 services due to a limitation in camd.socket API.

@Athoik:

 

15 demuxers, 15 descramblers, 15 DVRs, 8 frontends

ls -1 /dev/dvb/adapter0/* | sort
/dev/dvb/adapter0/audio0
/dev/dvb/adapter0/audio1
/dev/dvb/adapter0/ca0
/dev/dvb/adapter0/ca1
/dev/dvb/adapter0/ca10
/dev/dvb/adapter0/ca11
/dev/dvb/adapter0/ca12
/dev/dvb/adapter0/ca13
/dev/dvb/adapter0/ca14
/dev/dvb/adapter0/ca2
/dev/dvb/adapter0/ca3
/dev/dvb/adapter0/ca4
/dev/dvb/adapter0/ca5
/dev/dvb/adapter0/ca6
/dev/dvb/adapter0/ca7
/dev/dvb/adapter0/ca8
/dev/dvb/adapter0/ca9
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/demux1
/dev/dvb/adapter0/demux10
/dev/dvb/adapter0/demux11
/dev/dvb/adapter0/demux12
/dev/dvb/adapter0/demux13
/dev/dvb/adapter0/demux14
/dev/dvb/adapter0/demux2
/dev/dvb/adapter0/demux3
/dev/dvb/adapter0/demux4
/dev/dvb/adapter0/demux5
/dev/dvb/adapter0/demux6
/dev/dvb/adapter0/demux7
/dev/dvb/adapter0/demux8
/dev/dvb/adapter0/demux9
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/dvr1
/dev/dvb/adapter0/dvr10
/dev/dvb/adapter0/dvr11
/dev/dvb/adapter0/dvr12
/dev/dvb/adapter0/dvr13
/dev/dvb/adapter0/dvr14
/dev/dvb/adapter0/dvr2
/dev/dvb/adapter0/dvr3
/dev/dvb/adapter0/dvr4
/dev/dvb/adapter0/dvr5
/dev/dvb/adapter0/dvr6
/dev/dvb/adapter0/dvr7
/dev/dvb/adapter0/dvr8
/dev/dvb/adapter0/dvr9
/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/frontend1
/dev/dvb/adapter0/frontend2
/dev/dvb/adapter0/frontend3
/dev/dvb/adapter0/frontend4
/dev/dvb/adapter0/frontend5
/dev/dvb/adapter0/frontend6
/dev/dvb/adapter0/frontend7
/dev/dvb/adapter0/frontend8
/dev/dvb/adapter0/net0
/dev/dvb/adapter0/net1
/dev/dvb/adapter0/net10
/dev/dvb/adapter0/net11
/dev/dvb/adapter0/net12
/dev/dvb/adapter0/net13
/dev/dvb/adapter0/net14
/dev/dvb/adapter0/net2
/dev/dvb/adapter0/net3
/dev/dvb/adapter0/net4
/dev/dvb/adapter0/net5
/dev/dvb/adapter0/net6
/dev/dvb/adapter0/net7
/dev/dvb/adapter0/net8
/dev/dvb/adapter0/net9
/dev/dvb/adapter0/video0
/dev/dvb/adapter0/video1

Edited by malakudi, 12 November 2015 - 17:13.

[athoik]

@malakudi, also 2 video devices, so PIP as expected..