Quantcast
Channel: Xilinx Wiki : Xilinx Wiki - all changes
Viewing all 11776 articles
Browse latest View live

Booting via Serial ATA (SATA) on ZCU102 Evaluation Platform

$
0
0
This wiki page outlines the general workflow required to configure the ZCU102 evaluation platform to boot via the serial ATA (SATA) interface available on the Zynq UltraScale+ MPSoC device. In general, these steps follow those outlined on the main landing page of the Xilinx wiki. Where needed, alterations to the workflow are noted.
...
ES2 Board, and, RevD2 Prod
SATA is enabled by default in Vivado 2017.1 Board files. Same holds true for the Default ZCU102 Board Template HDF used in Petalinux 2017.1 and SDK 2017.1.
Build Images using PetaLinux 2017.1

Xilinx V4L2 Demosaic driver

$
0
0
{under.jpg} 2017.3 Updates Coming Soon
...
for Xilinx VideoSensor Demosaic soft IP. To understand more details about the Sensor Demosaic IP please
see the Product Guide below.

Overview
...
Demosaic IP core.Thecore.
The
Xilinx V4L2
...
control the Sensor Demosaic Soft
Linux Kernel Location
The driver is currently located in a special early access branch of the standard Xilinx Linux kernel. See drivers/media/platform/xilinx/xilinx-demosaic.c
...
{Demosaic_Kconfig.jpg}
Device tree binding
...
define the DT node is
...
here :
Documentation/devicetree/bindings/media/xilinx/xlnx,v-demosaic-v1.0.txt

Documentation/devicetree/bindings/media/xilinx/xlnx,v-demosaic.txt

(This path
...
to your linuxLinux kernel source
Limitations
12 and 16 color depth is not supported by this driver. Maximum color depth supported by the VPSS CSC soft IP driver is limited to 8-bit and 10-bit in this release
...
Supported Features
Only the following feature is supported :
Converting8-bit and 10-bit color depth support
Converting
input Bayer
...
RGB streaming video(24video (24 bit).
Driver will come up with a default media bus format of RGGB on the Sink Pad and a default media bus format of RGB on the Source Pad.
...
Source Pad (output) media bus
...
be changed throughtthrough media-ctl. However, the sinkSink pad's (input) media bus
entity 16: a0060000.demosaic (2 pads, 2 links)
type V4L2 subdev subtype Unknown flags 0

Xilinx V4L2 Demosaic driver (Updated early access branch to 2017.2_ea)

$
0
0

Xilinx V4L2 Demosaic driver

$
0
0
...
Linux Drivers
Xilinx V4L2 driver
Save

Xilinx V4L2 Demosaic driver

$
0
0
{under.jpg} 2017.3 Updates Coming Soon
...
about the Sensor
Sensor
Demosaic IP please
see
see the Product
Overview
The Linux V4L2 Demosaic driver is based on the V4L2 framework, and creates a subdev node(/dev/v4l-subdev*) which can be used to configure the Demosaic IP core.

Xilinx V4L2 Demosaic driver

$
0
0
...
Fringe Tolerant Interpolation is not supported. Only High Resolution Interpolation is supported by the driver.
Supported Features
The following table compares the IP features against those supported by the V4L2 driver
Sensor Demosaic (v 1.0) IP Features
Sensor Demosaic V4L2 Driver Support
1. 8-bit color depth
2017.1 Early Acccess
2. Horizontal Zipper Artifact Removal
2017.1 Early Access
3. High Resolution Interpolation
2017.1 Early Access
4. 10-bit color depth
2017.3 Early Access
5. Fringe Tolerant Interpolation
Not Supported

Only the following feature is supported :
8-bit and 10-bit color depth support

Xilinx V4L2 Gamma Correction LUT driver

$
0
0
{under.jpg} 2017.3 Updates Coming Soon
...
soft IP. To understand more details about this IP
and its functionality please see the Product Guide (below).

Overview
...
V4L2 Gamma Correction LUT driver (xilinx-gamma.c) is based on
...
V4L2 framework and creates a
...
and Blue gamma correction components. The
Linux Kernel Location
...
of the standard Xilinx Linux
...
See drivers/media/platform/xilinx/xilinx-gamma.c for the source code.
Linux Kernel defconfig
CONFIG_VIDEO_XILINX_GAMMA and CONFIG_VIDEO_XILINX should be enabled.
{Gamma_Kconfig.jpg}
Device tree binding
The dtsdevice tree node should
...
documented here:
Documentation/devicetree/bindings/media/xilinx/xlnx,v-gamma-lut-v1.0.txt

Documentation/devicetree/bindings/media/xilinx/xlnx,v-gamma-lut.txt

(This path
...
to your linuxLinux kernel source root directory)
Limitations
10,12 and 16 bit color depth is not supported by this driver. Maximum color depth supported by the Gamma LUT soft IP driver is limited to 8-bit in this release.

Supporting features
The following table compares the IP features against those supported by the V4L2 driver
Gamma LUT (v 1.0) IP Features
Gamma LUT V4L2 Driver Support
8-bit color depth
2017.1 Early Access
10-bit color depth
2017.3 Early Access

The Gamma Correction LUT soft IP provides a way to apply correction to each Red, Green and Blue components.
Exposes a V4L2 control to program Red, Green and Blue gamma values.
...
ZCU102 Rev 1.0
Technical Reference Designs
Coming SoonreVision Getting Started
Work to be done
SupportUser/Application programmable coefficients to program custom values intothe Red, Blue
...
Look Up Tables entered by the user.Tables.
Related Links
Gamma LUT Product Guide

Video Framebuffer Write

$
0
0
...
When the active frame completes, it is moved to the “done” list. The driver utilizes a tasklet which is called at the end of the frame interrupt handler. The tasklet will process any buffer descriptors on the done list by removing them from the list and calling any callback the client has linked to the descriptor.
This completes the lifecycle of a buffer descriptor. As can be seen, with four possible states, it is best to allocate at least four buffers to maintain consistent frame processing. Fewer buffers will result in gaps within the pipeline and result in frame data within a given buffer being overwritten one or more times (depending on how few buffers are queued and the number of resulting gaps in the driver’s buffer pipeline).
Note:* Note: normally, registers
...
effect, twice.


Video Framebuffer Write

$
0
0
...
v_frmbuf_rd_0: v_frmbuf_rd@80000000 {
#dma-cells = <1>;
compatible = "xlnx,axi-frmbuf-wr-1.00.a";"xlnx,axi-frmbuf-wr-v2";
interrupt-parent = <&gic>;
interrupts = <0 92 4>;
...
When the active frame completes, it is moved to the “done” list. The driver utilizes a tasklet which is called at the end of the frame interrupt handler. The tasklet will process any buffer descriptors on the done list by removing them from the list and calling any callback the client has linked to the descriptor.
This completes the lifecycle of a buffer descriptor. As can be seen, with four possible states, it is best to allocate at least four buffers to maintain consistent frame processing. Fewer buffers will result in gaps within the pipeline and result in frame data within a given buffer being overwritten one or more times (depending on how few buffers are queued and the number of resulting gaps in the driver’s buffer pipeline).
&#42; Note:Note: normally, registers
...
effect, twice.

Video Framebuffer Write

$
0
0
...
When the active frame completes, it is moved to the “done” list. The driver utilizes a tasklet which is called at the end of the frame interrupt handler. The tasklet will process any buffer descriptors on the done list by removing them from the list and calling any callback the client has linked to the descriptor.
This completes the lifecycle of a buffer descriptor. As can be seen, with four possible states, it is best to allocate at least four buffers to maintain consistent frame processing. Fewer buffers will result in gaps within the pipeline and result in frame data within a given buffer being overwritten one or more times (depending on how few buffers are queued and the number of resulting gaps in the driver’s buffer pipeline).
Note:&#42; Note: normally, registers
...
effect, twice.

Video Framebuffer Read

$
0
0
= {under.jpg}
=

Overview
Video Framebuffer Read IP cores are designed for video applications requiring frame buffers and is designed for high-bandwidth access between the AXI4-Stream video interface and the AXI4-interface.
Location
...
Linux kernel:
https://github.com/Xilinx/linux-xlnx/tree/2017.1_video_ea
<TBD>
Supported IP FeaturesSupported IP Features
The following is a list of IP constraints for which there is support in the driver and for which verification within the context of the listed reference designs has been performed (see below):
Streaming1. Streaming Video Format
...
RGB, YUV 4:2:2
Memory
4:2:2, YUV 4:4:4, YUV 4:2:0
2. Memory
Video Format Support: RGB8, BGRX8, RGBX8, YUYV8, YUVX8, RGBX10, YUVX10, Y_UV8, RGB8
Programmable
Y_UV8_420, UYVY8, YUV8, Y_UV10, Y_UV10_420, Y8, Y10
3. Programmable
memory video format
Support

4. Support
for 8-bit or 10-bit per color
...
memory interface
Resolutions

5. Resolutions
up to
Unsupported IP FeaturesUnsupported IP Features
The following list of IP constraints either has no driver support or has not yet been verified to work in any existing technical reference design:
Streaming Video Format Support: YUV 4:2:0, YUV 4:4:4
Memory Video Format Support: YUVX8, RGBX10, YUVX10, Y_UV8_420, YUV8, Y_UV10, Y_UV10_420, Y8, Y10
Support for 10-bit per color component on stream or memory interface
Resolutions
1. Resolutions up to
Known IssuesKnown Issues
When DMA operations are initiated by a client, the hardware is placed into "autorestart" mode. When the last buffer has been returned to the client as "completed", if the client does not supply a new read buffer location or fails to halt the driver, then the last buffer location written to will continue to be utilized by the driver. In effect, the driver will "spin" on the last location programmed.
Kernel ConfigurationKernel Configuration
The dirver must be enabled in the kernel by selecting option CONFIG_XILINX_FRMBUF
...
Device Tree ConfigurationDevice Tree Configuration
Comprehensive documentation regarding device tree configuration may be found: <linux_root>/Documentation/devicetree/bindings/dma/xilinx/xilinx_frmbuf.txt
Example:Below is a device tree example for a Framebuffer Read instance configured with 32-bit wide DMA descriptors and support for RGB8 as well as RGBX8 memory formats:
v_frmbuf_rd_0: v_frmbuf_rd@80000000 {
#dma-cells = <1>;
compatible = "xlnx,axi-frmbuf-rd-1.00.a";"xlnx,axi-frmbuf-rd-v2";
interrupt-parent = <&gic>;
interrupts = <0 92 4>;
reset-gpios = <&gpio 80 1>;
reg = <0x0 0x80000000 0x0 0x10000>;
xlnx,dma-addr-width = <32>;
xlnx,vid-formats = "bgr888","xbgr8888";

};
Implementation OverviewImplementation Overview

Video Framebuffer Read

$
0
0
...
xlnx,vid-formats = "bgr888","xbgr8888";
};
Implementation OverviewImplementation Overview
The Linux driver for Framebuffer Read implements the Linux DMA Engine interface semantics for a single channel DMA controller. Because the IP is video format aware, it has capabilities that are not fully served by the dma engine interface. As such, additional data is passed through the dma engine via the dma channel object as private data (see <linux_root>/include/linux/dma/xilinx_dma.h).
/* DRM Client Example */
#ifdef CONFIG_XILINX_FRMBUF
struct xilinx_xdma_config dma_config;
/*Consumed by frmbuf dma driver, if present*/
dma_config.fourcc = dma->format.pixelformat;
dma_config.type = XDMA_DRM;
dma->dma->private = &dma_config;
#endif
Technical Reference DesignsTechnical Reference Designs
Coming soon

Video Framebuffer Read

$
0
0
= {under.jpg}
=

{under.jpg}
=

Overview
Video Framebuffer Read IP cores are designed for video applications requiring frame buffers and is designed for high-bandwidth access between the AXI4-Stream video interface and the AXI4-interface.
...
xlnx,vid-formats = "bgr888","xbgr8888";
};
Interfacing with the Video Framebuffer Driver from DMA Clients
The Linux driver for Framebuffer Read implements the Linux DMA Engine interface semantics for a single channel DMA controller. Because the IP is video format aware, it has capabilities that are not fully served by the dma engine interface. As such, the Video Framebuffer driver exports an API interface that must be used by DMA clients in addition to the Linux DMA Engine interface for proper programming. (see <linux_root>/include/linux/dma/xilinx_frmbuf.h).
The general steps for preparing DMA to read to a specific memory buffer:
1. Using the Video Framebuffer API, configure the DMA device with the expected memory format for read
2. Prepare an interleaved template describing the buffer location (note: see section DMA Interleaved Template Requirements below for more details)
3. Pass the interleaved template to the DMA device using the Linux DMA Engine interface
4. With the DMA descriptor which is returned from step 3, add a callback and then submit to the DMA device via the DMA Engine interface
5. Start the DMA read operation
6. Terminate DMA read operation when frame processing deemed complete by client
/* Abstract DRM Client Code Example */
struct dma_chan *frmbuf_dma = to_frmbuf_dma_chan(xdev);
struct dma_interleaved_template dma_tmplt;
dma_addr_t addr = xvmixer_drm_fb_get_gem_obj(drm_framebuff, 0);
u32 flags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK;
/* Step 1 – Configure the dma channel to read out packed RGB */
xilinx_xdma_drm_config(frmbuf_dma, DRM_FORMAT_BGR888);
/* Step 2 – Describe the buffer attributes for a 1080p frame */
dma_tmplt.dir = DMA_MEM_TO_DEV;
dma_tmplt.src_sgl = true;
dma_tmplt.dst_sgl = false;
dma_tmplt.src_start = addr;
dma_tmplt.frame_size = 1; /* single plane pixel format */
dma_tmplt.numf = 1080; /* 1920x1080 frame */
dma_tmplt.sgl[0].size = 1080;
dma_tmplt.sgl[0].icg = 0;
/* Step 3 – Submit the buffer description to the dma channel */
desc = dmaengine_prep_interleaved_dma(frmbuf_dma, &dma_tmplt, flags);
desc->callback = dma_complete;
desc->callback_param = buf;
/* Step 4 – Submit the returned and updated descriptor to the dma channel */
dmaengine_submit(desc);
/* Step 5 – Start dma to memory operation */
dma_async_issue_pending(frmbuf_dma);
/* Step 6 – Halt DMA when required frame processing completed */
dmaengine_terminate_all(frmbuf_dma);

Video Framebuffer Read

$
0
0
...
xlnx,vid-formats = "bgr888","xbgr8888";
};
...
DMA Clients
The

The
Linux driver
...
(see <linux_root>/include/linux/dma/xilinx_frmbuf.h).
The general steps for preparing DMA to read to a specific memory buffer:
1. UsingUsing the Video
...
read
2. PreparePrepare an interleaved
...
details)
3. PassPass the interleaved
...
interface
4. WithWith the DMA
...
interface
5. StartStart the DMA
...
operation
6. TerminateTerminate DMA read
/* Abstract DRM Client Code Example */
struct dma_chan *frmbuf_dma = to_frmbuf_dma_chan(xdev);
...
/* Step 4 – Submit the returned and updated descriptor to the dma channel */
dmaengine_submit(desc);
...
operation */
dma_async_issue_pending(frmbuf_dma);
/* Step 6 – Halt DMA when required frame processing completed */
dmaengine_terminate_all(frmbuf_dma);
DMA Interleaved Template Requirements
The Video Framebuffer IP supports two dma address pointers for semi-planar formats: one for luma and one for chroma. As such, data for the two planes need to be strictly contiguous which permits for alignment of plane data within a larger buffer. However, all frame data (luma and chroma) must be contained within a contiguous frame buffer and luma plane data should be arranged to come before chroma data. Note that this is not a limitation imposed by the IP but by the driver at this moment. When preparing a struct dma_interleaved_template instance to describe a semi-planar format, the following members must be filled out as follows:
linux/dmaengine.h:
struct dma_interleaved_template:
src_start = <physical address from which to start reading frame data (any offsets should be added to this value)>
src_sgl = true
dst_sgl = false
numf = <height of frame in pixels; height of luma frame for semi-planar formats>
frame_size = < 1 or 2 depending on whether this is describing a packed or semi-planar format>
sgl = <see struct data_chunk below>
struct data_chunk:
sgl[0].size = <number of bytes devoted to image data for a row>
sgl[0].icg = < number of non-data bytes within a row of image data; padding>
sgl[0].src_sgl = <the offset in bytes between the end of luma frame data to the start of chroma plane data; only needed for semi-planar formats>
Below is a code example for semi-planar YUV 422 (i.e. NV16)
/* Step 1 – Configure the dma channel to read out semi-planar YUV 422 */
xilinx_xdma_drm_config(frmbuf_dma, DRM_FORMAT_NV16);
/* Step 2 – Describe the buffer attributes for a 1080p frame */
dma_tmplt.dir = DMA_MEM_TO_DEV;
dma_tmplt.src_sgl = true;
dma_tmplt.dst_sgl = false;
dma_tmplt.src_start = luma_addr;
dma_tmplt.frame_size = 2; /* two plane pixel format */
dma_tmplt.numf = 1080; /* height of luma frame */
dma_tmplt.sgl[0].size = 1080;
dma_tmplt.sgl[0].icg = 0;
frame_height = dma_tmplt.numf;
stride = dma_tmplt.sgl[0].size + dma_tmplt.sgl[0].icg;
dma_tmplt.sql[0].src_icg = chroma_addr – luma_addr – (frame_height * stride);
Driver Operation
The Framebuffer driver manages buffer descriptors in software keeping them in one of four possible states in the following order:
1. pending
2. staged
3. active
4. done
When a DMA client calls dma_commit(), the buffer descriptor is placed in the driver’s “pending” queue. Multiple buffers can be queued in this manner by the DMA client before proceeding to the next step (see step 4 of Interfacing with the Video Framebuffer Driver from DMA Clients). When dma_async_issue_pending() is called (step 5), the driver begins processing all queued buffers on the “pending” list. A buffer is plucked from the pending list and then stored as “staged”. At this moment, driver programs the registers with data provided within the “staged” buffer descriptor. During normal processing (i.e. all frames except the first frame*), these values will not become active until the currently processed frame completes. As such, there is a one-frame delay between programming and the actual writing data to memory. Hence the term “staged” to describe this part of the buffer lifecycle. When the currently active frame completed, the buffer descriptor is classified as “active” in the driver. At this point, a new descriptor is plucked from the pending list and this new buffer is marked as “staged” with its values programmed into the IP registers as described earlier. The buffer marked “active” represents the data currently being read from memory. Other than being held in the “active” state, no other action is taken with the buffer. When the active frame completes, it is moved to the “done” list. The driver utilizes a tasklet which is called at the end of the frame interrupt handler. The tasklet will process any buffer descriptors on the done list by removing them from the list and calling any callback the client has linked to the descriptor.
This completes the lifecycle of a buffer descriptor. As can be seen, with four possible states, it is best to allocate at least four buffers to maintain consistent frame processing. Fewer buffers will result in gaps within the pipeline and result in frame data within a given buffer being read one or more times (depending on how few buffers are queued and the number of resulting gaps in the driver’s buffer pipeline).
&#42; Note: normally, registers programmed while the IP is running will not take effect until the next frame. The very first frame, however, is an exception: the IP is not yet running and, as such, the values take effect immediately. Nevertheless, there is no additional special treatment given the first frame buffer. As such, it will be read from, in effect, twice.

Video Framebuffer Read

$
0
0
...
Kernel ConfigurationKernel Configuration
The dirver must be enabled in the kernel by selecting option CONFIG_XILINX_FRMBUF
{kernek_config.png} kernek_config.png
Device Tree ConfigurationDevice Tree Configuration
Comprehensive documentation regarding device tree configuration may be found: <linux_root>/Documentation/devicetree/bindings/dma/xilinx/xilinx_frmbuf.txt
...
When a DMA client calls dma_commit(), the buffer descriptor is placed in the driver’s “pending” queue. Multiple buffers can be queued in this manner by the DMA client before proceeding to the next step (see step 4 of Interfacing with the Video Framebuffer Driver from DMA Clients). When dma_async_issue_pending() is called (step 5), the driver begins processing all queued buffers on the “pending” list. A buffer is plucked from the pending list and then stored as “staged”. At this moment, driver programs the registers with data provided within the “staged” buffer descriptor. During normal processing (i.e. all frames except the first frame*), these values will not become active until the currently processed frame completes. As such, there is a one-frame delay between programming and the actual writing data to memory. Hence the term “staged” to describe this part of the buffer lifecycle. When the currently active frame completed, the buffer descriptor is classified as “active” in the driver. At this point, a new descriptor is plucked from the pending list and this new buffer is marked as “staged” with its values programmed into the IP registers as described earlier. The buffer marked “active” represents the data currently being read from memory. Other than being held in the “active” state, no other action is taken with the buffer. When the active frame completes, it is moved to the “done” list. The driver utilizes a tasklet which is called at the end of the frame interrupt handler. The tasklet will process any buffer descriptors on the done list by removing them from the list and calling any callback the client has linked to the descriptor.
This completes the lifecycle of a buffer descriptor. As can be seen, with four possible states, it is best to allocate at least four buffers to maintain consistent frame processing. Fewer buffers will result in gaps within the pipeline and result in frame data within a given buffer being read one or more times (depending on how few buffers are queued and the number of resulting gaps in the driver’s buffer pipeline).
&#42; Note:Note: normally, registers
...
effect, twice.


Video_Mixer

$
0
0

Overview
...
Video Mixer (v1.0).(v2.0). The Video
{DRM_Impl_Diagram_v2.png}
Location
...
Linux kernel:
https://github.com/Xilinx/linux-xlnx/tree/2017.1_video_ea
<TBD>
Supported IP Features
...
performed (see below):
Video
below).
Note that the Mixer (v1.0) driver was made available in a special branch for 2017.1 and 2017.2 and that Mixer v2.0 is only available in 2017.3 (wherein support for Mixer v1.0 has been removed):
IP Feature
2017.1/2017.2
2017.3
Output
Stream Output Formats: YUV 4:2:2, RGB
RGB, YUV422
RGB

Samples per Clock: 2Clock
2

Maximum Data Width: 8Width
8

Maximum Number of Columns: 3840Columns
3840

Maximum Number of Rows: 2160Rows
2160

Number of Layers: up to 8Layers
8

Layer Video Formats: RBB8,Formats
RGB8,
RGBX8, YUYV8,
...
Y_UV8, Y_UV8_420
[2017.1/2 list +] YUV8, YUVX8, YUVA8, Y8, UYVY8

Layer Alpha
Yes
Layer Scaling
LayerYes
Layer
Interface Type: memory
Memory

Logo Layer
LogoYes
Logo Layer
per Pixel Alpha
Yes

Unsupported IP Features
The following list of IP constraints either has no driver support or has not yet been verified to work in any existing technical reference design:

Video_Mixer

$
0
0
...
Unsupported IP Features
The following list of IP constraints either has no driver support or has not yet been verified to work in any existing technical reference design:
Video1. Video Stream Output
...
YUV 4:4:4, YUV 4:2:2, YUV 4:2:0
Maximum

2. Maximum
Data Width:
...
12, 16
Samples

3. Samples
per Clock: 1, 4
Layer

4. Layer
Video Formats: YUV8, YUVX8, YUVA8, RGBX10, YUVX10,
...
Y_UV10, Y_UV10_420, Y8, Y10
Layer

5. Layer
Interface Type: streaming
Logo

6. Logo
Transparency Color
Known Issues
Only DRM Encoder drivers implementing the encoder slave interface are supported. The DRM bridge interface is not yet supported.

XVMixer_Kernel_Config.png

Video_Mixer

$
0
0
...
Assign a layer of the mixer that is configured to read from some form of RGB in memory to be the DRM primary plane (see DRM Implementation Overview below)
Kernel Configuration
...
be enabled: CONFIG_DRM_XILINX=[y|m]
{kernel_config_mixer.png}
CONFIG_DRM_XILINX_XVMIXER=[y|m]
{XVMixer_Kernel_Config.png}

Device Tree Configuration
Comprehensive documentation may be found within the kernel branch under:
...
These properties, if described in the device tree, will be represented as DRM plane properties. To understand more about these capabilities, please refer to the Video Mixer Product Guide [PG243].
Additionally, the Video Mixer supports generation of solid background color when either the AXI streaming input is not connected or the layer is otherwise disabled. On initialization, this color is programmed to default to blue. The color may be configured using a value representing packed RGB little-endian format via the DRM plane property bg_color. This property is attached to the primary plane.
Technical Reference Designs
Coming Soon
code
code
Related Links
Title 1 & Link 1
Title 1 & Link 1

Video_Mixer

$
0
0
= {under.jpg}
=

Overview
The Linux Video Mixer driver is an early access DRM kernel driver designed to provide support for the Xilinx LogiCORE IP Video Mixer (v2.0). The Video Mixer is a configurable IP core than can blend up to eight video layers in addition to an optional logo layer into a single output video stream.
Viewing all 11776 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>