astra 2a testing signal 4k 28.2e

[Llew]

If it does indeed appear on Astra 3A sometime, according to their factsheet it'll be on 12.402 (V or H) - that's TP no. 3.236.

 

[strs65]

Ok, in that case there is a transmission on 12402,V,30000 DVB-S2/8PSK 5/6 (Astra 3B, no reception here of Astra 3A), with an encrypred pid (0x00FF) with huge bit rate (~50Mbps), but without any video or audio pids. Maybe they are using some other type of proprietary format...

 

[satesco]

Channel Name:Service 2
Channel Data:12441 V,sr.29500,3/4
Typ:MPEG-4 FTA{3840x2160 Resolution}
Sat Name:Astra 2B
Pos:28.2 E

 

[strs65]

Yes, that's known, the one that started this topic, no problem with that. Here it works best with SmartDVB 0.2.5.1 and the Coreavc 3.0.1 decoder. Do you have any interruptions and buffer overflows with DVBViewer Pro?

 

[satesco]

With DVBViewer Pro image is smooth, uninterrupted,without any sound that has no audio-pid.Image goes well with DivX H.264.
In a word work very well with DVB Viewer!

 

[strs65]

Ok thanks! What's the setup of your PC? I'm having those buffer overflows here with DVBViewer Pro, but not with SmartDVB or AltDVB...

 

[satesco]

Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz,Physical Memory:8192 MB,Type: DDR 3,HDD:SSD Corsair,Graphic CardVIDIA GeForce GTX 460,OS:Windows 7 Ultimate 64 bit

 

[solly]

what encrypted system using ultra hd
or maybe not use pid video or audio yet

 

[strs65]

what encrypted system using ultra hd
or maybe not use pid video or audio yet

This information is not given (no video/audio pids either)...

 

[solly]

it can be not start pid video and audio

 

[hvdh]

Astra 3B, 12363V 30000 2/3 8PSK ACM/VCM, MIS 17, also has some challenging video stream.
Broken video can be seen with VLC.

 

[solly]

picture sony screen ultra ha from ibc amsterdam

 

[BlindFaith]

Astra 3B, 12363V 30000 2/3 8PSK ACM/VCM, MIS 17, also has some challenging video stream.
Broken video can be seen with VLC.

What do you expect? According to crazyscan it's not a transport stream.

 

[hvdh]

Right, forgot to check the stream type. In other words, if stream type is not a transport stream, "we" will never get a clear picture?