Jump to content


Photo

GStreamer 1.0

gstreamer 1.0 openpli

  • Please log in to reply
2520 replies to this topic

Re: GStreamer 1.0 #161 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 26 October 2014 - 14:38

"video/x-3ivx and video/x-xvid -> video/mpeg,mpegversion=4

If it ever turns out that we really must use thoe specific fourccs and not the generic one, we can still add a flavor field to the caps later." - http://cgit.freedesk...0df64b50d46b04e
 
So in case of negative feedback we could add this "flavor" field. For example I did something like this in #154 solution 1, where "flavor" field is mpeg4codec.


Re: GStreamer 1.0 #162 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 26 October 2014 - 14:52

mx3L,

I don't think we have problem with 3ivx, it uses the same bypass. The problem is only with xvid that uses different bypass or because it packs unpacked bitstream.

There is a bug opened in GStreamer for xvid, please share your usefull toughts here too: https://bugzilla.gno...g.cgi?id=739196

Edited by athoik, 26 October 2014 - 14:52.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #163 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 26 October 2014 - 15:07

athoik,

 

I know we don't have problem with 3ivx, I just added reference to the quoted commit message. I believe It also applies for xvid codec since 3ivx was immediate commit after xvid one.

This commit message gives us clue about how to handle this issue properly in case of negative feedback from gstreamer's devs, so no need to revert many commits.

 

Thanks will look into that.



Re: GStreamer 1.0 #164 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 26 October 2014 - 15:14

I don't understand why there needs to be an identifier for divx, xvid, etc? It's all mpeg4-vc after all.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: GStreamer 1.0 #165 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 26 October 2014 - 15:21

I don't understand why there needs to be an identifier for divx, xvid, etc? It's all mpeg4-vc after all.


Also why we need to pack unpacked xvid? (#define PACK_UNPACKED_XVID_DIVX5_BITSTREAM)
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #166 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 28 October 2014 - 08:22

rtmp vod streams in general:
- seeking is not possible, after seek action, picture just freezes


It seems that the problem with seeking is the same as in latest 0.10 branch that we had to revert a commit (http://forums.openpl...h-rtmp-streams/).

The problem seems again to be the unlock function. Additionally it causes segfaults when calling RTMP_Close while another thread is in receiving state (https://bugzilla.gno...g.cgi?id=739263)

I removed the unlock function, but this time I added the RTMP_Close in stop, in order to properly release rtmp memory (without Close most probably we have memory leaks). Although again we might have segfaults! On my tests didn't manage to get another one with the patch applied.

@m3xL, can you test if seeking works with the patch applied (or provide a test rtmp url)?

Attached Files


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #167 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 28 October 2014 - 10:06

athoik,

seeking in rtmp streams now works, good job



Re: GStreamer 1.0 #168 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 29 October 2014 - 10:37

There is a problem with playback of HTTPS streams.
 

gst-launch-1.0 playbin uri='https://r3---sn-nf5o-cune.googlevideo.com/videoplayback?sparams=id%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Cmm%2Cms%2Cmv%2Cratebypass%2Crequiressl%2Csource%2C
upn%2Cexpire&itag=22&id=o-ACJOt5TMeGnFpXs_EIp9XIEu9IV-AfhihawzjYvKB0te&source=youtube&ratebypass=yes&initcwndbps=2307500&ip=91.219.132.80&key=yt5&fexp=912130%2C914020%2C917000%2C924637%2C927622%2C930666%2C93067
2%2C931983%2C932404%2C947209%2C952302%2C952901%2C955102%2C957103&expire=1414536219&sver=3&mv=m&mt=1414514563&signature=7F5C5F9795251F2F1C5CAF5FFD5F921174E94CA8.50B604DAECD4161FCD4B4D1EE8F65F3A62934193&ms=au&mm=
31&ipbits=0&requiressl=yes&upn=ObSfxayrIVA'
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source: Secure connection setup failed.
Additional debug info:
/home/marko/git/openpli-oe-core/build/tmp/work/mips32el-oe-linux/gstreamer1.0-plugins-good/1.4.3-r0/gst-plugins-good-1.4.3/ext/soup/gstsouphttpsrc.c(1502): gst_soup_http_src_parse_status (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:
Unacceptable TLS certificate (6), URL: https://r3---sn-nf5o-cune.googlevideo.com/videoplayback?sparams=id%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Cmm%2Cms%2Cmv%2Cratebypass%2Crequiressl%2Csource%2Cupn%2Cexpire&itag=22&id=o-ACJOt5TMeGnFpXs_EIp9XIEu9IV-AfhihawzjYvKB0te&source=youtube&ratebypass=yes&initcwndbps=2307500&ip=91.219.132.80&key=yt5&fexp=912130%2C914020%2C917000%2C924637%2C927622%2C930666%2C930672%2C931983%2C932404%2C947209%2C952302%2C952901%2C955102%2C957103&expire=1414536219&sver=3&mv=m&mt=1414514563&signature=7F5C5F9795251F2F1C5CAF5FFD5F921174E94CA8.50B604DAECD4161FCD4B4D1EE8F65F3A62934193&ms=au&mm=31&ipbits=0&requiressl=yes&upn=ObSfxayrIVA, Redirect to: (NULL)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...


This is related to change in latest gstreamer version:
 

Gstreamer 1.4.3 introduced for souphttpsrc: Add properties for selecting SSL/TLS certificate checking
And by default properly check certificates against the system's CA certificates. Everything else is not a good default at all.

 



I managed to playback this video with ssl-strict option turned off:

gst-launch-1.0 -v souphttpsrc ssl-strict=false location='https://r3---sn-nf5o-cune.googlevideo.com/videoplayback?sparams=id%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Cmm%2Cms%2Cmv%2Crateby
pass%2Crequiressl%2Csource%2Cupn%2Cexpire&itag=22&id=o-ACJOt5TMeGnFpXs_EIp9XIEu9IV-AfhihawzjYvKB0te&source=youtube&ratebypass=yes&initcwndbps=2307500&ip=91.219.132.80&key=yt5&fexp=912130%2C914020%2C917000%2C924
637%2C927622%2C930666%2C930672%2C931983%2C932404%2C947209%2C952302%2C952901%2C955102%2C957103&expire=1414536219&sver=3&mv=m&mt=1414514563&signature=7F5C5F9795251F2F1C5CAF5FFD5F921174E94CA8.50B604DAECD4161FCD4B4
D1EE8F65F3A62934193&ms=au&mm=31&ipbits=0&requiressl=yes&upn=ObSfxayrIVA' !queue!qtdemux!dvbvideosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstDVBVideoSink:dvbvideosink0.GstPad:sink: caps = "video/x-h264\,\ stream-format\=\(string\)avc\,\ alignment\=\(string\)au\,\ level\=\(string\)3.1\,\ profile\=\(string\)high\,\ codec_data\=\(buffer\)0164001fffe1001c6764001facb4028022fcdff819081900800001f480005dc0078c195001000468ee3cb0\,\ width\=\(int\)1280\,\ height\=\(int\)534\,\ framerate\=\(fraction\)24000/1001\,\ pixel-aspect-ratio\=\(fraction\)801/800"
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock

So in case we don't figure out why ssl-strict option enabled doensn't work, even with ca-certificates package installed, we could turn it off.

 

Attached Files



Re: GStreamer 1.0 #169 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 29 October 2014 - 18:05

So in case we don't figure out why ssl-strict option enabled doensn't work, even with ca-certificates package installed, we could turn it off.


mx3L, if you have a "static" url (not a dynamic from google etc) and this continues to happen, most probably we need to create a new bug report.

Although I guess setting ssl-strict off by default it will be nice feature for most of the users..
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #170 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 30 October 2014 - 09:53

athoik,

 

This is not an issue anymore, I didn't notice that my system time was set to 1970 :), after setting it up, playback of HTTPS videos with "ssl-strict" option enabled is working

gst-launch-1.0 -v souphttpsrc ssl-strict=true location='https:
//r3---sn-nf5o-cune.googlevideo.com/videoplayback?fexp=927622%2C927882%2C930666%
2C930672%2C932404%2C934040%2C936117%2C941393%2C947209%2C947215%2C952302%2C952901
%2C953912%2C957103&itag=18&sparams=id%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Cmm%2C
ms%2Cmv%2Cratebypass%2Crequiressl%2Csource%2Cupn%2Cexpire&ipbits=0&ratebypass=ye
s&key=yt5&upn=ykw0PrA02Bk&expire=1414679638&sver=3&mv=m&mt=1414657162&ms=au&id=o
-AJxZTD-cz525g7QawMN88P45VumM5529otsdHqC1rBeU&source=youtube&mm=31&initcwndbps=2
151250&ip=91.219.132.80&signature=34E9A44E3B036718DA499D033434A6A67A2191C8.3C5F8
D5C375AE3EB940FA9CC7466EF1046D81AAD&requiressl=yes' !queue!qtdemux!dvbvideosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstDVBVideoSink:dvbvideosink0.GstPad:sink: caps = "video/x-h264\,\ stream-format\=\(string\)avc\,\ alignment\=\(string\)au\,\ level\=\(string\)3\,\ profile\=\(string\)constrained-baseline\,\ codec_data\=\(buffer\)0142c01effe100196742c01eda0280bfe5c044000003000400000300c03c58ba8001000468ce3c80\,\ width\=\(int\)640\,\ height\=\(int\)360\,\ framerate\=\(fraction\)24/1\,\ pixel-aspect-ratio\=\(fraction\)1/1"
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock


Re: GStreamer 1.0 #171 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 30 October 2014 - 09:55

What about self signed certificates? ;)


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #172 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 30 October 2014 - 10:34

Sorry, don't follow, what about them?

 

As for gstreamer, I noticed another issue. When I'm trying to use relative seek from PAUSED state, it always causes deadlock.



Re: GStreamer 1.0 #173 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 30 October 2014 - 10:45

With self signed certificates it's sure that ssl-strict must be false in order to work.

 

Regarding the deadlock you can run enigma2 with GST_DEBUG (init 4; GST_DEBUG=*:6 enigma2 2>&1 | tee e2.log). Maybe there is something clear in the logs.

 

If above doesn't work then I guess we need to kill enigma2 with SIGSEVG and examine the core dump with gdb.


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #174 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 30 October 2014 - 18:56

mx3L,

Here is a gdb stack trace of threads (thread apply all bt) when deadlock is happening.

http://pastebin.com/5qcwqJry

There is a deadlock and easy to reproduce with Enigma2..
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #175 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 30 October 2014 - 23:07

Here is another gdb stack trace of thread (with more dbg packages installed now)

http://pastebin.com/eTFuD03v

Anyone has a clue of what goes wrong?
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #176 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 31 October 2014 - 09:57

There is a problem with playback of HTTPS streams.

gst-launch-1.0 playbin uri='https://r3---sn-nf5o-cune.googlevideo.com/videoplayback?sparams=id%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Cmm%2Cms%2Cmv%2Cratebypass%2Crequiressl%2Csource%2C
upn%2Cexpire&itag=22&id=o-ACJOt5TMeGnFpXs_EIp9XIEu9IV-AfhihawzjYvKB0te&source=youtube&ratebypass=yes&initcwndbps=2307500&ip=91.219.132.80&key=yt5&fexp=912130%2C914020%2C917000%2C924637%2C927622%2C930666%2C93067
2%2C931983%2C932404%2C947209%2C952302%2C952901%2C955102%2C957103&expire=1414536219&sver=3&mv=m&mt=1414514563&signature=7F5C5F9795251F2F1C5CAF5FFD5F921174E94CA8.50B604DAECD4161FCD4B4D1EE8F65F3A62934193&ms=au&mm=
31&ipbits=0&requiressl=yes&upn=ObSfxayrIVA'
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source: Secure connection setup failed.
Additional debug info:
/home/marko/git/openpli-oe-core/build/tmp/work/mips32el-oe-linux/gstreamer1.0-plugins-good/1.4.3-r0/gst-plugins-good-1.4.3/ext/soup/gstsouphttpsrc.c(1502): gst_soup_http_src_parse_status (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:
Unacceptable TLS certificate (6), URL: https://r3---sn-nf5o-cune.googlevideo.com/videoplayback?sparams=id%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Cmm%2Cms%2Cmv%2Cratebypass%2Crequiressl%2Csource%2Cupn%2Cexpire&itag=22&id=o-ACJOt5TMeGnFpXs_EIp9XIEu9IV-AfhihawzjYvKB0te&source=youtube&ratebypass=yes&initcwndbps=2307500&ip=91.219.132.80&key=yt5&fexp=912130%2C914020%2C917000%2C924637%2C927622%2C930666%2C930672%2C931983%2C932404%2C947209%2C952302%2C952901%2C955102%2C957103&expire=1414536219&sver=3&mv=m&mt=1414514563&signature=7F5C5F9795251F2F1C5CAF5FFD5F921174E94CA8.50B604DAECD4161FCD4B4D1EE8F65F3A62934193&ms=au&mm=31&ipbits=0&requiressl=yes&upn=ObSfxayrIVA, Redirect to: (NULL)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
This is related to change in latest gstreamer version:
 

Gstreamer 1.4.3 introduced for souphttpsrc: Add properties for selecting SSL/TLS certificate checking
And by default properly check certificates against the system's CA certificates. Everything else is not a good default at all.



I managed to playback this video with ssl-strict option turned off:
gst-launch-1.0 -v souphttpsrc ssl-strict=false location='https://r3---sn-nf5o-cune.googlevideo.com/videoplayback?sparams=id%2Cinitcwndbps%2Cip%2Cipbits%2Citag%2Cmm%2Cms%2Cmv%2Crateby
pass%2Crequiressl%2Csource%2Cupn%2Cexpire&itag=22&id=o-ACJOt5TMeGnFpXs_EIp9XIEu9IV-AfhihawzjYvKB0te&source=youtube&ratebypass=yes&initcwndbps=2307500&ip=91.219.132.80&key=yt5&fexp=912130%2C914020%2C917000%2C924
637%2C927622%2C930666%2C930672%2C931983%2C932404%2C947209%2C952302%2C952901%2C955102%2C957103&expire=1414536219&sver=3&mv=m&mt=1414514563&signature=7F5C5F9795251F2F1C5CAF5FFD5F921174E94CA8.50B604DAECD4161FCD4B4
D1EE8F65F3A62934193&ms=au&mm=31&ipbits=0&requiressl=yes&upn=ObSfxayrIVA' !queue!qtdemux!dvbvideosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstDVBVideoSink:dvbvideosink0.GstPad:sink: caps = "video/x-h264\,\ stream-format\=\(string\)avc\,\ alignment\=\(string\)au\,\ level\=\(string\)3.1\,\ profile\=\(string\)high\,\ codec_data\=\(buffer\)0164001fffe1001c6764001facb4028022fcdff819081900800001f480005dc0078c195001000468ee3cb0\,\ width\=\(int\)1280\,\ height\=\(int\)534\,\ framerate\=\(fraction\)24000/1001\,\ pixel-aspect-ratio\=\(fraction\)801/800"
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
So in case we don't figure out why ssl-strict option enabled doensn't work, even with ca-certificates package installed, we could turn it off.

Applied, thanks.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: GStreamer 1.0 #177 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 31 October 2014 - 10:02

I don't understand why there needs to be an identifier for divx, xvid, etc? It's all mpeg4-vc after all.

Also why we need to pack unpacked xvid? (#define PACK_UNPACKED_XVID_DIVX5_BITSTREAM)

I know of something that may or may not be related. "Divx" (as complete product, not only the videocodec) uses avi as container. Avi cannot properly handle B-frames because it cannot store DTS (which for B-frames is different than the PTS). Divx workarounds this issue by "packing" B-frames together with P-frames, which is "illegal" according to mpeg4-vc, and a generic mpeg4-vc codec won't decode it properly. Almost all players handle this case though and so they get away with it.

Maybe this is what they refer to?

Don't know why it's called xvid though, because it concerns divx, not xvid. Also if divx would have use the proper container (mp4...) then this also would never have existed. But divx has a way of cutting corners, unfortunately.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: GStreamer 1.0 #178 Erik Slagter

  • PLi® Core member
  • 46,960 posts

+541
Excellent

Posted 31 October 2014 - 10:07

rtmp vod streams in general:
- seeking is not possible, after seek action, picture just freezes


It seems that the problem with seeking is the same as in latest 0.10 branch that we had to revert a commit (http://forums.openpl...h-rtmp-streams/).

The problem seems again to be the unlock function. Additionally it causes segfaults when calling RTMP_Close while another thread is in receiving state (https://bugzilla.gno...g.cgi?id=739263)

I removed the unlock function, but this time I added the RTMP_Close in stop, in order to properly release rtmp memory (without Close most probably we have memory leaks). Although again we might have segfaults! On my tests didn't manage to get another one with the patch applied.

@m3xL, can you test if seeking works with the patch applied (or provide a test rtmp url)?

Is this a patch meant for patching gstreamer from a bb file?

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: GStreamer 1.0 #179 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 31 October 2014 - 10:16

 

Is this a patch meant for patching gstreamer from a bb file?

 

 

Correct.


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: GStreamer 1.0 #180 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 31 October 2014 - 19:24

When I'm trying to use relative seek from PAUSED state, it always causes deadlock.


Can you try the following patch, does it solve the problem in the expected way?

Attached Files


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916



3 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users


    Bing (1)