Multiple Description Video Coding over Multiple Path Routing Networks
视频编码
视频编码多媒体数据量大的特点给多媒体存储和传输带来了很大的障碍,多媒体数字压缩技术的出现使多媒体存储和传输成为可行。
压缩编码技术主要利用了数据之间的冗余、人类的心理感知的冗余等原理,使人们在降低多媒体数据大小的情况下,还能够获得很好的音视频质量。
视频编码属于压缩编码,它将原始视频进行编码从而获得一定压缩比和质量的编码后视频。
目前视频编码标准主要有MPEG-1、MPEG-2、MPEG-4,以及可视电话会议电视的H.261、H.264等等,采用的一些压缩技术有分层编码、多描述编码等等。
⏹MPEG-4标准与编码器XVIDMEPG-4的目标是针对极低码率(<64kbps),这是视频压缩标准的最后一个比特率范围。
MPEG-4与MPEG-1、MPEG-2的最根本区别是,MPEG-4是基于内容的压缩编码方法,它将一幅图像按内容分割成子块,将感兴趣的物体从场景中截取出来,进行编码处理,同时基于内容或物体截取的子块内信息相关性强,可以产生高压缩比效果。
另外,基于物体的子块,其运动的估计和表示就有可能使用物体的刚性运动或非刚性运动模型来描述,它比基于宏块的描述要高效的多。
MPEG-4具有高压缩性、基于内容交互以及基于内容分级扩展,具有基于内容方式表示的视频数据。
它引入了视频物体(VO)和视频物体平面(VO Plane)等概念来实现基于内容表示。
基于内容分级扩展使用了分层可扩展和精细可扩展编码FGSC技术,它将视频分为基本层和增强层,在基本码率之上的任何带宽增加都可以得到视频质量的改善,这对适应网络状态随时变化的特性十分有益。
Xvid是一种视频编解码器(codec),它是一款开放源代码的MPEG-4视频编解码器,创建于2001年,通过GPL协议发布。
Xvid关注MPEG-4视频压缩,早期的Xvid version0.9x版本实现了MPEG-4 simple profile(SP)的编解码,而在1.0版本中引入了MEPG-4 的advanced simple profile(ASP),其中包括了所有高级编码工具,如1/4像素运动补偿和GMC等等。
机顶盒与IPTV业务运营平台接口技术规范V2.2(EPG部分)
STB
EPG 服务系统
a)HTTP GET 请求
b)HTTP 响应
6.1.2.
图 7-1-1-1 机顶盒访问 EPG 首页流程图
EPG 首页请求
承载协议:HTTP GET
接口方向:机顶盒–〉EPG 服务系统
接口地址:http://EPGDomain
接口功能:机顶盒向 EPG 服务系统请求 EPG 首页
可扩展标记语言 XML 数据定义文件
5. 机顶盒与 IPTV 业务运营平台接口框架 5.1.机顶盒与 IPTV 业务运营平台接口描述图
机顶盒与 IPTV 业务运营平台有以下逻辑接口: a).与业务管理平台的接口(S1) b).与 EPG 服务系统的接口(S2) c).与增值业务平台的接口(S3) d).与 TS 内容分发系统的接口(S4-T) e).与 ISMA 内容分发系统的接口(S4-I) f).与 DRM 系统的接口(C4) g).与通信服务系统的接口(S5) h).与终端管理系统的接口(S6) 所有接口在系统中的位置,如图 5-1-1 所示:
机顶盒的 MAC 地址,格 String
17
式为:xx:xx:xx:xx:xx:xx
O M M
O
http://EPGDomain?UserID=1234567&UserGroupNMB=us010018&E
PGGroupNMB=sh001018&STBID=011010000021E030002100300004C7E7&
7
PDF 文件使用 "pdfFactory Pro" 试用版本创建
机顶盒通过 S6 接口与终端管理系统交互,完成终端管理、软件升 级、性能监测等功能
Hikvision iDS-2VS435-F840-EY(T5) 4MP 40× Network I
iDS-2VS435-F840-EY(T5)4 MP 40 × Network IR Traffic PTZ CameraHikvision iDS-2VS435-F840-EY(T5) 4MP 40× Network IR Speed Dome adopts 1/1.8" progressive scan CMOS chip. With the 40 × optical zoom lens, the camera offers more details over expansive areas. The network IR traffic PTZ camera features complete traffic violation enforcement functions. Detection, capturing, storage and transmission of traffic violation events are supported.⏹High quality imaging with 4 MP resolution⏹Excellent low-light performance with DarkFighter technology⏹40 × optical zoom, 16 × digital zoom⏹140 dB WDR, 3D DNR, HLC, BLC, EIS, defog⏹400 m IR distance⏹Efficient H.265+/H.265 compression technology⏹Multiple violations supported: illegal parking detection, reverse driving detection, over lane line detection, illegal lane change detection, vehicle on non-motor vehicle lane, U-turning detection⏹Water and dust resistant (IP67)⏹The illegal parking detection distance is 300 m inmulti-scene patrol.⏹DORIThe DORI (detect, observe, recognize, identify) distance gives the general idea of the camera ability to distinguish persons or objects within its field of view.It is calculated based on the camera sensor specification and the criteria given by EN 62676-4: 2015.DORI Detect Observe Recognize IdentifyDefinition25 px/m63 px/m125 px/m250 px/m Distance (Tele)2965.5 m (9729.3 ft.)1176.8 m (3860.9 ft.)604.1 m (1982.0 ft.)302.1 m (991.1 ft.)⏹SpecificationCameraImage Sensor 1/1.8" Progressive Scan CMOSMax. Resolution 2560 × 1440Min. Illumination Color: 0.001 Lux @ (F1.2, AGC ON), B/W: 0.0005 Lux @ (F1.2, AGC ON), 0 Lux with IR Shutter Speed 1/1 s to 1/30000 sDay &Night IR cut filterZoom 40 × optical, 16 × digitalSlow Shutter YesLensFocal Length 6 to 240 mmFOV Horizontal field of view: 56.6° to 1.8°, vertical field of view: 33.7° to 1.0°, diagonal field of view: 63.4° to 2.0°Focus Auto, semi-auto, manualAperture Max. F1.2Zoom Speed Approx. 5.4 sIlluminatorSupplement Light Type IRSupplement Light Range IR distance: up to 400 mSmart Supplement Light YesPTZMovement Range (Pan) 360° endlessMovement Range (Tilt) -20° to 90°, auto flipPan Speed Pan speed: configurable from 0.1° to 210°/s, preset speed: 280°/s Tilt Speed Tilt speed: configurable from 0.1° to 150°/s, preset speed 250°/s Proportional Pan YesPresets 300Preset Freezing YesPatrol Scan 8 patrols, up to 32 presets for each patrolPattern Scan 4 pattern scans, record time over 10 minutes for each scanPark Action Preset, pattern scan, patrol scan, auto scan, tilt scan, random scan, frame scan, panorama scan3D Positioning Yes PTZ Status Display YesScheduled Task Preset, pattern scan, patrol scan, auto scan, tilt scan, random scan, frame scan, dome reboot, dome adjust, aux output, panorama scanPower-off Memory Yes VideoMain Stream 50 Hz: 25 fps (2560 × 1440, 1920 × 1080, 1280 × 960, 1280 × 720) 60 Hz: 30 fps (2560 × 1440, 1920 × 1080, 1280 × 960, 1280 × 720)Sub-Stream 50 Hz: 25 fps (704 × 576, 640 × 480, 352 × 288) 60 Hz: 30 fps (704 × 480, 640 × 480, 352 × 240)Third Stream 50 Hz: 25 fps (1920 × 1080, 1280 × 960, 1280 × 720, 704 × 576, 640 × 480, 352 × 288) 60 Hz: 30 fps (1920 × 1080, 1280 × 960, 1280 × 720, 704 × 480, 640 × 480, 352 × 240)Video Compression Main stream: H.265+/H.265/H.264+/H.264, Sub-stream: H.265/H.264/MJPEG,Third stream: H.265/H.264/MJPEGVideo Bit Rate 32 Kbps to 16 MbpsH.264 Type Baseline profile, Main profile, High profile H.265 Type Main profileScalable Video Coding (SVC) H.264 and H.265 encodingRegion of Interest (ROI) 8 fixed regions for each streamAudioAudio Compression G.711, G.722.1, G.726, MP2L2, PCM, AAC-LCAudio Bit Rate 64 Kbps (G.711), 16 Kbps (G.722.1), 16 Kbps (G.726), 32 to 192 Kbps (MP2L2), 16 to 64Kbps (AAC-LC)NetworkProtocols TCP/IP, ICMP, HTTP, HTTPS, FTP, DHCP, DNS, DDNS, RTP, RTSP, RTCP, PPPoE, NTP, UPnP, SMTP, SNMP, IGMP, 802.1X, QoS, IPv4/IPv6, UDP, BonjourSimultaneous Live View Up to 20 channelsAPI Open Network Video Interface (Profile S, Profile G, Profile T), ISAPI, SDK, ISUP User/Host Up to 32 users. 3 user levels: administrator, operator, and userSecurity Password protection, complicated password, HTTPS encryption, 802.1X authentication (EAP-TLS, EAP-LEAP, EAP-MD5), watermark, IP address filter, basic and digest authentication for HTTP/HTTPS, WSSE and digest authentication for Open Network Video Interface, RTP/RTSP over HTTPS, control timeout settings, security audit log, TLS 1.3, host authentication (MAC address)Network Storage NAS (NFS, SMB/CIFS), auto network replenishment (ANR) Client iVMS-4200, HikCentral Pro, Hik-ConnectWeb Browser Safari11+, Chrome57+, Firefox52+, IE11ImageImage Parameters Switch YesImage Settings Saturation, brightness, contrast, sharpness, gain, and white balance adjustable by client software or web browserDay/Night Switch Day, night, auto, scheduleWide Dynamic Range (WDR) 140 dBSNR ≥ 52 dBDefog Optical defog, Digital defogImage Stabilization EIS (Built-in gyroscope to improve EIS performance)Image Enhancement BLC, HLC, 3D DNRPrivacy Mask 24 programmable polygon privacy masks, mask color or mosaic configurableRegional Focus YesRegional Exposure YesSupplement DetectionSatellite Positioning NoGyroscope YesCompass NoInterfaceVideo Output CVBS: 1.0 V[p-p]/75 Ω, PAL/NTSC, BNC connectorEthernet Interface 1 RJ45 10M/100M self-adaptive Ethernet portOn-board Storage Built-in memory card slot, support microSD/microSDHC/microSDXC card, up to 256 GBAudio 1 input (line in), max. input amplitude: 2-2.4 vpp, input impedance: 1 KΩ ± 10%, 1 output (line out), line level, output impedance: 600 ΩAlarm 7 input(s), 2 output(s)RS-485 1 RS-485 (Half duplex, HIKVISION, Pelco-P, Pelco-D, self-adaptive)Reset YesEventBasic Event Motion detection, video tampering alarm, exception, alarm input and outputAlarm Linkage Upload to FTP/NAS/memory card, notify surveillance center, send email, trigger alarm output, trigger recording, trigger capture, and PTZ actions (such as preset, patrol scan, pattern scan)Road Traffic and Vehicle DetectionIllegal Parking Illegal parking detection, reverse driving detection, over lane line detection, illegal lane change detection, vehicle on non-motor vehicle lane, U-turning detectionGeneralPower 24 VDC ± 25%, max. 62 WDimension Ø266.6 mm × 410 mm (Ø10.50" × 16.14")Weight Approx. 8 kg (17.64 lb.)Material ADC12Operating Condition -40 °C to 70 °C (-40 °F to 158 °F). Humidity 95% or less (non-condensing) Vandal-proof Alarm YesHeater YesWiper YesDe-icing NoDemist NoLanguage 33 languages: English, Russian, Estonian, Bulgarian, Hungarian, Greek, German, Italian, Czech, Slovak, French, Polish, Dutch, Portuguese, Spanish, Romanian, Danish, Swedish, Norwegian, Finnish, Croatian, Slovenian, Serbian, Turkish, Korean, Traditional Chinese, Thai, Vietnamese, Japanese, Latvian, Lithuanian, Portuguese (Brazil), UkrainianApprovalEMC FCC (47 CFR Part 15, Subpart B), CE-EMC (EN 55032: 2015, EN 61000-3-2: 2019, EN 61000-3-3: 2013 + A1: 2019, EN 50130-4: 2011 + A1: 2014), KC (KN 32: 2015, KN 35: 2015), RCM (AS/NZS CISPR 32: 2015), IC (ICES-003: Issue 7)Safety UL (UL 62368-1), CB (IEC 62368-1: 2014 + A11), CE-LVD (EN 62368-1: 2014/A11: 2017), BIS (IS 13252 (Part 1): 2010/IEC 60950-1: 2005), LOA (IEC/EN 60950-1)Environment CE-RoHS (2011/65/EU), WEEE (2012/19/EU), Reach (Regulation (EC) No 1907/2006)ProtectionIP67 (IEC 60529-2013), IK10 (IEC 62262:2002), TVS 6K V lightning protection, surge protection and voltage transient protection⏹Typical ApplicationHikvision products are classified into three levels according to their anti-corrosion performance. Refer to the following description to choose for your using environment.This model has MODERATE PROTECTION.LevelDescriptionTop-level protectionHikvision products at this level are equipped for use in areas where professional anti-corrosion protection is a must. Typical application scenarios include coastlines, docks, chemical plants, and more.Moderate protectionHikvision products at this level are equipped for use in areas with moderate anti-corrosion demands. Typical application scenarios include coastal areas about 2 kilometers (1.24 miles) away from coastlines, as well as areas affected by acid rain.No specific protection Hikvision products at this level are equipped for use in areas where no specific anti-corrosion protection is needed.⏹Dimension⏹Available Model iDS-2VS435-F840-EY(T5)⏹Accessory⏹IncludedDS-1681ZJ DS-1681ZJ-2 ⏹OptionalDS-1604ZJ-BOX-Corner-Y DS-1604ZJ-BOX-Y。
诺瓦科技LED视频处理器VP200U规格书英文版
Specifications Video Processor VP200URev1.0.0 NS160100098Xi ’an N o v a St ar T ec hC o., L t d.OverviewVP200U is a video processor developed for display system of large-size LED displays. With the leading-edge chips of the industry used and 12-bit digital processing inside, it will bring us clearer images and richer colors.VP200U has adopted technologies such as Faroudja® DCDI de -interlacing video processing, Real Color® real color image processing, Faroudja®TureLife™ video image enhancement, etc. to perfect the display of video image.The maximum output resolution of a single unit is up to 2304x1152 and it allows to customize output resolution. VP200U has multiple special switching effects like signal cut and fade. The size and position of PIP can be set as you wish and AIAO (Any In Any Out) is supported.In addition, VP200U supports USB drive play with the features of automatic detection and plug-and-play, which has made it much easier and more flexible to use.Features 1) VP200U has a full range of video input interfaces, including AV ×2, VGA ×1, DVI ×1, HDMI ×1 and USB ×1.2) It will automatically detect and play files after USB drive is plugged, that is, plugand play.3) VP200U is a new product of NovaStar's video processor series, which is powerfulin image processing, professional in image control and friendly in user interface. 4) VP200U has provided switching effects such as seamless cut and fade to enhanceXi ’a n N o v a St ar T ec hC o., L t d.and present pictures with professional quality.5) The position and size of PIP are adjustable and can be controlled as you wish. 6) With an intuitive LCD interface and key indicator lights to simplify system control. 7) VP200U supports high-bit level video input, 10bit/8bit.8) VP200U supports custom output resolution and maximum video outputresolution is 2304x1152@60Hz.Dimensions(mm)Xi ’an N o v a St ar T ec hC o., L t d.AppearanceFront Panel: PIP closed;: PIP opened, Channel1 picture is moved to the top layer;: PIP opened, Channel2 picture is moved to the top layer;: Part display is enabled and the size of output image is the same as window size;: :: : : : : : Xv aRear PanelSpecificationsAppendix 1: Conflict list of PIP sourcesAppendix 2: Relevant parameters of USB interfacee c h。
The H.264 AVC Advanced Video Coding Standard-Overview and Introduction to the Fidelity Range Extensi
Presented at the SPIE Conference on Applications of Digital Image Processing XXVII Special Session on Advances in the New Emerging Standard: H.264/AVC, August, 2004The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range ExtensionsGary J. Sullivan*, Pankaj Topiwala†, and Ajay Luthra‡*Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 † FastVDO LLC, 7150 Riverwood Dr., Columbia, MD 21046 ‡ Motorola Inc., BCS, 6420 Sequence Dr., San Diego, CA 92121ABSTRACTH.264/MPEG-4 AVC is the latest international video coding standard. It was jointly developed by the Video Coding Experts Group (VCEG) of the ITU-T and the Moving Picture Experts Group (MPEG) of ISO/IEC. It uses state-of-the-art coding tools and provides enhanced coding efficiency for a wide range of applications, including video telephony, video conferencing, TV, storage (DVD and/or hard disk based, especially high-definition DVD), streaming video, digital video authoring, digital cinema, and many others. The work on a new set of extensions to this standard has recently been completed. These extensions, known as the Fidelity Range Extensions (FRExt), provide a number of enhanced capabilities relative to the base specification as approved in the Spring of 2003. In this paper, an overview of this standard is provided, including the highlights of the capabilities of the new FRExt features. Some comparisons with the existing MPEG-2 and MPEG-4 Part 2 standards are also provided. Keywords: Advanced Video Coding (AVC), Digital Video Compression, H.263, H.264, JVT, MPEG, MPEG-2, MPEG-4, MPEG-4 part 10, VCEG.1. INTRODUCTIONSince the early 1990s, when the technology was in its infancy, international video coding standards – chronologically, H.261 [1], MPEG-1 [2], MPEG-2 / H.262 [3], H.263 [4], and MPEG-4 (Part 2) [5] – have been the engines behind the commercial success of digital video compression. They have played pivotal roles in spreading the technology by providing the power of interoperability among products developed by different manufacturers, while at the same time allowing enough flexibility for ingenuity in optimizing and molding the technology to fit a given application and making the cost-performance trade-offs best suited to particular requirements. They have provided much-needed assurance to the content creators that their content will run everywhere and they do not have to create and manage multiple copies of the same content to match the products of different manufacturers. They have allowed the economy of scale to allow steep reduction in cost for the masses to be able to afford the technology. They have nurtured open interactions among experts from different companies to promote innovation and to keep pace with the implementation technology and the needs of the applications. ITU-T H.264 / MPEG-4 (Part 10) Advanced Video Coding (commonly referred as H.264/AVC) [6] is the newest entry in the series of international video coding standards. It is currently the most powerful and state-of-the-art standard, and was developed by a Joint Video Team (JVT) consisting of experts from ITU-T’s Video Coding Experts Group (VCEG) and ISO/IEC’s Moving Picture Experts Group (MPEG). As has been the case with past standards, its design provides the most current balance between the coding efficiency, implementation complexity, and cost – based on state of VLSI design technology (CPU's, DSP's, ASIC's, FPGA's, etc.). In the process, a standard was created that improved coding efficiency by a factor of at least about two (on average) over MPEG-2 – the most widely used video coding standard today – while keeping the cost within an acceptable range. In July, 2004, a new amendment was added to this standard, called the Fidelity Range Extensions (FRExt, Amendment 1), which demonstrates even further coding efficiency against MPEG-2, potentially by as much as 3:1 for some key applications. In this paper, we develop an outline of the first version of the H.264/AVC standard, and provide an introduction to the newly-minted extension, which, for reasons we explain, is already receiving wide attention in the industry.1.1. H.264/AVC History H.264/AVC was developed over a period of about four years. The roots of this standard lie in the ITU-T’s H.26L project initiated by the Video Coding Experts Group (VCEG), which issued a Call for Proposals (CfP) in early 1998 and created a first draft design for its new standard in August of 1999. In 2001, when ISO/IEC’s Moving Pictures Experts Group (MPEG) had finished development of its most recent video coding standard, known as MPEG-4 Part 2, it issued a similar CfP to invite new contributions to further improve the coding efficiency beyond what was achieved on that project. VCEG chose to provide its draft design in response to MPEG's CfP and proposed joining forces to complete the work. Several other proposals were also submitted and were tested by MPEG as well. As a result of those tests, MPEG made the following conclusions that affirmed the design choices made by VCEG for H.26L: ♦ The motion compensated Discrete Cosine Transform (DCT) structure was superior to others, implying there was no need, at least at that stage, to make fundamental structural changes for the next generation of coding standard. ♦ Some video coding tools that had been excluded in the past (for MPEG-2, H.263, or MPEG-4 Part 2) due to their complexity (hence implementation cost) could be re-examined for inclusion in the next standard. The VLSI technology had advanced significantly since the development of those standards and this had significantly reduced the implementation cost of those coding tools. (This was not a "blank check" for compression at all costs, as a number of compromises were still necessary for complexity reasons, but it was a recognition that some of the complexity constraints that governed past work could be re-examined.) ♦ To allow maximum freedom of improving the coding efficiency, the syntax of the new coding standard could not be backward compatible with prior standards. ♦ ITU-T’s H.26L was a top-performing proposal, and most others that showed good performance in MPEG had also been based on H.26L (as it had become well-known as an advance in technology by that time). Therefore, to allow speedy progress, ITU-T and ISO/IEC agreed to join forces together to jointly develop the next generation of video coding standard and use H.26L as the starting point. A Joint Video Team (JVT), consisting of experts from VCEG and MPEG, was formed in December, 2001, with the goal of completing the technical development of the standard by 2003. ITU-T planned to adopt the standard under the name of ITU-T H.264, and ISO/IEC planned to adopt the standard as MPEG-4 Part 10 Advanced Video Coding (AVC), in the MPEG-4 suite of standards formally designated as ISO/IEC 14496. As an unwanted byproduct, this standard gets referred to by at least six different names – H.264, H.26L, ISO/IEC 14496-10, JVT, MPEG-4 AVC and MPEG-4 Part 10. In this paper we refer it as H.264/AVC as a balance between the names used in the two organizations. With the wide breadth of applications considered by the two organizations, the application focus for the work was correspondingly broad – from video conferencing to entertainment (broadcasting over cable, satellite, terrestrial, cable modem, DSL etc.; storage on DVDs and hard disks; video on demand etc.) to streaming video, surveillance and military applications, and digital cinema. Three basic feature sets called profiles were established to address these application domains: the Baseline, Main, and Extended profiles. The Baseline profile was designed to minimize complexity and provide high robustness and flexibility for use over a broad range of network environments and conditions; the Main profile was designed with an emphasis on compression coding efficiency capability; and the Extended profile was designed to combine the robustness of the Baseline profile with a higher degree of coding efficiency and greater network robustness and to add enhanced modes useful for special "trick uses" for such applications as flexible video streaming. 1.2. The FRExt Amendment While having a broad range of applications, the initial H.264/AVC standard (as it was completed in May of 2003), was primarily focused on "entertainment-quality" video, based on 8-bits/sample, and 4:2:0 chroma sampling. Given its time constraints, it did not include support for use in the most demanding professional environments, and the design had not been focused on the highest video resolutions. For applications such as content-contribution, content-distribution, and studio editing and post-processing, it may be necessary to ♦ Use more than 8 bits per sample of source video accuracy ♦ Use higher resolution for color representation than what is typical in consumer applications (i.e., to use 4:2:2 or 4:4:4 sampling as opposed to 4:2:0 chroma sampling format)-2-♦ ♦ ♦ ♦ ♦ ♦Perform source editing functions such as alpha blending (a process for blending of multiple video scenes, best known for use in weather reporting where it is used to super-impose video of a newscaster over video of a map or weather-radar scene) Use very high bit rates Use very high resolution Achieve very high fidelity – even representing some parts of the video losslessly Avoid color-space transformation rounding error Use RGB color representationTo address the needs of these most-demanding applications, a continuation of the joint project was launched to add new extensions to the capabilities of the original standard. This effort took about one year to complete – starting with a first draft in May of 2003, the final design decisions were completed in July of 2004, and the editing period will be completed in August or September of 2004. These extensions, originally known as the "professional" extensions, were eventually renamed as the "fidelity range extensions" (FRExt) to better indicate the spirit of the extensions. In the process of designing the FRExt amendment, the JVT was able to go back and re-examine several prior technical proposals that had not been included in the initial standard due to scheduling constraints, uncertainty about benefits, or the original scope of intended applications. With the additional time afforded by the extension project, it was possible to include some of those features in the new extensions. Specifically, these included: ♦ Supporting an adaptive block-size for the residual spatial frequency transform, ♦ Supporting encoder-specified perceptual-based quantization scaling matrices, and ♦ Supporting efficient lossless representation of specific regions in video content. The FRExt project produced a suite of four new profiles collectively called the High profiles: ♦ The High profile (HP), supporting 8-bit video with 4:2:0 sampling, addressing high-end consumer use and other applications using high-resolution video without a need for extended chroma formats or extended sample accuracy ♦ The High 10 profile (Hi10P), supporting 4:2:0 video with up to 10 bits of representation accuracy per sample ♦ The High 4:2:2 profile (H422P), supporting up to 4:2:2 chroma sampling and up to 10 bits per sample, and ♦ The High 4:4:4 profile (H444P), supporting up to 4:4:4 chroma sampling, up to 12 bits per sample, and additionally supporting efficient lossless region coding and an integer residual color transform for coding RGB video while avoiding color-space transformation error All of these profiles support all features of the prior Main profile, and additionally support an adaptive transform blocksize and perceptual quantization scaling matrices. Initial industry feedback has been dramatic in its rapid embrace of FRExt. The High profile appears certain to be incorporated into several important near-term application specifications, particularly including ♦ The HD-DVD specification of the DVD Forum ♦ The BD-ROM Video specification of the Blu-ray Disc Association, and ♦ The DVB (digital video broadcast) standards for European broadcast television Several other environments may soon embrace it as well (e.g., the Advanced Television Systems Committee (ATSC) in the U.S., and various designs for satellite and cable television). Indeed, it appears that the High profile may rapidly overtake the Main profile in terms of dominant near-term industry implementation interest. This is because the High profile adds more coding efficiency to what was previously defined in the Main profile, without adding a significant amount of implementation complexity.-3-2. CODING TOOLSAt a basic overview level, the coding structure of this standard is similar to that of all prior major digital video standards (H.261, MPEG-1, MPEG-2 / H.262, H.263 or MPEG-4 part 2). The architecture and the core building blocks of the encoder are shown in Fig. 1 and Fig. 2, indicating that it is also based on motion-compensated DCT-like transform coding. Each picture is compressed by partitioning it as one or more slices; each slice consists of macroblocks, which are blocks of 16x16 luma samples with corresponding chroma samples. However, each macroblock is also divided into sub-macroblock partitions for motion-compensated prediction. The prediction partitions can have seven different sizes – 16x16, 16x8, 8x16, 8x8, 8x4, 4x8 and 4x4. In past standards, motion compensation used entire macroblocks or, in the case of newer designs, 16x16 or 8x8 partitions, so the larger variety of partition shapes provides enhanced prediction accuracy. The spatial transform for the residual data is then either 8x8 (a size supported only in FRExt) or 4x4. In past major standards, the transform block size has always been 8x8, so the 4x4 block size provides an enhanced specificity in locating residual difference signals. The block size used for the spatial transform is always either the same or smaller than the block size used for prediction. The hierarchy of a video sequence, from sequence to samples1 is given by: sequence (pictures (slices (macroblocks (macroblock partitions (sub-macroblock partitions (blocks (samples)))))). In addition, there may be additional structures such as packetization schemes, channel codes, etc., which relate to the delivery of the video data, not to mention other data streams such as audio. As the video compression tools primarily work at or below the slice layer, bits associated with the slice layer and below are identified as Video Coding Layer (VCL) and bits associated with higher layers are identified as Network Abstraction Layer (NAL) data. VCL data and the highest levels of NAL data can be sent together as part of one single bitstream or can be sent separately. The NAL is designed to fit a variety of delivery frameworks (e.g., broadcast, wireless, storage media). Herein, we only discuss the VCL, which is the heart of the compression capability. While an encoder block diagram is shown in Fig. 1, the decoder conceptually works in reverse, comprising primarily an entropy decoder and the processing elements of the region shaded in Fig. 1.Input Video+Transform/ Scaling/ Quant.Scaling/ Inv .Quant./ Inv. TransformEntropy Coder+Intra (Spatial) Prediction DeblockingC o m p r e s s e d V i d e o b i t sMotion Comp. Decoded Video Motion Vector Info Motion EstimationFig. 1: High-level encoder architecture1We use the terms sample and pixel interchangeably, although sample may sometimes be more rigorously correct.-4-Prediction Spatial/Temporal2-D TransformQuantizationScanningVLC / Arithmetic Entropy CodeFig. 2: Higher-level encoder block diagramIn the first version of the standard, only the 4:2:0 chroma format (typically derived by performing an RGB-to-YCbCr color-space transformation and subsampling the chroma components by a factor of 2:1 both horizontally and vertically) and only 8 bit sample precision for luma and chroma values was supported. The FRExt amendment extended the standard to 4:2:2 and 4:4:4 chroma formats and higher than 8 bits precision, with optional support of auxiliary pictures for such purposes as alpha blending composition. The basic unit of the encoding or decoding process is the macroblock. In 4:2:0 chroma format, each macroblock consists of a 16x16 region of luma samples and two corresponding 8x8 chroma sample arrays. In a macroblock of 4:2:2 chroma format video, the chroma sample arrays are 8x16 in size; and in a macroblock of 4:4:4 chroma format video, they are 16x16 in size. Slices in a picture are compressed by using the following coding tools: ♦ "Intra" spatial (block based) prediction o Full-macroblock luma or chroma prediction – 4 modes (directions) for prediction o 8x8 (FRExt-only) or 4x4 luma prediction – 9 modes (directions) for prediction ♦ "Inter" temporal prediction – block based motion estimation and compensation o Multiple reference pictures o Reference B pictures o Arbitrary referencing order o Variable block sizes for motion compensation Seven block sizes: 16x16, 16x8, 8x16, 8x8, 8x4, 4x8 and 4x4 o 1/4-sample luma interpolation (1/4 or 1/8th-sample chroma interpolation) o Weighted prediction o Frame or Field based motion estimation for interlaced scanned video ♦ Interlaced coding features o Frame-field adaptation Picture Adaptive Frame Field (PicAFF) MacroBlock Adaptive Frame Field (MBAFF) o Field scan ♦ Lossless representation capability o Intra PCM raw sample-value macroblocks o Entropy-coded transform-bypass lossless macroblocks (FRExt-only) ♦ 8x8 (FRExt-only) or 4x4 integer inverse transform (conceptually similar to the well-known DCT) ♦ Residual color transform for efficient RGB coding without conversion loss or bit expansion (FRExt-only) ♦ Scalar quantization ♦ Encoder-specified perceptually weighted quantization scaling matrices (FRExt-only)-5-♦ ♦ ♦ ♦♦♦ ♦ ♦ ♦Logarithmic control of quantization step size as a function of quantization control parameter Deblocking filter (within the motion compensation loop) Coefficient scanning o Zig-Zag (Frame) o Field Lossless Entropy coding o Universal Variable Length Coding (UVLC) using Exp-Golomb codes o Context Adaptive VLC (CAVLC) o Context-based Adaptive Binary Arithmetic Coding (CABAC) Error Resilience Tools o Flexible Macroblock Ordering (FMO) o Arbitrary Slice Order (ASO) o Redundant Slices SP and SI synchronization pictures for streaming and other uses Various color spaces supported (YCbCr of various types, YCgCo, RGB, etc. – especially in FRExt) 4:2:0, 4:2:2 (FRExt-only), and 4:4:4 (FRExt-only) color formats Auxiliary pictures for alpha blending (FRExt-only)Of course, each slice need not use all of the above coding tools. Depending upon on the subset of coding tools used, a slice can be of I (Intra), P (Predicted), B (Bi-predicted), SP (Switching P) or SI (Switching I) type. A picture may contain different slice types, and pictures come in two basic types – reference and non-reference pictures. Reference pictures can be used as references for interframe prediction during the decoding of later pictures (in bitstream order) and non-reference pictures cannot. (It is noteworthy that, unlike in prior standards, pictures that use bi-prediction can be used as references just like pictures coded using I or P slices.) In the next section we describe the coding tools used for these different slice types. This standard is designed to perform well for both progressive-scan and interlaced-scan video. In interlaced-scan video, a frame consists of two fields – each captured at ½ the frame duration apart in time. Because the fields are captured with significant time gap, the spatial correlation among adjacent lines of a frame is reduced in the parts of picture containing moving objects. Therefore, from coding efficiency point of view, a decision needs to be made whether to compress video as one single frame or as two separate fields. H.264/AVC allows that decision to be made either independently for each pair of vertically-adjacent macroblocks or independently for each entire frame. When the decisions are made at the macroblock-pair level, this is called MacroBlock Adaptive Frame-Field (MBAFF) coding and when the decisions are made at the frame level then this is called Picture-Adaptive Frame-Field (PicAFF) coding. Notice that in MBAFF, unlike in the MPEG-2 standard, the frame or field decision is made for the vertical macroblock-pair and not for each individual macroblock. This allows retaining a 16x16 size for each macroblock and the same size for all submacroblock partitions – regardless of whether the macroblock is processed in frame or field mode and regardless of whether the mode switching is at the picture level or the macroblock-pair level. 2.1. I-slice In I-slices (and in intra macroblocks of non-I slices) pixel values are first spatially predicted from their neighboring pixel values. After spatial prediction, the residual information is transformed using a 4x4 transform or an 8x8 transform (FRExt-only) and then quantized. In FRExt, the quantization process supports encoder-specified perceptual-based quantization scaling matrices to optimize the quantization process according to the visibility of the specific frequency associated with each transform coefficient. Quantized coefficients of the transform are scanned in one of the two different ways (zig-zag or field scan) and are compressed by entropy coding using one of two methods – CAVLC or CABAC. In PicAFF operation, each field is compressed in a manner analogous to the processing of an entire frame. In MBAFF operation, if a macroblock pair is in field mode then the field neighbors are used for spatial prediction and if a macroblock pair is in frame mode, frame neighbors are used for prediction. The frame or field decision is made before applying the rest of the coding tools described below. Temporal prediction is not used in intra macroblocks, but it is for P and B macroblock types, which is the main difference between these fundamental macroblock types. We therefore review the structure of the codec for the I-slice first, and then review the key differences for P and B-slices later.-6-2.1.1. Intra Spatial Prediction To exploit spatial correlation among pixels, three basic types of intra spatial prediction are defined: ♦ Full-macroblock prediction for 16x16 luma or the corresponding chroma block size, or ♦ 8x8 luma prediction (FRExt-only), or ♦ 4x4 luma prediction. For full-macroblock prediction, the pixel values of an entire macroblock of luma or chroma data are predicted from the edge pixels of neighboring previously-decoded macroblocks (similar to what is shown in Fig. 3, but for a larger region than the 4x4 region shown in the figure). Full-macroblock prediction can be performed in one of four different ways that can be selected by the encoder for the prediction of each particular macroblock: (i) vertical, (ii) horizontal, (iii) DC and (iv) planar. For the vertical and horizontal prediction types, the pixel values of a macroblock are predicted from the pixels just above or to the left of the macroblock, respectively (like directions 0 and 1 in Fig. 3). In DC prediction (prediction type number 2, not shown in Fig. 3), the luma values of the neighboring pixels are averaged and that average value is used as predictor. In planar prediction (not shown in Fig. 3), a three-parameter curve-fitting equation is used to form a prediction block having a brightness, slope in the horizontal direction, and slope in the vertical direction that approximately matches the neighboring pixels. Full-macroblock intra prediction is used for luma in a macroblock type called the intra 16x16 macroblock type. Chroma intra prediction always operates using full-macroblock prediction. Because of differences in the size of the chroma arrays for the macroblock in different chroma formats (i.e., 8x8 chroma in 4:2:0 macroblocks, 8x16 chroma in 4:2:2 macroblocks, and 16x16 chroma in 4:4:4 macroblocks), chroma prediction is defined for three possible block sizes. The prediction type for the chroma is selected independently of the prediction type for the luma. 4x4 intra prediction for luma can be alternatively selected (on a macroblock-by-macroblock basis) by the encoder. In 4x4 spatial prediction mode, the values of each 4x4 block of luma samples are predicted from the neighboring pixels above or left of a 4x4 block, and nine different directional ways of performing the prediction can be selected by the encoder (on a 4x4 block basis) as illustrated in Fig. 3 (and including a DC prediction type numbered as mode 2, which is not shown in the figure). Each prediction direction corresponds to a particular set of spatially-dependent linear combinations of previously decoded samples for use as the prediction of each input sample. In FRExt profiles, 8x8 luma intra prediction can also be selected. 8x8 intra prediction uses basically the same concepts as 4x4 prediction, but with a prediction block size that is 8x8 rather than 4x4 and with low-pass filtering of the predictor to improve prediction performance.M A B C D E F G H8 1 6 3 7 0 5 4I J K La e i mb f j nc g k od h l pFig. 3: Spatial prediction of a 4x4 block.-7-2.1.2. Transform and Quantization After spatial prediction, a transform is applied to decorrelate the data spatially. There are several unique features about the transform selected for this coding standard. Some of these features are listed below. ♦ It is the first video standard fundamentally based on an integer inverse transform design for its main spatial transforms, rather than using idealized trigonometric functions to define the inverse transform equations and allowing implementation-specific approximations within some specified tolerances.2 The forward transform that will typically be used for encoding is also an integer transform. A significant advantage of the use of an integer is that, with an exact integer inverse transform, there is now no possibility of a mismatch between then encoder and decoder, unlike for MPEG-2 and ordinary MPEG-4 part 2. ♦ In fact, the transform is specified so that for 8-bit input video data, it can be easily implemented using only 16-bit arithmetic, rather than the 32-bit or greater precision needed for the transform specified in prior standards. ♦ The transform (at least for the 4x4 block size supported without FRExt) is designed to be so simple that it can be implemented using just a few additions, subtractions, and bit shifts. ♦ A 4x4 transform size is supported, rather than just 8x8. Inconsistencies between neighboring blocks will thus occur at a smaller granularity, and thus tend to be less noticeable. Isolated features can be represented with greater accuracy in spatial location (reducing a phenomenon known as "ringing"). For certain hardware implementations, the small block size may also be particularly convenient. Thus, while the macroblock size remains at 16x16, these are divided up into 4x4 or 8x8 blocks, and a 4x4 or 8x8 block transformation matrix T4x4 or T8x8 is applied to every block of pixels, as given by:T4 x 41 ⎡ 1 ⎢ 2 1 =⎢ ⎢ 1 −1 ⎢ ⎣ 1 −21⎤ − 1 − 2⎥ ⎥, T 8 x8 1⎥ −1 ⎥ 2 − 1⎦ 18 8 8 ⎡ 8 ⎢ 12 10 6 3 ⎢ ⎢ 8 4 − 4 −8 ⎢ 10 − 3 − 12 − 6 =⎢ ⎢ 8 −8 −8 8 ⎢ 3 10 ⎢ 6 − 12 ⎢ 4 −8 8 −4 ⎢ ⎢ 3 −6 10 − 12 ⎣8 −3 −8 6 8 10 −48 −4 12 −8 −3 88 4 3 −8 12 −8 6− 6 − 1012 − 108⎤ − 12⎥ ⎥ 8⎥ ⎥ − 10⎥ 8⎥ ⎥ − 6⎥ 4⎥ ⎥ − 3⎥ ⎦The 4x4 transform is remarkably simple, and while the 8x8 transform (used in FRExt profiles only) is somewhat more complex, it is still remarkably simple when compared to an ordinary 8x8 IDCT. The transform T is applied to each block within the luma (16x16) and chroma (8x8, or in FRExt, 8x16 or 16x16) samples for a macroblock by segmenting the full sample block size into smaller blocks for transformation as necessary. In addition, when the 16x16 Intra prediction mode is used with the 4x4 transform, the DC coefficients of the sixteen 4x4 luma blocks in the macroblock are further selected and transformed by a secondary Hadamard transform using the H4x4 matrix shown below (note the basic similarity of T4x4 and H4x4). The DC coefficients of the 4x4 blocks of chroma samples in all macroblock types are transformed using a secondary Hadamard transform as well. For 4:2:0 video, this requires a 2x2 chroma DC transformation specified by the Hadamard matrix H2x2 (below); for 4:4:4, the chroma DC uses the same 4x4 Hadamard transformation as used for luma in 16x16 intra mode; and for 4:2:2 video, the chroma DC transformation uses the matrices H2x2 and H4x4 to perform a 2x4 chroma DC secondary transformation.2MPEG-4 part 2 and JPEG2000 had previously included integer wavelet transforms. But JPEG2000 is an image coding standard without support for interframe prediction, and in MPEG-4, the integer transforms are used only rarely for what is called texture coding (somewhat equivalent to the usual I-frame coding, but not found in most implementations of MPEG-4), and the main transform used for nearly all video data was still specified as an ideal 8x8 IDCT with rounding tolerances. The integer transform concept had also been previously applied in H.263 Annex W, but only as an after-thefact patch to a prior specification in terms of the 8x8 floating point IDCT.-8-。
数字电视卫星传输信道编码和调制规范
数字电视卫星传输信道编码和调制规范1 范围本文件规定了在固定卫星业务(FSS)波段中,用于卫星数字多路节目电视(包括标准清晰度电视、高清晰度电视以及超高清晰度电视)业务和数字音频广播业务的一次分配的信道编码和调制系统(以下简称“系统”)。
本文件适用于固定卫星业务(FSS)波段中,卫星数字多路节目电视(包括标准清晰度电视、高清晰度电视以及超高清晰度电视)业务和数字音频广播业务的一次分配。
2 规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。
其中,注日期的引用文件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 17700—1999 卫星数字电视广播信道编码和调制标准GB/T 17975.1 信息技术运动图像及其伴音的通用编码第1部分:系统GB/T 17975.2 信息技术运动图像及其伴音的通用编码第2部分:视频ETSI EN 300 468 数字视频广播(DVB) DVB系统中的业务信息(SI)规范(Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems)ETSI EN 301 192 数字视频广播(DVB) 数据广播的DVB规范(Digital Video Broadcasting (DVB); DVB specification for data broadcasting)ETSI EN 301 195 数字视频广播(DVB) 通过全球移动通信系统(GSM)的交互信道(Digital Video Broadcasting (DVB); Interaction channel through the Global System for Mobile communications (GSM))ETSI EN 301 790 数字视频广播(DVB) 卫星分发系统的交互信道(Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems)ETSI EN 302 307-2 V1.1.1 数字视频广播(DVB) 第二代广播、交互式服务、新闻采集和其他宽带卫星应用系统的帧结构、信道编码及调制标准第2部分:S2扩展(S2X)(Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications; Part 2: S2-Extensions (S2X))ETSI ES 200 800 数字视频广播(DVB) 有线电视分配系统(CATV)的DVB交互信道(Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV))ETSI ETR 162 数字视频广播(DVB) DVB系统业务信息(SI)码的分配(Digital Video Broadcasting (DVB); Allocation of Service Information (SI) codes for DVB systems)ETSI ETS 300 801 数字视频广播(DVB) 通过公共电信交换网(PSTN)/综合业务数据网(ISDN)的交互信道(Digital Video Broadcasting (DVB); Interaction channel through Public Switched Telecommunications Network (PSTN)/ Integrated Services Digital Networks (ISDN))ETSI ETS 300 802 数字视频广播(DVB) DVB交互服务的网络自主协议(NIP)(Digital Video Broadcasting (DVB); Network-independent protocols for DVB interactive services)ETSI TR 101 154 数字视频广播(DVB) 在卫星、有线和地面广播应用中使用MPEG-2系统与视音频的实施指南(Digital Video Broadcasting (DVB); Implementation guidelines for the use of MPEG-2 Systems, Video and Audio in satellite, cable and terrestrial broadcasting applications)ETSI TR 102 376 V1.1.1 数字视频广播(DVB) 第二代广播、交互式服务、新闻采集和其他宽带卫星应用系统(DVB-S2)用户指南(Digital Video Broadcasting (DVB); User guidelines for the second generation system for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications (DVB-S2))ETSI TS 102 005 数字视频广播(DVB) 在IP协议中直接传输的DVB业务中的视音频编码使用规范(Digital Video Broadcasting (DVB); Specification for the use of Video and Audio Coding in DVB services delivered directly over IP protocols)3 术语和定义本文件没有需要界定的术语和定义。
stable video diffusion原理 -回复
stable video diffusion原理-回复稳定的视频传输亦称为稳定的视频扩散,是指在视频传输过程中保持画质和帧率稳定的技术。
这项技术在实时视频传输、视频会议以及流媒体等领域具有重要的应用价值。
稳定的视频传输可以通过多种技术来实现,其中包括分层编码、帧间编码以及错误修复等。
一、分层编码分层编码是实现稳定视频传输的一种常用方法。
该方法包括将视频数据划分为多个层,不同层次的数据对于画质和帧率的重要性不同。
在传输过程中,可以根据网络带宽和传输条件的变化,灵活地选择不同的层次进行传输,从而实现画质和帧率的稳定。
具体来说,分层编码将视频数据划分为基本层和增强层。
基本层包含了视频的基本信息,对于保证视频的基本质量起着重要作用。
增强层包含了视频的细节信息,对于提高视频的清晰度和细节展示具有重要作用。
在传输过程中,可以根据网络带宽和传输条件的变化,选择性地传输基本层和增强层,以达到稳定的视频传输效果。
二、帧间编码帧间编码是实现稳定视频传输的另一种常用方法。
该方法利用视频中相邻帧之间的相关性,通过压缩和预测来减少传输数据量。
帧间编码将视频帧划分为关键帧和预测帧。
关键帧是完整的帧,不依赖于其他帧进行解码。
预测帧则是根据前一帧或多帧来进行预测和重建。
在传输过程中,可以选择性地传输关键帧和预测帧,以适应网络带宽和传输条件的变化。
这样可以减少传输数据量,并提高整个系统的稳定性。
帧间编码在视频会议和流媒体等实时传输场景中具有广泛应用。
三、错误修复错误修复是保证稳定视频传输的另一个重要技术。
在视频传输过程中,由于网络干扰、传输错误或丢包等原因,传输数据可能会发生错误。
为了减少错误对视频画质和帧率的影响,可以采用错误修复技术来进行恢复。
一种常用的错误修复技术是冗余编码。
该技术通过在传输数据中增加冗余信息,以实现错误的检测和修复。
当传输数据出现错误时,接收端可以利用冗余信息对错误进行检测,并利用冗余信息进行数据恢复。
这样可以有效提高视频传输的稳定性。
ABNTNBR15602_2D2_2007Ing_2008
BRAZILIAN STANDARD ABNT NBR15602-2First edition2007.11.30Valid from2007.12.01Digital terrestrial television – Video coding, audio coding and multiplexingPart 2: Audio codingDescriptors: Digital terrestrial television. Source coding. AAC. Level and profile. ICS 33.160.01ISBN 978-85-07-00608-4Reference numberABNT NBR 15602-2:200812 pages© ABNT 2008ABNT NBR 15602-2:2007© ABNT 2008All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ABNT.ABNT officeAv.Treze de Maio, 13 - 28º andar20031-901 - Rio de Janeiro - RJTel.: + 55 21 3974-2300Fax: + 55 21 2220-1762abnt@.br.brPublished in Brazilii © ABNT 2007 – All rights reservedABNT NBR 15602-2:2007© ABNT 2007 – All rights reserved iiiContents Pages1 Scope (1)2 Normative references (1)3 Terms and definitions (1)4 Abreviations (2)5 Audio input format (3)5.1 General conditions (3)5.2 Main parameters (3)5.2.1 Formats (3)5.2.2 Interfaces (3)5.2.3 Audio signal levels (4)5.2.4 Multichannel modes or configurations (4)5.2.5 Metadata (4)6 Audio services and auxiliary channels (5)7 Audio coding system (6)8 Audio compression and transmission procedures (6)8.1 Overview of the coding standard (6)8.2 Profiles and levels (7)8.3 Transport and multiplex layer (7)9 Audio coding parameter restrictions (8)9.1 Audio coding parameter restrictions for full-seg services (8)9.1.1 Audio coding modes (8)9.1.2 Main parameters (9)9.1.3 Operational restrictions with respect to stereo receivers compatibility (10)9.2 Audio coding parameter restrictions for one-seg services (10)9.2.1 Audio coding modes (10)9.2.2 Main parameters (11)Bibliography (12)ABNT NBR 15602-2:2007ForewordAssociação Brasileira de Normas Técnicas (ABNT) is the Brazilian Standardization Forum. Brazilian Standards, which content is responsability of the Brazilian Committees (Comitês Brasileiros – ABNT/CB), Sectorial Standardization Bodies (Organismos de Normalização Setorial – ABNT/ONS), and Special Studies Committees (Comissões de Estudo Especiais – ABNT/CEE), are prepared by Study Committees (Comissões de Estudo – CE), made up of representants from the sectors involved including: producers, consumers and neutral entities (universities, laboratories, and others).Brazilian Standards are drafted in accordance with the rules given in the ABNT Directives (Diretivas), Part 2. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.ABNT NBR 15602-2 was prepared within the purview of the Special Studies Committees of Digital Television (ABNT/CEE-00:001.85). The Draft Standard was circulated for National Consultation in accordance with ABNT Notice (Edital) nº 07,from June 29, 2007 to August 28, 2007, with the number Draft 00:001.85-002/2.Should any doubts arise regarding the interpretation of the English version, the provisions in the original text in Portuguese shall prevail at all time.This standard is based on the work of the Brazilian Digital Television Forum as established by the Presidential Decree number 5.820 of June, 29th 2006.ABNT NBR 15602 consists of the following parts, under the general title “Digital terrestrial television – Video coding, audio coding and multiplexing”:⎯Part 1: Video coding;⎯Part 2: Audio coding;⎯Part 3: Signal multiplexing systems.This Standard is the English version of the corrected version dated 2008.04.07 of ABNT NBR 15602-2:2007.iv © ABNT 2007 – All rights reservedBRAZILIAN STANDARD ABNT NBR 15602-2:2007© ABNT 2007 – All rights reserved 1Digital terrestrial television – Video coding, audio coding and multiplexing Part 2: Audio coding1 ScopeThis part of ABNT NBR 15602 specifies the parameters for the audio signals and the system of sound coding and decoding to be used in the Brazilian system for digital terrestrial television (SBTVD).2 Normative referencesThe following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.ABNT NBR 15602-3:2007, Digital terrestrial television – Audio coding, video coding and multiplexing – Part 3: Multiplexing signalsABNT NBR 15603-2:2007, Digital terrestrial television – Video coding, audio coding and multiplexing – Part 3: Signal multiplexing systemsISO/IEC 13818-1:2007, Information technology – Generic coding of moving pictures and associated audio information: SystemsISO/IEC 14496-3:2005, Information technology – Coding of audio-visual objects – Part 3: AudioITU Recommendation BS.775-1, Multichannel stereophonic sound system with and without accompanying picture 3 Terms and definitionsFor the purposes of this part of ABNT NBR 15602, the following terms and definitions apply.3.1encodingtransforming process of external signals in bits representing such signalsNOTE The encoding takes place, for instance, through sampling, and the obtained information may also be compressed.3.2decodingprocess responsible for original signal recovery through the bits received by the coderNOTE The decoding also may, eventually, perform the decompression of the received information.3.3downmixoperation that transforms a n-channel matrix and obtains less than n channels, usually related to the conversion of a multichannel program to stereo or monoABNT NBR 15602-2:20073.4LATM/LOAStransport mechanism defined in the MPEG-4 that utilizes two layers, one for multiplexing and other for synchronizingNOTE The multiplexing layer LATM manages the multiplexing of several audio payloads (audio data) and its configuration data on the AudioSpecificConfig() elements. The synchronizing layer LOAS specifies the syntax for self-synchronizing in the MPEG-4 audio transport stream.3.5levelmaximum number of channels and sample frequency indicating the computational complexity of the decoder3.6full-seg receiverdevice capable of decoding the audio, video and data information contained in the transport stream layer of the thirteen segments aimed the fixed (indoor) and mobile servicesNOTE The classification of full-seg shall be applied to digital converters, and know as settop boxes and integrated thirteen segments with exhibition screen but not limited to those. This kind of receiver shall be capable of receiving and decoding the high definition television signals and at manufactures criteria, also be capable of receiving and decoding the information on layer “A” of the transport stream, which is originally aimed to the portable receivers, here defined as one-seg.3.7one-seg receiverdevice which decode exclusively audio and video information contained in transmission layer “A” located in the central portion of the thirteen segmentsNOTE The classification of the one-seg shall be assigned to portable receivers, also known as handheld devices, with screen size bellow 7 inches. Within the products classified as one-seg are, but not limited to, the mobile phone integrated receivers, PDA, one-seg dongles, portable television, that are energized by an internal battery and, therefore, without the necessary use of an external power source, as well as those aimed vehicular reception. This kind of receiver shall be capable of receiving and decoding only digital terrestrial television signal in layer “A” of the transport stream, and therefore only the basic profile, aimed the portable devices.3.8audio access unitaudio portion of an elementary stream that is individually accessibleNOTE For the proposes of this part of ABNT NBR 15602, the audio access unit is equivalent to a rawdatablock4 AbreviationsFor the purposes of this part of ABNT NBR 15602, the following abbreviations apply.AAC Advanced Audio CodingCPE Channel Pair ElementHDMI High-definition multimedia interfaceLATM Low overhead audio transport multiplexLFE Low Frequency EnhancementLOAS Low Overhead Audio Stream2 © ABNT 2007 – All rights reservedABNT NBR 15602-2:2007PCE Program Configuration ElementPCM Pulse-code modulationPS Parametric StereoPSI Program Specific InformationSAP Second Audio ProgramSCE Single Channel ElementSDI Serial Digital InterfaceSBR Spectral Band ReplicationTS Transport Stream5 Audio input format5.1 General conditionsThe general conditions for the audio input format shall be the following:a) sample frequency of audio signal: 32 kHz, 44,1 kHz or 48 kHz;b) configuration of stereophonic and multichannel signals (that means, signals consisting of two or more audiosignals to obtain an evolving reproduction or spatial sound): sample rate for all the signals shall be the same;c) quantization of input signals shall use 16 bits or 20 bits;d) one audio program shall have at least one audio channel. The maximum number of channels in the programshall be limited to maximum number of channels allowed for ISO/IEC 14496-3;e) it is recommended that multichannel programs be prepared in conformance with ITU RecommendationBS.775-1;f) for audio programs in multichannel mode compatible with the modes foreseen in the standard ITURecommendation BS.775-1 shall be in one of the allowed configurations presented on Table 3;g) in case a multichannel program is transmitted without a stereo program, the multichannel program shall be inmode 3/2 (5.0 or 5.1, with or without LFE of low frequency enhancement) to allow stereo downmix;5.2 Main parameters5.2.1 FormatsBitstreams or files containing uncompressed digital audio shall be accepted in PCM format, such as WAVE or AIFF, stereo and multichannel.5.2.2 InterfacesWithin the allowed digital input/output interfaces shall be AES3 (AES/EBU, with two PCM channels per bitstream), SDI, HD-SDI and HDMI.© ABNT 2007 – All rights reserved3ABNT NBR 15602-2:20075.2.3 Audio signal levelsThe reference level for sound pressure intensity shall be equal to 0 dB. The allowable dynamic range shall be limited to + 20 dB (headroom) and – 70 dB with respect to reference, corresponding to a typical dynamic range of 90 dB. Mean audio levels should be at – 20 dBFS (0 dB), to allow volume homogeneity between distinct channels. The signal shall allow peaks of at least 4 times its mean RMS power.5.2.4 Multichannel modes or configurationsThe transmission mode refers to the multichannel configuration used, the number of available channels in the transport stream and to the coding mode of this bitstream.The number of source audio channels shall be at least one for a basic configuration, two for typical stereo and five channels plus one low frequency enhancement (LFE) channel for standard “5.1” multichannel transmission. The source signals shall be preprocessed and/or combined prior to entering the encoder to produce the transmission channels, which shall be present in the bitstream.A same audio program may be transmitted in more than one mode, for instance, in stereo (2 channels) plus multichannel mode 3/2 (5.1) simultaneously, but the simultaneous transmission is not mandatory.In the case of exclusive transmission on multichannel mode 3/2 (5.1) the receivers shall be capable of synthesizing the stereo channel by means of a downmixing conversion, replication operations, dematrixing, combination and signal processing within the functional audio reproduction system of the receiver. The allowed multichannel modes for coding and transmission shall be as described in 9.1.1.5.2.5 MetadataAuxiliary data shall contain information such as content description of audio programs, configuration parameters of audio services and parameters of the transmitted audio signals in the bitstream.The following data may be allowed as auxiliary data:a) content description of audio programs being transmitted (for instance, sound program rating, audio objectsdescription mixed within the content, auxiliary channel content description, etc);b) the multichannel mode;c) the reference level for equalization operations during playback on the access terminal.Auxiliary data and the content description of audio programs may be classified in two levels.A first level shall be normative. This level shall affect directly the receiver operation (bitstream decoding) such as, for instance, number and channel mode information and coding profile and level extracted directly from PSI tables. The data under this category shall be essential for the correct decoding and playback of the audio service in the receiver.A second level shall be informative. This level shall not interfere with decoding, but give information about the content of the audio programs associated with each PID. Data in this category shall be used for processing the program information on the receiver.Table 1 summarizes the types of audio auxiliary data allowed in the system.4 © ABNT 2007 – All rights reservedABNT NBR 15602-2:2007© ABNT 2007 – All rights reserved 5Table 1 — Type of audio auxiliary data Parameter Description and usematrix_downmix_idx Description: coefficient indicator used in the multichannel-to-stereodownmix equations. Shall be transmitted in the bitstream as metadata,as specified in ISO/IEC 14496-3Use: Mandatory when a multichannel program is transmittedWhen the matrix_mixdown_idx_present parameter is set to ‘1’ in itsprogram PCE (PID), the downmix system described inISO/IEC 14496-3:2005, in subclause 4.5.1.2.2 and Table 4.70 shall beusedIf the receiving terminal performs the downmix process, the stereoanalog output shall be always active with this signalprogram_ref_level Description: representative value of the mean intensity of long termprogram audio volume for all combined channels with respect to the0 dBFS reference. It is represented in 128 levels (7 bits), in steps of0.25 dB with a total range of 32 dB in relation to the end of scale(0 dBFS)This parameter shall contain an informative description of the referencevolume used by the broadcaster (0 dB) with respect to the end of scale(0 dBFS), for dialogue normalization and to make the channel changemore comfortable to the viewerUse: mandatory. It is recommended to use prog_ref_level = 80 (0x50)which corresponds, to an indicative value of – 20 dBFS as 0 dBreference, according to ISO/IEC 14496-3This parameter shall be transmitted together with the DRC structure,as described in ISO/IEC 14496-3:2005, subclause 4.5.2.7Dynamic Range Control (DRC)Description: the dynamic range control is specially indicated totransmissions in multichannel mode and can be signaled by metadata,as indicated in ISO/IEC 14496-3:2005, subclause 4.5.2.7Use: is optional during encoding, but the decoder shall support this tool.In case the encoder do not sends the DRC information, the decodershall not use the DRC tool 6 Audio services and auxiliary channelsAudio services include the transmission of additional audio programs to the main program and shall be considered optional services, excluding the audio description channel which transmission is required by current legislation.The transmission of these services is done through the allocation of additional auxiliary channels in distinct audio programs (PID) or in the same bitstream of a unique PID, observing the maximum number of allowed channels in the same bitstream by the coding profile/level used.Additional channels to the main program may be used to transmit audio in other languages (for instance, SAP), to transmit additional programs to the main program, audio description services (AD), and secondary audio from other sound takes (additional content, such as effects).All additional channels referring to auxiliary audio services shall be appropriately signaled using valid component_type identification in the respective audio_component_descriptor of the program.The auxiliary channels shall be transmitted in distinct programs (distinct PID) with proper signaling and channel identification to be selected, decoded and played with or in substitution of the main audio program channels.ABNT NBR 15602-2:2007The audio description service usually consists in one voice monoaural channel and gives a scene description as a subcomponent associated to the television service. It shall support the understanding of the main entertainment (but no exclusively) for viewers with visual impairment.The AD transmission shall be implemented using at least one of the mechanisms below:a) as an auxiliary channel (monaural or stereo) containing the AD previously mixed with the main audio program;b) as a auxiliary channel containing separate AD to later processing with the main audio program;In both cases, the service should be signaled on the component_type parameter described in the “Audio component descriptor”, as per ABNT NBR 15603-2:2007, Table 28.The ability to mix one or more supplementary description channels with the main audio program may have other applications, including multilingual commentary, interactivity and educational purposes.7 Audio coding systemAudio signals shall be coded by a combination of time-frequency transform coding. The frequency transform shall decompose the input signal in its frequency components by means of a modified discrete cosine transform (DCT), which reduces the amount of information by reducing the decrease in frequency deviation of each component.An additional compression tool is the psycho-acoustic weighted bit assignment in which codes shall be weighted to minimize signal degradation in the frequency bandwidth perceived by human ears.Audio compression and transmission procedures shall comply with ISO/IEC 14496-3.Decoders shall be made under the assumption that any legal structure as permitted by ISO/IEC 13818-1 may occur in the broadcast stream even if presently reserved or unused. The audio decoder shall be able to skip over “reserved” structures and data structures which correspond to functions not implemented by receivers.8 Audio compression and transmission procedures8.1 Overview of the coding standardFigure 1 shows audio compression and transmission procedure.6 © ABNT 2007 – All rights reservedFigure 1 - Procedures for audio transmission and codingThe filter bank shall convert the digital audio input signal from time domain to frequency domain. After that, the filter bank applies the modified discrete cosine transform, and windowing functions to input signal blocks, according to audible psychological characteristics.The psychoacoustic process shall calculate the masking quantity (limits for differentiating a specific audio signal from other signals) and feed the filter bank with input signal blocks.The samples shall be quantized after the filter bank processing, based on masking factor calculated by psychoacoustic process. So that, the total number of bits utilized for each block shall not be exceeded. Bitstream shall be configured according to ISO/IEC 14496-3.8.2 Profiles and levelsThe audio coding shall be compatible with ISO/IEC 14496-3. The following profiles and levels of MPEG-4 AAC standard shall be allowed:a) LC (low complexity), basic profile of AAC standard; L2 and L4 levels;b) HE (high efficiency), advanced profile of high efficiency, combining the LC profile with the use of the SBR(spectral band replication) tool for version 1 of this profile, L2 and L4 levels;c) HE combined with PS (parametric stereo) tool for version 2 of this profile, L2 level.The profile and level of the MPEG-4 AAC coder shall be adequately signalized according to ABNT NBR 15602-3e ABNT NBR 15603-2.8.3 Transport and multiplex layerThe intermediate audio coding and framing shall be compatible with LATM/LOAS according to ISO/IEC 14496-3. The elementary stream shall be first encapsulated in the LATM transport format and shall use the A udioMuxElement() multiplex element.The audio transport synchronization layer (LOAS) shall use the AudioSyncStream() transmission format, according to ISO/IEC 14496-3.The MPEG-4 audio transported by the MPEG-2 transport stream using the LATM/LOAS transport syntax shall be identified by the stream_type 0x11, according to the stream_type_assignments in ISO/IEC 13818-1:2007.To decode audio, the receiver shall identify the type, profile and level transmitted and shall be capable to extract the audio objects payloads. It is mandatory the use of explicit SBR signaling without PES alignment to transmit MPEG-4 audio over MPEG-2 transport streams.© ABNT 2007 – All rights reserved7The receivers shall be capable of processing the SBR tool. The SBR presence signaling shall be explicit using the non-backward compatible explicit signalization mechanism, according to ISO/IEC 14496-3.Table 2 describes the LATM/LOAS transport syntax fields within StreamMuxConfig(), which shall be formatted to identify and recover audio payloads, according to ISO/IEC 14496-3.Table 2 — Main LATM configuration parametersLATM parameter Use descriptionaudioMuxVersion Shall have the value “0”allStreamsSameTimeFraming Shall have the value “1”numSubFrames Shall have the value “0” indicating only one PayloadMux() (access unit) within an AudioMuxElement()numProgram Shall have the value “0” indicating one program per LATMnumLayer Shall have the value “0” indicating only one layerframeLengthType Shall have the value “0” indicating that the payload frame length isvariable. The payload extension in bytes is directly specified inPayloadLengthInfo() with 8 bits words9 Audio coding parameter restrictions9.1 Audio coding parameter restrictions for full-seg services9.1.1 Audio coding modesThe coding mode determines the number of available channels on the audio service. The audio coding modes for digital transmission shall be in accordance to the restrictions of Table 3.Table 3 — Restrictions of the audio coding modesParameter RestrictionAllowed audio modes Monaural (1/0), stereo (2/0 and 2/0 + LFE)a, multichannel stereo (3/0, 2/1, 3/1, 2/2, 3/2, 3/2 + LFE)a, two independent audio signals (dual monaural), multi-audio (three or more audio signals) and a any combination of the above modesRecommended audiomodesStereo (2/0), multichannel (3/2 + LFE)Downmix The signaling presented in Table 1 shall be used for 5.0 and 5.1 configurations. In any other multichannel configuration, the receiver can use other downmix schemes, since audio intelligibility is assured. The stereo-to-mono downmix scheme is not covered by this Standard, but clipping shall be avoideda Number of channels for front/surround loudspeakers.EXAMPLE 3/1 = 3 front + 1 surround; 3/2 = 5.0 = 3 front channels and 2 surround.© ABNT 2007 – All rights reserved 9The decoder shall be capable to process any of the recommended audio modes.The second channel configuration according to its operation mode, and its transmission order within the payload, shall be in accordance with Table 4.Table 4 — Channel configurations and recommended modes for MPEG-4 AAC ModeChannel configuration SE order of transmission a Standard element for loudspeaker mapping b Monaural (1/0)1 <SCE1><TERM> SCE1 = C Stereo (2/0)2 <CPE1><TERM> CPE1 = L and R 3/03 <SCE1><CPE1><TERM> SCE1 = C, CPE1 = L and R3/1 4 <SCE1><CPE1><SCE2> <TERM> SCE1 = C, CPE1 = L and R, SCE2 = MSMultichannel 5.0 (3/2) 5 <SCE1><CPE1><CPE2> <TERM> SCE1 = C, CPE1 = L and R,CPE2 = LS and RSMultichannel 5.1 (3/2 + LFE)6 <SCE1><CPE1><CPE2> <LFE><TERM> SCE1 = C, CPE1 = L and R,CPE2 = LS and RS, LFE = LFE a Abbreviations related to the syntactic element (SE): SCE – single channel element, CPE – channel pairelement, LFE – LFE channel element, TERM – terminator.b Abbreviations related to loudspeaker arrangement: L – front-left loudspeaker / R – front-right loudspeaker / C– front-central loudspeaker / LFE – low frequency enhancement / LS – left-surround loudspeaker / RS – right-surround loudspeaker / MS – monaural surround loudspeaker .In the case a two independent audio signals are transmitted (monaural dual or 1/0 + 1/0) the recommended SE order of transmission is: <SCE1><SCE2><TERM>, being SCE1 the first (main) channel and SCE2 the second program channel.If the used configuration is not present on Table 4, it shall be reproduced using a configuration with the same number of channels and with the respective signaling.9.1.2 Main parametersThe audio coding system main parameters shall be as presented on Table 5.Table 5 — Main audio coding parameters – Full-seg servicesParameter RestrictionAllowed transport mechanismsLATM/LOAS (according to ISO/IEC 14496-3) Recommended channel numberMono (1.0), 2 channels (stereo or 2.0) or multichannel (5.1) Allowed profiles and levels Low complexity AAC: level 2 (LC-AAC@L2) for two channelsLow complexity AAC: level 4 (LC-AAC@L4) for multichannel High-Efficiency (HE): level 2 (HE-AAC v1@L2) for two channelsHigh-Efficiency (HE): level 4 (HE-AAC v1@L4) for multichannelMaximum allowed bit rateIn accordance to ISO/IEC 14496-3 Samples per frame frameLengthFlag in GASpecificConfig() shall be set to 0, indicating that the frame length shall be of 1024 samples for AAC and 2048when using SBR. 960 samples for AAC (or 1920 when using SBR)are not allowedFor high-fidelity transmission it is recommended the use of the profile/level AAC@L4 in multichannel mode and profile/level AAC@L2 for stereo mode. In stereo audio transmission, level 4 (L4) shall not be used.Signals may be encoded on any bit rate supported by the selected profile and level. At the same time, the multichannel signal may use any of the profile sample rates.The dynamic range control tools of MPEG-4 AAC may be used.9.1.3 Operational restrictions with respect to stereo receivers compatibilityWhen the multichannel service is available:a) the transmission shall occur with a minimum of one program in two channels (2/0 or stereo) or onemultichannel program (3/2);b) the simultaneous transmission of two channels is not mandatory when the multichannel service is available.Basically, the two channels receiver (stereo) shall be capable to process the signal through downmixing;c) the receiver shall be capable to interpret the downmix coefficient using PCE according to the AAC standard(see Table 1) when the 5 (3/2) and 5.1 (3/2 + LFE) channel services are available.9.2 Audio coding parameter restrictions for one-seg services9.2.1 Audio coding modesThe coding mode determines the number of available channels on the audio service. The audio coding modes for digital transmission shall be in accordance to the restrictions described on Table 6.Table 6 — Restrictions on audio coding modes – one-seg service Parameter RestrictionAllowed audio modes Monaural (1/0), stereo (2/0)The audio decoder shall be capable to process any of the recommended audio modes.The channel configuration, according to the operation mode, and its transmission order within the payload shall be in accordance to Table 7.Table 7 — Channel configuration and standard modes for MPEG-4 AAC Mode Channel configuration SE order oftransmission aStandard element for loudspeaker mapping b Monaural (1/0) 1 <SCE1><TERM>SCE1 = C Stereo (2/0) 2 <CPE1><TERM>CPE1 = L and R a Abbreviations related to the syntactic element (SE): SCE – single channel element, CPE – channel pairelement, LFE – LFE channel element, TERM – terminator.b Abbreviations related to loudspeaker arrangement: L – front-left loudspeaker / R – front-rightloudspeaker / C – front-central loudspeaker.。
通信专业部分术语英文简写
multiple description coding前向纠错码(FEC)或自动要求重发机制(ARQ。
FEC要求带宽比较多.而且FEC的设计和网络的状态密切相关.而网络的状态恰恰是最难估量的。
采用ARQ带来的问题是丢失包重新收到的时延比较长运动补偿内插(MC.1单描述符(SD,single description)压缩原理,现有传输层解决丢包问题的主要方法包括:自动重传请求(auto retransmission request,ARQ)、采用纠错码进行前向纠错 J(forward error corection,FEC)以及混合ARQ与离散余弦变换(discrete cosine transform,DCT3.3 数据分组数据分组的方法是利用码流中不同部分重要性不同的特点来将码流中不同重要性的部分分开分别打包,并运用不等错误保护(unequal error protection,UEP)的编码方法来对不同重要性的包给予不同程度的差错保护,例如,一般来说,图像编码的码流中的运动矢量对重建图像质量的贡献要大于离散余弦变换(discrete cosine transform,DCT)系数的贡献,因而可以将运动矢量与DCT系数区分开来分别打包,并给予不同程度的差错保护。
用不等错误保护(unequal errorprotection,UEP)的编码方法来对不同重要性的包给予不同程度的差错保护精细可伸缩编码(fine granular scalability,FGS3.4 可伸缩编码可伸缩编码是将编码的码流分为基本层和若干增强层分别进行编码,其中基本层满足最基本的要求,而且越多的增强层将使解码端重建信号的质量越好。
一种较好的可伸缩编码方法是精细可伸缩编码(fine granular scalability,FGS)。
FGS的基本层编码与普通的视频编码是一样的,而增强层则采用了比特平面的编码方法。
FGS编码虽取得了较好的可伸缩性,但是由于FGS编码的运动估计补偿是基于基本层进行的,因而运动补偿之后的残差较大,这就降低了编码效率。
基于模式复制的H.264多描述视频编码
基于模式复制的H.264多描述视频编码董萌;蔡灿辉【期刊名称】《信号处理》【年(卷),期】2011(027)011【摘要】本文提出了一种新的基于H.264的多描述视频编码算法——基于模式复制的多描述编码算法.首先对输入视频序列中的每一帧图像分别进行水平方向下采样和垂直方向下采样,形成四个子图像.相应的子图像构成四个视频子序列.把这四个子序列两两组合,形成两个描述,每个描述包含两个子序列.由于每个描述中两个子序列之间具有很强的空间相关性和时间相关性,其对应宏块的最佳模式和运动矢量基本相同,因此只需用H.264编码器对其中一个子序列进行编码,另一子序列则可直接采用上述已编码子序列的最佳模式和运动向量对其进行预测编码.这样只需要对其中一个子序列进行模式选择,也只需要对一个子序列的最佳模式和运动向量进行编码传输,既降低了计算复杂度,又提高了编码效率.实验结果表明,在中高码率下,本文算法与同类算法在相同比特率情况下,PSNR有明显的提高,并且比特率越高,这种优势就越明显.%This paper presents a novel multiple description video coding algorithm for H. 264, called mode duplication based multiple description coding. Each frame in the input video sequence is down-sampled first horizontally and then vertically to form four sub-frames. The resulted four sub-sequences are pair-wisely grouped to form two descriptions. Considering that two sub-sequences in a description have strong spatial correlation and temporal correlation, so the best modes and motion vectors in corresponding macro-blocks are basically the same. In thispaper, only one sub-sequence per description is coded by a H. 264 coder, and the other sub-sequence is coded by using the best modes and motion vectors of the aforementioned encoded subsequence. Consequently, only one sub-sequence per description needs to perform mode decision, reducing the computational complexity and bit rates. The experimental results have shown that at moderate and high rates, the proposed algorithm achieves a higher coding quality compared with other H. 264 based MDC algorithms.【总页数】5页(P1675-1679)【作者】董萌;蔡灿辉【作者单位】华侨大学信息科学与工程学院,厦门,361021;华侨大学信息科学与工程学院,厦门,361021【正文语种】中文【中图分类】TP309.7【相关文献】1.一种兼容H.264标准的多描述视频编码方法 [J], 卓力;王仕宝2.基于H.264视频编码的快速模式决策算法 [J], 吴桂清;陈彦芳;厉振武3.H.264视频编码帧间与帧内预测模式算法的改进 [J], 魏晨;王民4.基于H.264和双树小波的多描述视频编码 [J], 陈婧;李莉;蔡灿辉5.基于CDN和H.264的多描述视频编码方法 [J], 杨任尔;肖方明;郁梅因版权原因,仅展示原文概要,查看原文内容请购买。
多描述编码
1 引言
hl钯Inet及无线网络的迅猛发展使视频流逐渐成 为网络的主流业务,而视频业务的不断拓展又促使了 视频编码技术的不断发展。传统的视频编码是针对给 定信道带宽而进行的,其目标是在某一给定带宽下, 使重建的视频质量达到最优或传输更多的信息。随着 互联网的发展,网络带宽的波动及可能出现的丢包, 使得编码技术不但要考虑如何使视频流适合于网络 的波动性,还要考虑如何克服信道中出现的数据差错
道的多描述编码,其目标就是设计编码一解码器, 当两个信道同时工作时使平均失真最小,并使平均 失真在只有一个信道工作时服从约束,从而保证最 小的失真。对于两信道的多描述编码,早期的研究 主要集中于五元组(R1'恐,D0,Dl,D2)的可实现范 围(Sh锄non意义上的),对于可实现的范围有如下 约束
D0≥D(墨+恐)
收稿日期:2003.12.23;修回日期:2004.08.26 基金项目:国家自然科学基金资助项目(60202006)
万方数据
通信学报
第26卷
2多描述编码的理论研究
多描述编码的历史可以追溯到20世纪70年代, 当时Bell实验室为了在电话网上提供不问断的电话 业务,将来自一个通话的信号进行奇偶分离成两路 信号,并在两个分离的信道上传输。当时该问题被 Beu实验室称为信道分离(ch锄∞l splining)问题。
相关。PradhaIl和R锄chaIldrall、证明例:对二维高
斯矢量信源(两描述)而言,2×2方块正交变换是 酉滤波器簇中的最优变换。使用正交变换的一个不 足是:导致两个信道的不对称(两个描述的率不相 等)。非正交MDTC使用非正交的变换而不是使用 正交的变换,它使得变换在设计上有更大的灵活 性。对经过非正交变换后的变量使用均匀量化将导
设计了J躺一个aI量I化i和器来Ta减斓小l这提伞出差距了。_种._算1 法用’于构造
Hikvision iVMS-4200客户端软件说明书
iVMS-4200 Client Software is designed to configure and manage Hikvision devices in a unified and intuitive manner, including the DVRs, NVRs, IP cameras, encoders, access control devices, security control panels, video intercom devices, VCA devices, etc. It provides multiple functionalities, including real-time live view, video recording, video footage search and playback, event and alarm receiving, etc.Key FeatureLive View●Supports up to 64-window division for standard screen, and 48-window division for wide screen●Supports customizing window division●Supports viewing the stream information during live view, including bitrate, frame rate and resolution (except for devicesadded by Hik-Connect)●Supports live view in fisheye mode for one or more fisheye cameras, and supports Panorama, PTZ, Half Sphere, AR HalfSphere, and Cylinder modes●Supports smart linkage●Supports resuming the latest live view status after the client restarts●Supports displaying or hiding waste gas information during live viewRecording●Supports recording both main stream and sub-stream for playback (if device supports)●Supports manual recording●Supports recording schedule for continuous recording, event recording and command recording●Providing SAN and Hybrid Storage Area Network configuration for Hybrid SAN devices●Supports overwriting video file and deleting expired video fileEvent Management●Supports camera linkage and multiple linkage actions●Supports configuring up to 4 cameras as the linkage of one event, and supports playing back the videos or capturedpictures of the cameras simultaneously when searching historical events or viewing real-time events●Supports sending email with captured picture as the attachment when the event is triggered●Supports customizing alarm sound●Supports subscribing event that the client can display in real time in event center when it is triggered●Supports audible warning, pop-up live view and captured picture when alarm is triggered●Supports receiving real-time events, e.g. events of face arming●Supports searching for the historical events by event type or event details as the key words●Supports exporting historical events in CSV format●Supports searching and downloading event triggered captured picture and event triggered video●Supports acknowledging the received event, viewing the event on E-map, etc.●Supports device arming and partition and zone settings●Supports event configuration for video event, access control event, and security control event●Supports sending alarms when the gray scale is abnormal or object thrown from building is detected●Supports searching for the persons’ temperature information and whether they are wearing masks when exporting thecapture events of face temperature screening●Supports checking the event types of door contact open/close and door contact open by force of video intercom devices ●Supports displaying events triggered by authentication via irisPlayback●Supports remote playback●Supports up to 16-ch synchronous playback●Supports viewing the stream information during live view, including bitrate, frame rate, resolution (except for devicesadded by Hik-Connect)●Supports instant playback, normal playback, alarm input playback, event playback, ATM playback, VCA playback, fisheyeplayback and POS playback●Supports locating the playback time accurately●Supports skipping unconcerned video footage during VCA playback●Supports filtering the video footage with human or vehicle detected●Supports searching and exporting captured pictures of event by date and event type●Supports downloading video file of devices added by Hik-Connect●Supports merging video files when downloading by date●Provides player in the installation directory to view the downloaded video file●Supports searching recorded video files triggered by event and playing the video files, and downloading the video files Person Management●Supports managing persons in different organizations●Supports getting person information in a batch or via employee ID from added devices●Supports importing and exporting person and face information●Provides multiple types of credentials, including card number, face, and fingerprint, for composite authentications●Supports collecting face pictures by third-party camera (USB camera or the build-in camera of computer)●Supports viewing resource statistics (including persons, face pictures, cards, iris and fingerprints) on client and on device ●Supports extending person’s validity period for access permission●Supports reading card No. by swiping card●Supports using USB to collect card number, fingerprint, face, and person ID from the Enrollment Station●Supports collecting iris via the client or access control devices●Supports getting the iris from access control devicesAccess Control and Video Intercom●Supports setting holiday schedule and access schedule template●Supports setting a schedule for door's remaining open/closed status●Supports setting access groups to relate persons, templates, and access points, which defines the access permissions ofdifferent persons●Supports multiple modes for both card reader authentication and person authentication●Supports advanced functions such as multi-factor authentication, custom Wiegand, first person in, anti-passback, andmulti-door interlocking●Supports controlling the door status (lock, unlocked, remain locked, remain unlocked, remain all locked and remain allunlocked) by the client remotely●Supports applying iris information to the device●Added iris as the authentication mode●Supports configuring linkage actions for events triggered by authentication via irisElevator Control●Supports setting parameters for elevator control devices●Supports setting the relay types of the elevator control devices and setting the relation between relays and floors●Supports controlling elevator status via the client, including Opening Door, Controlled, Free and Disabled●Supports displaying events triggered by iris authenticationTime and Attendance●Supports setting general rules for time and attendance●Supports setting different rules for various attendance scenarios, such as one-shift and man-hour shift●Supports customizing overtime levels and setting corresponding work hour rate●Supports flexible and quick settings of timetables, shifts, and shift schedule●Supports setting multiple timetables in one shift●Supports getting detailed attendance data from the managed device, including check-in and check-out, break-in andbreak-out, overtime-in and overtime-out, etc.●Supports customizing contents displayed in reports and sending reports to specified email address according to schedule ●Supports multiple types of reports according to different needs●Supports sending the original attendance data to a third-party database (Microsoft® SQL Server® 2008 and above, MySQLV5.0.45 and above) and customizing the data type, and thus the client can access third-party T&A and payment system●Supports calculating the break time as attendance●Supports flexible shift schedule on weekend●Supports editing flexible timetable and counting the day with insufficient attendance time under the set flexible timetableas absenceSecurity Control●Accessing AX-series security control device●Supports adding zone as hot spot on E-map and viewing the video of the linked camera●Supports radar configuration, including drawing zones, drawing trigger line, setting master-slave tracking, setting parkingpoints for linked camera, setting map calibration, drawing point cloud filter zones, and displaying environment learning information in blue points●Supports drawing false track area●Supports enabling terrain learning when setting smart linkageStatistics●Supports data statistics of heat analysis, people counting, counting, road traffic, face retrieval, license plate retrieval,behavior analysis, face capture, queuing-up time analysis, queue status analysis and intersection analysis●Supports people counting by facial features and displaying the duplicated persons●Supports showing large picture of face retrieval, license plate retrieval, and behavior analysis and the pictures can beexported for local storage●Supports data retrieval for faces, human bodies, vehicles, behavior analysis related pictures and videos, persons who donot wear hard hats, and facial recognition check-in●Supports searching facial recognition check-in records●Supports searching frequently appeared persons and rarely appeared persons●Supports AI dashboard retrieval function to search result for imported picture analysis task●Supports hard hat retrieval by wearing an hard hat or not and face recognition status, and supports displaying ID type andID No. in search results●Supports searching for the historical temperature statistics of specific devices and displaying the information on atemperature map●AI Dashboard supports searching for data stored in DeepinMind serversNetwork●Supports adding encoding devices and Hik-Connect devices●Supports adding devices by IP address, domain name, HiDDNS, IP Segment and ISUP account, and supports importingdevices in batch●Supports enabling transmission encryption using TLS (Transport Layer Security) protocol when adding a device●Supports searching for the active online devices●Supports NTP protocol for time synchronization from the client to the added devices●Supports checking device's online users●Supports two-way audio and broadcast function●Supports applying the client in local area network and wide area networkPTZ Control●Supports remote PTZ control, preset, patrol, and pattern settings●Supports displaying analog speed dome's local menu via PTZ control panel●Supports PTZ control of one-touch patrol and one-touch park●Supports lens de-icing heater and PT de-icing●Supports arming and tracking target (human or vehicle)General●Supports transmission encryption when logging in the SDK over TLS mode●Supports upgrading client and device firmware after detecting new versions●Supports importing and exporting configuration file●Supports auto backing database up according to the configured schedule●Supports log search and backup●Supports adding facial recognition devices such as DeepinView and DeepinMind●Supports remote configuration for added devices●Supports adding online devices registered to Hik-Connect after logging into Hik-Connect●Supports creating a password to activate device. For device which supports Hik-Connect, supports enabling Hik-Connectservice when activating it●Supports resetting device password●Supports setting email when activating devices, and resetting the password of devices by the email●Supports hardware decoding for live view and playback●Supports downloading video files to PC in MP4 and AVI format●Supports user permission management●Supports E-map functions, including adding, deleting, editing and viewing e-map, zooming in/out and moving the e-map ●Provides topology management module to monitor network health status of connected devices●Provides configuration wizards for access control and time and attendance, which helps users to quick start●Supports importing the events of the access control devices to the client in CSV format (encrypted)●Supports configuring display formats of date and time of the client●Supports 1V1 face comparison●Supports searching analysis result for video and captured picture task●Supports face picture retrieval, human body retrieval and vehicle retrieval, and exporting the related video files●Supports saving pictures in structure data format to meet GDPR standards in the EU●Supports selecting the retention period of events (the default retention period is 3 years)●The Online Device List supports exporting information of video intercom devices, including door station, indoor stationand main station.SpecificationModel iVMS-4200DatabaseClient Database SQLite (encrypted)Third-Party Database Microsoft® SQL Server® 2008 and above, MySQL V5.0.45 and aboveSupported Language Arabic, Bulgarian, Croatian, Czech, Danish, Dutch, English, Finnish, French, German, Greek, Hungarian,Indonesian, Italian, Japanese, Korean, Lithuanian, Norwegian, Polish, Portuguese, Portuguese (Brazil), Romanian, Russian, Serbian, Simplified Chinese, Slovak, Slovenian, Spanish, Swedish, Thai, Traditional Chinese, Turkish, Ukrainian, VietnameseClient GeneralUser 50 users and one super userE-map 256Encoding Device 256Group256 groups256 channels for each groupChannel 256 channels for all groupsDeepinMind Server 1Behavior Analysis Task 64 tasksBehavior Analysis Taskin One Group64 tasksVideoLive View 64-ch live view at a time on one screenAuxiliary Screen Preview One main screen and 3 auxiliary screens for live viewPlayback 16-ch playback at a timeSynchronous Playback 16-ch synchronous playbackDownloading 16-ch downloading tasks at a timeAccessControlOrganization 10 levelsPerson 2,000Card 5,000Finger 5,000Face Picture 2,000Elevator Controller 2Access Group 50Door 50Template 16Video Intercom Devices(Door Station, IndoorStation, Master Station)256Shift 32Time and AttendanceDataThe retention period of attendance results and retention period of original recordsdepend on the HDD capacity and amount of the data generated during usage. SecurityControlSecurity Control Panel 16Security Radar 8System Requirement* For high stability and good performance, the following system requirements must be met. Features RequirementsOperating System Microsoft® Windows 7 SP1 and above (32-bit or 64-bit) Microsoft® Windows 8.1 (32-bit or 64-bit)Microsoft® Windows 10 (32-bit or 64-bit)Microsoft® Windows 11 (32-bit or 64-bit)CPU Intel® Core™ i3 Processor and above Memory 4 GB and aboveResolution 1280×768 and aboveLive View PerformanceH.264 (Software Decoding)Resolution Bit Rate(Mbps)FrameRate(fps)CPU:***************Graphics Card: GT1030Windows 10 64-bitCPU:***************Graphics Card: GTX1050TiWindows 10 64-bitCPU:***************Graphics Card: GTX2080×2Windows 10 64-bitChannels CPU(%) Memory(MB) Channels CPU(%) Memory(MB) Channels CPU(%) Memory(MB)1080P 6 30 11 79-88 150.9 18 86-88 156.4 27 86-89 173.4 8MP 12 30 4 73-80 169.4 5 76-87 95.6 7 72-82 194.3 H.264 (Hardware Decoding)Resolution Bit Rate(Mbps)FrameRate(fps)CPU:***************Graphics Card: GT1030Windows 10 64-bitCPU:***************Graphics Card: GTX1050TiWindows 10 64-bitCPU:***************Graphics Card: GTX2080×2Windows 10 64-bitChannels GPU(%)Memory(MB)Channels GPU(%)Memory(MB)Channels GPU(%)Memory(MB)1080P 6 30 7 50-52 181.9 30 14-16 99.3 29 11-15 133.9 8MP 12 30 3 19-21 188.3 6 4-6 176.6 7 5-6 169.8 H.264+Resolution Bit Rate(Mbps)FrameRate(fps)CPU: i3-8100Graphics Card: GT1030 D5Windows 7 64-bitCPU:**************Graphics Card: GTX970Windows 7 64-bitCPU: i7-6700k@4GHzGraphics Card: GTX1070Windows 7 64-bitChannels CPU(%) Memory(MB) Channels CPU(%) Memory(MB) Channels CPU(%) Memory(MB)720P 3 30 24 62-84 1,208 27 63-90 1,382 48 53-80 1,125 1080P 6 30 11 60-89 1,024 12 61-90 1,536 21 80-90 1,161 8MP 12 30 - - - 3 70-91 686 6 64-92 1,249 H.265Resolution Bit Rate(Mbps)FrameRate(fps)CPU: i3-8100Graphics Card: GT1030 D5Windows 7 64-bitCPU:**************Graphics Card: GTX970Windows 7 64-bitCPU: i7-6700k@4GHzGraphics Card: GTX1070Windows 7 64-bitChannels CPU(%) Memory(MB) Channels CPU(%) Memory(MB) Channels CPU(%) Memory(MB)720P 3 30 14 69-91 1,054 15 70-90 850 26 71-89 1,251 1080P 6 30 8 64-81 1,105 8 60-85 1,239 15 70-88 1,284 8MP 12 30 - - - 2 77-92 666 3 51-64 1,075Typical ApplicationApplication for Video SecurityApplication for Video IntercomApplication for Security Control PanelApplication for Access Control。
AZ 17-11ZK长寿命小体积电缆孔盖M16多编码双层防水说明书
DataOrdering dataProduct type descriptionAZ 17-11ZK Article number (order number)101121960EAN (European Article Number)4030661049670eCl@ss number, Version 9.027-27-26-02eCl@ss number, Version 11.027-27-26-02Approval - StandardsCertificates BGcULusCCCEAC CNCAGeneral dataProduct nameAZ 17Coding level according to ISO14119Low Enclosure materialPlastic, glass-fibre reinforced thermoplastic, self-extinguishing Material of the contacts,electricalSilver Gross weight 85 g AZ17-11ZKLong lifeSmall bodycable gland M16Multiple codingDouble-insulated8 actuating planes30 mm x 60 mm x 30 mmInsensitive to soilingThermoplastic enclosure High level of contact reliability with low voltages and currentsGeneral data - FeaturesNumber of auxiliary contacts1Number of safety contacts1Safety appraisalStandards EN ISO 13849-1Mission Time20 Year(s)Safety appraisal - Safety outputsB10d Normally-closed contact2,000,000 Operations (NC)B10d Normally open contact1,000,000 Operations (NO)Note (B10d Normally openat 10% I e and ohmic load contact (NO))Mechanical dataMechanical life, minimum1,000,000 Operations Latching force 5 Npositive break travel11 mmPositive break force, minimum17 NActuating speed, maximum 2 m/sMechanical data - Connection techniqueTerminal Connector IDC method of termination Cable section, minimum 1 x 0.75 mm²Cable section, maximum 1 x 1 mm²Mechanical data - DimensionsLength of sensor30 mmWidth of sensor30 mmHeight of sensor60 mmAmbient conditionsDegree of protection IP 67 to IEC/EN 60529 Ambient temperature, minimum-30 °CAmbient temperature,+80 °CmaximumAmbient conditions - Insulation value250 VRated insulation voltage UiRated impulse withstandvoltage U imp4 kVElectrical dataThermal test current10 AUtilisation category AC-15230 VACUtilisation category AC-15 4 AUtilisation category DC-1324 VDCUtilisation category DC-13 4 ASwitching element NO contact, NC contact Switching principle Creep circuit element Scope of deliveryIncluded in delivery Actuators must be ordered separately.Slot cover for dust-proof covering of the opening not in useNotesNote (General)This type termination (IDC) method enables simple connetion of flexible conductors without the need for the use of conductor ferrulesOrdering codeProduct type description:AZ 17-(1)Z(2)K-(3)-(4)-(5)(1)111 NO contacts/1 NC contact 022 NC contact(2)without Latching force 5 NR Latching force 30 N(3)without M16 cable gland 2243Front cable entry 2243-1Rear cable entryST M12 connector, 4 pole(4)1637Gold-plated contacts(5)5M Cable length 5 m6M Cable length 6 mPicturesProduct picture (catalogue individual photo)ID: kaz17f16| 670,2 kB | .jpg | 221.192 x 529.167 mm - 627 x 1500Pixel - 72 dpi| 125,7 kB | .png | 74.083 x 177.094 mm - 210 x 502Pixel - 72 dpiDimensional drawing basic componentID: 1az17g01| 3,7 kB | .png | 74.083 x 51.858 mm - 210 x 147 Pixel- 72 dpi| 32,7 kB | .cdr || 67,0 kB | .jpg | 352.778 x 247.297 mm - 1000 x 701Pixel - 72 dpiSwitch travel diagramID: kaz17s01| 52,6 kB | .jpg | 352.778 x 125.236 mm - 1000 x 355Pixel - 72 dpi| 2,0 kB | .png | 74.083 x 26.458 mm - 210 x 75 Pixel -72 dpi| 19,6 kB | .cdr |DiagramID: kaz17k07| 50,1 kB | .jpg | 352.778 x 103.011 mm - 1000 x 292Pixel - 72 dpi| 15,8 kB | .cdr |Assembly exampleID: kaz17m02| 210,2 kB | .cdr |K.A. Schmersal GmbH & Co. KG, Möddinghofe 30, D-42279 WuppertalThe details and data referred to have been carefully checked. Images may diverge from original. Further technical data can be found in the manual. Technical amendments and errors possible.Generated on 21/05/2021 05:05:43。
DS-2CD6944G0-IHS( NFC) 180° Stitched 16 MP PanoVu
● 1/1.8" Progressive Scan CMOS● Max. resolution 4800 × 2688 @ 30 fps in panorama display mode● Multiple display modes available: panorama, original, panorama + ePTZ, and divided panorama ● Up to 20 m IR distance ● H.265+, H.264+● BLC, 3D DNR, HLC, defog, EIS (only the original mode supports)● Audio and alarm I/O ● IP67, IK10DORIThe DORI (detect, observe, recognize, identify) distance gives the general idea of the camera ability to distinguish persons or objects within its field of view. It is calculated based on the camera sensor specification and the criteria given by EN 62676-4: 2015.DORIDetectObserve Recognize Identify Distance(2.8 mm) 63.0 m 25.0 m 12.6 m 6.3 m Distance(6 mm)126.5 m50.2 m25.3 m12.6 mSpecificationsCameraImage Sensor 1/1.8" Progressive Scan CMOSMin. Illumination Color: 0.009 Lux @ (F1.6, AGC ON)B/W: 0.0018 Lux @ (F1.6, AGC ON), 0 Lux with IRShutter Speed 1/25 s to 1/100,000 sDay & Night IR cut filter. Blue glass module to reduce ghost phenomenon. WDR Digital WDRAngle Adjustment Pan: 0° to 355°, tilt: 0° to 90°LensLens Type Fixed lens, 2.8 mm/6 mm, four lensesAperture F1.4Focus ManualFOV 2.8 mm: horizontal FOV 180°, vertical FOV 90°6 mm: horizontal FOV 180°, vertical FOV 25°Lens Mount M16IlluminatorIR Range Four IR LEDs, up to 20 m Wavelength 850 nmVideoMax. Resolution 2.8 mmPanorama+ePTZ mode: panorama channel: 1920 × 1080; ePTZ channel: 1920 × 1080 Panorama mode: 4800 × 2688Original mode: 2688 × 1520Divided panorama: 2400 × 13446 mmPanorama+ePTZ mode: panorama channel: 3072 × 540; ePTZ channel: 1920 × 1080 Panorama mode: 8160 × 1440Original mode: 2688 × 1520Divided panorama: 2032 × 1440Main Stream 2.8 mmPanorama+ePTZ mode: panorama channel: 50Hz: 25fps (1920 × 1080, 960 × 540),60Hz: 30fps (1920 × 1080, 960 × 540); ePTZ channel: 50Hz: 25fps (1920 × 1080, 1280 × 720), 60Hz: 30fps (1920 × 1080, 1280 × 720)Panorama mode: 50Hz: 25fps (4800 × 2688, 3840 × 2160, 2688 × 1520), 60Hz: 30fps (4800 × 2688, 3840 × 2160, 2688 × 1520)Original mode: 50Hz: 25fps (2688 × 1520), 60Hz: 30fps (2688 × 1520)6 mmPanorama+ePTZ mode: panorama channel: 50Hz: 25fps (3072 × 540, 2688 × 480, 1920 × 320), 60Hz: 30fps (3072 × 540, 2688 × 480, 1920 × 320); ePTZ channel: 50Hz: 25fps (1920 × 1080, 1280 × 720), 60Hz: 30fps (1920 × 1080, 1280 × 720)Panorama mode: 50Hz: 25fps (8160 × 1440, 6720 × 1200, 4800 × 840), 60Hz: 30fps(8160 × 1440, 6720 × 1200, 4800 × 840)Original mode: 50Hz: 25fps (2688 × 1520), 60Hz: 30fps (2688 × 1520)Sub-Stream 2.8 mmPanorama mode: 50Hz: 25fps (1920 × 1080, 960 × 540), 60Hz: 30fps (1920 × 1080, 960 × 540)6 mmPanorama mode: 50Hz: 25fps (3072 × 540, 2688 × 480, 1920 × 320), 60Hz: 30fps (3072 × 540, 2688 × 480, 1920 × 320)Video Compression Main stream: H.265/H.264Sub-stream: H.265/H.264/MJPEGH.264 Type Baseline Profile/Main Profile/High ProfileH.264+ Main stream supportsH.265 Type Main ProfileH.265+ Main stream supportsVideo Bit Rate 32 Kbps to 16 MbpsScalable Video Coding (SVC) H.264 and H.265 encodingAudioAudio Compression G.711/G.722.1/G.726/MP2L2/PCMAudio Bit Rate 64Kbps(G.711)/16Kbps(G.722.1)/16Kbps(G.726)/32-192Kbps(MP2L2)/32Kbps(PCM) Environment Noise Filtering YesAudio Sampling Rate 8 kHz/16 kHz/32 kHz/48 kHzSmart Feature-SetBasic Event Motion detection (only panorama mode supports), exception (network disconnected, IP address conflict, illegal login, HDD full, HDD error)People Density Yes (only panorama mode supports)Linkage Method Upload to FTP/NAS/memory card, notify surveillance center, send email, trigger alarm output, trigger recording, trigger captureImageImage Enhancement BLC, HLC, 3D DNR, Defog, EIS (only the original mode supports)Image Settings Rotate mode (only the original mode supports), saturation, brightness, contrast, sharpness, AGC, and white balance are adjustable by client software or web browserTarget Cropping Yes (only panorama mode supports)Day/Night Switch Day/Night/Auto/Schedule/Triggered by Alarm InPicture Overlay LOGO picture can be overlaid on video with 128 × 128 24bit bmp format NetworkNetwork Storage Support Micro SD/SDHC/SDXC card (256G), local storage and NAS (NFS,SMB/CIFS), ANRProtocols TCP/IP, ICMP, HTTP, HTTPS, FTP, DHCP, DNS, DDNS, RTP, RTSP, RTCP, PPPoE, NTP, UPnP, SMTP, SNMP, IGMP, 802.1X, QoS, IPv6, UDP, BonjourAPI ONVIF (PROFILE S, PROFILE G), ISAPI, SDK, EhomeSecurity Password protection, complicated password, HTTPS encryption, 802.1X authentication (EAP-TLS, EAP-LEAP, EAP-MD5), watermark, IP address filter, basic and digest authentication for HTTP/HTTPS, WSSE and digest authentication for ONVIF, RTP/RTSP over HTTPS, control timeout settings, security audit log, TLS 1.2, TLS1.0, TLS1.1Simultaneous Live View Up to 20 channelsUser/Host Up to 32 users. 3 user levels: administrator, operator and user Client iVMS-4200Web Browser IE8+InterfaceCommunication Interface 1 RJ45 10M/100M/1000M Ethernet port;1 RS-485 interface (half duplex, HIKVISION, Pelco-P, Pelco-D, self-adaptive)Audio 1 input (line in), 3.5 mm 3-section connector, max. input amplitude: 1 vpp, input impedance: 4.7 KΩ, interface type: non-equilibrium;1 output (line out), 3.5 mm 3-section connector, max. output amplitude: 1 vpp, output impedance: 100 Ω, interface type: non-equilibriumAlarm 2 inputs, 2 outputs (max. 24 VDC, 1A)On-board Storage Built-in microSD/SDHC/SDXC slot, up to 256 GBFiber Optical (/NFC)Interface Type FC interfaceOptical Type Single mode, single fiberInput/output Wavelength Tx1310nm/1.25G, Rx1550nm/1.25G Transmission Distance Up to 20 kmGeneralFirmware Version V5.5.83Web Client Language EnglishGeneral Function Anti-flicker, heartbeat, mirror (only original mode supports), privacy masks (only original mode supports), password protection, watermark, IP address filter (only original mode supports), pixel counterReset Reset via reset button on camera body, web browser and client software Startup and OperatingConditions-40 °C to +60 °C (-40 °F to +140 °F), humidity 95% or less (non-condensing) Storage Conditions -40 °C to 60 °C (-40 °F to 140 °F), humidity 95% or less (non-condensing) Power Supply 12 VDC, three-core terminal block, PoE (802.3at)Power Consumption and Current 12 VDC, 1.6 A, max. 24 W, PoE (802.3at, 42.5 V to 57 V), 0.5 to 0.4 A Material Aluminum alloyHeater YesDimensions Camera: 189.5 × 207.63 × 206.62 mm (7.46" × 8.17" × 8.13") Package: 340 × 261 × 293 mm (13.4" × 10.3" × 11.5")Weight Camera: approx. 3 kg (6.6 lb.) With package: approx. 5 kg (11 lb.)ApprovalEMC 47 CFR Part 15, Subpart B; EN 55032: 2015, EN 61000-3-2: 2014, EN 61000-3-3: 2013, EN 50130-4: 2011 +A1: 2014; AS/NZS CISPR 32: 2015; ICES-003: Issue 6, 2016; KN 32: 2015, KN 35: 2015Safety UL 60950-1, IEC 60950-1:2005 + Am 1:2009 + Am 2:2013, EN 60950-1:2005 + Am 1:2009 + Am 2:2013, IS 13252(Part 1):2010+A1:2013+A2:2015Environment 2011/65/EU, 2012/19/EU, Regulation (EC) No 1907/2006Protection Ingress protection: IK10 (IEC 62262:2002), IP67 (IEC 60529-2013)Available ModelDS-2CD6944G0-IHS (2.8 mm), DS-2CD6944G0-IHS/NFC (2.8 mm), DS-2CD6944G0-IHS (6 mm), DS-2CD6944G0-IHS/NFC (6 mm)Typical ApplicationHikvision products are classified into three levels according to their anti-corrosion performance. Refer to the following description to choose for your using environment.This model has NO SPECIFIC PROTECTION.Level DescriptionTop-level protection Hikvision products at this level are equipped for use in areas where professional anti-corrosion protection is a must. Typical application scenarios include coastlines, docks, chemical plants,and more.Moderate protection Hikvision products at this level are equipped for use in areas with moderate anti-corrosiondemands. Typical application scenarios include coastal areas about 2 kilometers (1.24 miles)away from coastlines, as well as areas affected by acid rain.No specific protection Hikvision products at this level are equipped for use in areas where no specific anti-corrosionprotection is needed.DimensionAccessoryDS-1602ZJ Wall MountDS-1661ZJPendant MountCap (Included)。
专业英语学习:通讯行业英语词汇
市话号码 local number市话局 local office市话忙 local busy市话络 local network市忙 local busy sib⽰波器 oscillometer事件检测点 event detection point edp事实上的标准,⾮官⽅标准 de facto standards事务处理能⼒ transaction capabilities tc事务处理能⼒应⽤部分 transaction application part tcap事务处理应⽤部分 transaction capability application part tcap 事务处理⼦层 transaction sub-layer tsl事务处理⼦层的能⼒ transaction sub-layer capabilities tsc视距通信系统 line of sight system los视盘,视像盘,电视唱盘 videodisc视频 video frequency视频编码,电视编码 video coding视频点播 video on demand vod视频器件 video parts视听 audio-visual av试呼 call attempt试图,企图, 试呼 attempt试⽤物料 probation materials〖整理该⽂章,版权归原作者、原出处所有。
〗试运⾏ trial running室内电缆卡 cable fixed-caliper室内接地总汇 indoor grounding bar室内⾛线架 indoor cabling rack室外接地总汇条 outdoor grounding bar室外设备单元 outdoor device unit odu室外⾛线架 outdoor cabling rack适配单元 adaptive unit au适配器, 衔接器,转接器, 附加器 adapter ap释放 release释放监护信号 release guard signal rlg释放键 release key释放完成消息 release complete message rlc收到后向b4 backward signal b4 received收发 transceiving收发单元 transmit-receive unit tru收发端局 the transmitting and receiving end office收发速率适配单元 transmitting-receiving rate adapter unit trau 收发特性 transceiver features收发信单元背板 transceiver backplane trb收发信机(板) transceiver (board) trx收发信机基带单元 transceiver baseband unit tbu收号状态 number receiving status收缩卷积码 punctured convolutional codes收完再发 sending after receiving completely收信机 receiver收信机/接收 receiver/reception rx⼿电钻 hand-held electric drill⼿动复位 manual reset⼿机 mobile phone⼿锯 handsaw⼿摇钻 hand drill守护进程 daemon⾸尾站 originating and destination stations⾸选电路群 first-choice circuit group⾸选路由 first-choice route寿命曲线 life curve受话器 receiver受理席 handle position售后服务 after-sales service书签 bookmark枢纽站 junction center station输出脉形 output pulse form输⼊、输出设备 input/output device输⼊/输出设备 input/output equipment io输⼊监测 input monitor connector imc输⼊输出地址 i/o address ioa⿏标转接线⼩转⼤键盘转接线⼀拖⼆键盘转接线 ps2 mouse switchersmall-to-big keyboard switcherone-to-two keyboard switcher树型 tree network数标⽅式 digital label mode数据/地址总线 data/address bus dabus数据包 packet数据采集 data collection数据操作语⾔ data manipulation language数据层次结构 data hierarchy数据处理语⾔ data manipulation language dml数据电路终接设备 data circuit-terminating equipment dce数据分割 data partitioning数据⾼速通道 data highway数据缓冲处理器 data buffer handler dbh数据缓冲器 data buffer dbuf数据集标号 data set label dsl数据加密 data encryption数据库 database db数据库登录 login database数据库管理系统 data base management system dbms数据宽带设备 broadband data equipment数据链路层 data link (layer) dl数据链路连接标识 data link connection identifier dlci数据流 data stream ds数据流图 data flow chart数据描述语⾔ data description language ddl数据⽣成器 data generator数据收集 data collecting数据⼿套 data glove数据通信oem专⽤物料 special materials for datacom oem products数据通信设备 datacom equipment数据通讯芯⽚ datacom chip数据 data network数据显⽰控制 data display control ddc数据形式1 data form1 dt1数据终端就绪 data terminal ready dtr数据终端设备 data terminal equipment dte数据总线 data bus数据总线电路 data bus circuit数码管 digitron数模转换器 digital-analog converter d/a数制,数系 number system数字程控交换机 digital spc switch数字电话交换机 digital telephone exchange txd数字电话络 digital telephone network dtn数字电视 digital television数字多点微波系统 digital multipoint microwave system dms数字复接,分接器数字复⽤器-数字分解器 digital multiplexer-demultiplexer数字复⽤ digital multiplexing数字话⾳插空,数字语⾳插空 digital speech interpolation dsi数字环回 digital loop-back [page]数字环路测试 digital loop test数字环路复⽤系统 digital loop multiplexing system数字环路载波 digital loop carrier数字键 number key数字交叉连接单元 digital cross-connect unit dcc数字交叉连接设备 digital cross-connection system dxc数字交替反转 alternate digit inversion adi数字接⼊与交叉连接系统 digital access and cross-connect system数字陆地电视⼴播 digital terrestrial television broadcasting dttb数字逻辑电路芯⽚ digit-logic circuit chip数字配线架(中继) digital distribution frame ddf数字配线架,数字分配架 digital distribution frame ddf数字式amps 系统(美) advanced mobile phone system-digital amps-d数字数据业务 digital data service dds数字通信复⽤器 digital communication multiplexer dcm数字络结构 digital network architecture dna数字线路终端单元 digital line-termination unit dltu数字信号,级别n digital signal,level n ds-n数字信号-0级 digital signal level 0 传输速率为64kb/s ds-0数字信号处理器 digital signal processing dsp数字信号处理器芯⽚ dsp chip数字⽤户线电路 digital subscriber line circuit dslc数字中继 digital trunk dt数字中继板 digital trunk board数字中继电缆 digit trunk cable衰减 attenuation衰减特性 attenuation specification衰落 fading衰落容限 fading allowance双边缘连接器 edge connector双⼯ duplex双⼯器,天线共⽤器,天线分离滤波器 duplexer双缓冲 double buffering双击,双按(⿏标) double click双级交叉连接结构 dual staged cross connect architecture双极化定向天线 directional bipolarization antenna双极性 bipolar双极性传输 bipolar transmission双极性破坏 bipolar polarity violation bpv双绞线 twisted pair ftp双绞线 twisted pair cable双节点互连 dual node interconnection dni双节点交互 dual node interworking双⼝随机存储器 double port random memory dpram双连接集线器 dual-attached concentrator dac双列直插式封装 dual in-line package dip双路光功率放⼤器 2 x booster amplifier ba2双⾯胶 double faced adhesive tape双频 dual band双频/多层话务流量控制 dual band/multi-layer advanced load management (alm) 双频⼿机 dual-band mobile phone双频⽆缝切换 dual band seamless handovers双频制 bifrequency system双频终端 dual-band terminal双速率码型变换板 dual-rate transcoder drt双速率码型变换板 dual-rate transcoder drt双头电话线 dual-port telephone line双纤单向通道保护环 two-fiber unidirectional path protection ring双纤双向线性倒换环 two-fiber bidirectional linear switched ring双相制 biphase system双向 bi-directional,2-way双向全闭塞 bi-directional block双向天线 bidirectional antenna双向线性倒换环 bidirectional linear switched ring双向中继 two-way trunk, bidirectional trunk双向⾃愈环 bi-directional self-healing ring bshr双⾳多频 dual tone multi-frequency dtmf双⾳多频按键话机 dtmf phone set双⾳发号 dual-tone dialing双⾳信号收发板 dual tone transceiver dtr双重占⽤ dual holding⽔浸传感器 water sensor⽔平调节脚 leveling adjuster, leveling feet⽔平仪 level instrument, gradienter⽔平仪⽓泡 level vial⽔淹告警 flooding alarm顺序号 sequence number snr瞬断 transient interruption说明, 例证, 例⼦, 图表, 插图 illustration说明书 instructions说明⽂件 instruction files死锁 dead lock四分之⼀通⽤中间格式 quarter common intermediate format qcif 四位拨码开关 4-digit toggle switch松⾹ rosin速率适配 rate adaptation ra塑胶件 plastic parts算法语⾔ algorithmic language随机 random rand随机存取存储器 random access memory ram随机接⼊信道 random access channel rach随机数 random number随机资料 delivery attached documentation随路控制信道 associated control channel acch随路信令 channel associated signaling cas隧道标识 tunnel identifier tid损失业务量,损失话务 lost traffic缩位拨号 abbreviated dialing abd缩位呼叫, abbreviated call锁闭功能 lock-out function锁定开关 locking switch锁紧螺钉 locking screw锁紧螺母 retaining nut锁开关 lock switch锁相 phase lock锁相环 phase lock loop dpll他站 remote station / another station塔顶放⼤器 tower amplifier塔放模块 tower amplification module台上计算机,台式微机 desktop computer钽电容器 tantalum capacitor碳膜电阻器 carbon-film resistor陶瓷滤波器 ceramic filter [page]套件 kit, suite套接字 socket套筒扳⼿ socket wrench特服 special service st特服台 special service console (station)特⾼频 ultra high frequency uhf特殊拨号⾳ special dial tone特殊滤波器 special filter特殊信号⾳信号 special-information tone signal ssi特殊信息⾳ special information tone特殊振荡器 special oscillator特征函数 characteristic function特征相互作⽤管理 feature interactions management fim特征状态(况) characteristic condition特指 refer in particular to ...特制电缆 traitor-make cable梯⼦ ladder提⽰ prompt提⽰框 prompt dialog box提⽰⾳/提醒⾳ prompt tone提醒被叫⽤户 destination user prompting dup提醒主叫⽤户 originating user prompting oup体系结构 architecture天馈 antenna feeder天馈部件 antenna feeder parts天馈附件 antenna feeder accessories天馈检测计 antenna feeder detector天馈滤波器 antenna feeder filter天馈耦合器 antenna feeder coupler天馈线 antenna feeder天馈组件 antenna feeder component天线 antenna天线⽅向性图,天线辐射图 antenna pattern天线合路器 antenna combiner acom天线增益 antenna gain天线增益 antenna gain天线⽀架 antenna stand填充⽐特 filling bit填充材料 embedding material填充信号单元 fill in signal unit fisu填充字符 filling character跳次计数 hop count跳频 frequency hopping fh跳频多址 frequency hopping multiple access fhma跳频扩频 frequency hopping spread spectrum fhss跳频序列号 hopping sequence number hsn跳线 jumper贴⽚电感器 smt inductor贴⽚化 surface mounting technology smt贴⽚化双⾳驱动板 surface-mounted dual-tone driving card铁粉芯 irondust core铁路通信系统 railroad communication system rrcs铁塔天线 tower antenna停机,中⽌ halt停⽌等待⽅式 stop-and-wait通达状态,通话状态 connected status通道 channel通道保护和复⽤段保护 path protection and multiplex section protection 通道开销 path overhead poh通过测试 pass the test通话 conversation通话费 call charge通话计费时长 charged duration通话时间 conversation time通路开销 path overhead poh通配符,万能符 wild-card。
专业英语期末复习
专业英语期末复习一.名词解释PCM pulse-code modulation 脉冲编码调制PPM Pulse Position Modulation 脉冲位置调制ASK amplitude shift keying (ASK) 幅移键控FSK frequency shift keying (FSK) 频移键控BFSK binary frequency shift keying 二进制频移键控MSK minimum shift keying 最小频移键控PSK phase shift keying (PSK) 相移键控FDM Frequency division multiplexing频分复用OFDM orthogonal frequency division multiplexing 正交频分复用TDM time division multiplexing 时分复用WDM wave division multiplexing 波分复用DWDM dense wave division multiplexing 密集型波分复用PM amplitude/ frequency/ phase modulation (AM/FM/PM)幅度/频/调制CPM continuous phase modulation 连续相位调制FDMA frequency division multiple access.频分多址TDMA time division multiple access 时分多址CDMA code division multiple access 码分多址SDMA space division multiple access 空分多址GSM global system for mobile communicatons 全球数字移动通信系统MS mobile station 移动台BTS base transceviver 基站收发台BSC base station controller 基站控制器BSS base station subsystem 基站子系统MSC mobile switching center 移动交换中心AUC Authentication center 鉴权中心VLR visitor location register 访问位置寄存器EIR equipment identity register 设备识别寄存器HLR home location register 本地位置寄存器PSTN public switched telephone network 公共电话交换网ISDN integrated sercices digital network 综合业务数字网Boardband—ISDN Boardband-ISDN ADSL asymmetric digital subscriber line 非对称数字用户线路NSS network and switching subsystem 网络交换中心PBX private branch exchange 程控交换机ATM asynchronous transfer mode 异步传输模式LAN local area network 局域网IEEE Institute of Electrical and Electronics Engineers美国电气和电子工程师协会CSMA/CD Carrier Sense Multiple Access/Collision Detect载波监听多路访问/冲突检测MAC medium access control 介质访问控制层LLC logical link control 链路逻辑控制TCP Transmission Control Protocol 传输控制协议FTP file transfer protocolJPEG: Joint Photographic Experts Group 联合图像专家小组MPEG: Moving Pictures Experts GroupNAP s network access points 网络接入点IXPs Internet exchange points 互联网接入点SNA systems network architecture 系统网络体系结构OSI open system interconnectionGPS thw global positioning system 全球定位系统ICMP:Internet Control Message Protocol控制报文协议IGMP:Internet Group Management Protocol 组管理协议FDD frequency division duplex 频分双工TDD time division duplex 时分双工PLL phase lock loop 锁相环ADC analog-to-digital converter模数转换器SSMA spread spectrum multiple access 扩频多址系统VLC variable length coding 可变长编码HDTV high-definition tevevisionVOD video-on-demand 视频点播技术OSS operation support systems 运营支撑系统DRM digital rights management 数字版权管理CISC/SISC complex/simple instruction set computerPLMN public land mobile network 公共陆地移动网MUL mobile user link 移动用户链路GWL gateway link 网关链路ISL inter satellite links 内部卫星链路BRI basic rate interface 基本速率接口PRI primary rate interface 基群速率接口TA terminal adapter 终端适配器APD avalanche photodiode 雪崩光电二极管PIN positive-intrinsic negative 本征光电二极管TE transverse electric mode模电模式TM tranaverse magnetic 横磁模式LP linearly polarized mode 线性模式STB set top box 机顶盒Multimedia 多媒体information theory 信息论signal-to-noise信噪比destination of the information信宿sequences of messages 消息序列the light intensity光强度three dimensional sound transmission三维声音传输In a multiplex PCM system the different speech functions must be sampled,compressed,quantized and encoded.在一个多路复用PCM系统中不同的语音函数必须被抽样、压缩、量化和编码a pair of wires一双金属丝a coaxial cable一条同轴缆a band of radio frequencies一波段的收音机频率a beam of light一束光discrete and continuous variables离散、连续变量modulated signal已调信号modulating signal 调制信号binary bit-steam二进制比特流base-band signal基带信号antennas.天线synchronization同步the carrier frequency载波频率Path-loss信道损耗penetration of obstacles绕射reflection反射, scattering散射, diffraction衍射Spectral efficiency 频率效率power efficiency功率效率robustenss稳定性DSP digital signal processor 数字信号处理器Multiple Access 多址技术the guard band 保护频段frequency hopping and direct sequence 调频和直接序列扩频downlink/uplink slots 上行时隙/下行时隙Circuit Switching 电路交换Packet switching 分组交换dedicate line 专用线路subscriber用户thunk 中继local loop 用户环路physical layer物理层datalink layer 数据链路层application layer 应用层Internetwork layer 网际层Network interface layer 网络接口层twisted copper cable双绞线coaxial cable 同轴电缆optical fiber 光缆Bus/tree/ring/star topology 总线/树/环/星型拓扑结构Round robin 循环reservation 预约contention 竞争an access point 接入点、访问点hierarchical 等级上hot spots 热点decompression/compression 解压缩/压缩encoder/decoder 编码器/解码器redundancy 冗余lossy/lossless 有损/无损multicast 多播authentication 身份鉴定/鉴权authoirization 授权nomadicity 漫游session management 会话管理stream control transmission 流控制传输协议channel bonding 信道绑定on hook/off hook 接通/挂断attenunation loss 衰减损耗transmission loss 传输损耗acousto optic modulator 声光调制器electro-optic modulator 光电调制器optical amplifiers 光放大器dielectric waveguide 电解质波导step inder fiber 阶跃光纤graded index fiber 渐变光纤single mode/multimode fibers 单/多模光纤hard/soft handover 硬/软切换spread spectrum 扩频narrowband signal/interference 窄带信号/干扰power density 功率谱密度resistance narrowband/adjacent interface 抵制窄带/频道干扰band pass filter 带通滤波器geostationary/geosynchronous satellite 同步卫星satellite for navigation 导航卫星Geostationary (or geosynchronous) earth orbit (GEO): 地球同步轨道Medium earth orbit (MEO): 中距离轨道Low earth orbit (LEO):近地轨道Highly elliptical orbit (HEO): 椭圆轨道paramount 及其simultaneously 同时mechanism 机制the radio spectrum 无线频谱a user process 一个用户进程defined by port and sockets 由端口号和套接字定义multiple application 多个应用程序duplicate data suppression 抑制数据复制error recovery 差错复原connection-orient reliable data delivery 面向连接的可靠的数据传输congestion/flow control 拥塞/流量控制二.翻译1.So What is Cloud Computing?We see Cloud Computing as a computing model, not a technology. In this model “customers” plug into the “cloud” to access IT resources which are priced and provided “on-demand”. Essentially, IT resources are rented and shared among multiple tenants much as office space, apartments, or storage spaces are used by tenants. Delivered over an Internet connection, the “cloud” replaces the company data center or server providing the same service. Thus, Cloud Computing is simply IT services sold and delivered over the Internet. Refer to section of Types of Cloud Computing.Cloud Computing vendors combine virtualization (one computer hosting several “virtual” servers), automated provisioning (servers have software installed automatically), and Internet connectivity technologies to provide the service[1]. These are not new technologies but a new name applied to a collection of older (albeit updated) technologies that are packaged, sold and delivered in a new way.A key point to remember is that, at the most basic level, your data resides on someone else’s server(s). This means that most concerns (and there are potentially hundreds) really come down to trust and control issues. Do you trust them with your data?那么什么是云计算?我们看到云计算作为一个计算模型,而不是技术。
P2P流媒体服务方案及其关键技术研究
第1期 No.1
计 算 机 工 程 Computer Engineering
文章编号:1000—3428(2013)01—0125—06 文献标识码:A
2013 年 1 月 January 2013
中图分类号:TP393
・网络与通信・
P2P 流媒体服务方案及其关键技术研究
张明军,彭
————————————
过充分利用网络上主机节点 (Peer 节点 )的空闲资源, 使 Peer 节点既是获取流媒体数据的客户端,也是提 供数据下载的服务器,这样可极大地减少流媒体源服 务器的压力,具有很好的扩展性和较高的性价比。因 此, P2P 流媒体技术已经成为 Internet 上流媒体应用 最常见的实现方案。 本 文根 据十年 来 的 P2P 流 媒体 服务方 案 ( 包 括 P2P 流媒体直播和点播 2 种服务 )的研究成果, 对 P2P 流媒体的关键技术进行分析和总结,并对未来可能的 研究方向提出一些看法。
2
P2P 流媒体覆盖网络构建技术
P2P 流媒体覆盖网络的构建技术主要有 2 种:
基金项目:广州大学华软软件学院科研基金资助项目(200926) 作者简介:张明军(1980-),男,讲师、硕士,主研方向:流媒体技术;彭 收稿日期:2011-09-13 修回日期:2011-11-14 娅、俞文静,讲师、硕士 E-mail:zh_mjun@
126
计
算
机
Hale Waihona Puke 工程2013 年 1 月 15 日
(1)基于应用层组播技术; (2)基于支持分布式操作的通信协议 (如 Gossip 协 议 )。此外,还有各种结构或技术结合的混合结构。 单组播树结构 依据构建覆盖网络的方式,即构建控制拓扑和数 据拓扑的先后顺序,可将单组播树结构分为网优先 (mesh first) 、 树 优 先 (tree first) 和 隐 含 式 (implicit) 等 3 类。 2.1 2.1.1 网优先单组播树 在网优先组播方式中,组成员首先形成控制拓
Html5学习进阶一 视频和音频
autoplay
假如浮现该属性,则视频在就绪后马上播放。
Your browser does not support the video tag.
controls
第2页共5页
controls 假如浮现该属性,则向用户显示控件,比如播放按钮。 Height</td> pixels 设置视频播放器的高度。 loop loop
假如浮现该属性,则当媒介文件完成播放后再次开头播放。 preload preload 假如浮现该属性,则视频在页面加载时举行加载,并准备播放。 假如用法 "autoplay",则忽视该属性。 src url
第3页共5页
要播放的视频的 URL。 Width</td> pixels 设置视频播放器的宽度。 HTML5 规定了一种通过 audio 元素来包含音频的标准办法。 audio 元素能够播放声音文件或者音频流。 当前,audio 元素支持三种音频格式:
Html5 学习进阶一 视频和音频
HTML5 规定了一种通过 video 元素来包含视频的标准办法。 当前,video 元素支持两种视频格式: Ogg=带有 Thedora 视频编码和 Vorbis 音频编码的 Ogg 文件 MPEG4=带有 H.264 视频编码和 AAC 音频编码的 MPEG 4 文件 如需在 HTML5 中显示视频,您全部需要的是:
如需在 HTML5 中播放音频,您全部需要的是:
control 属性供添加播放、暂停和音量控件。 与 之间插入的内容是供不支持 audio 元素的扫瞄器显示的:
Your browser does not support the audio tag.
第4页共5页
基于无线视频传感器网络的失真优化路由算法
基于无线视频传感器网络的失真优化路由算法陈旭;沈军;罗护;付新华【摘要】According to the characteristics of wireless sensor network link with video transmission instability and poor reconstruction quality, this paper proposed an reliable transmission of routing algorithm ( EDLOR) which is adaptive to Multiple Description Coding ( MDC). Firstly, it took fully consideration about the video coding rate, delay-constrained, network packet loss and other factors. Secondly, it aimed at how to optimize multiple description of the Peak Signal-to-Noise Ratio( PSNR). As a result, the overall video distortion minimization was gained. Thirdly, these MDCs would be assigned to designed path for transmission according the computed results. It is shown from experimental results that EDLOR can improve the overall video quality through promoting the average PSNR and lowering packet loss rate.%针对无线视频传感器网络链路不稳定、重建质量要求不高的特点,提出一种适应多描述编码(MDC)可靠传输的路由算法EDLOR.该算法充分考虑了视频编码速率、时延受限、网络丢包等因素,以多描述峰值信噪比(PSNR)作为优化目标,使视频总体失真最小化;然后根据计算结果,将多描述编码分配到指定的路径进行传输.实验结果表明,EDLOR路由算法能够提高平均PSNR,降低了网络丢包率,提升了总体视频质量.【期刊名称】《计算机应用》【年(卷),期】2012(032)005【总页数】4页(P1232-1235)【关键词】无线视频传感器网络;多描述编码;视频传输;路由;峰值信噪比【作者】陈旭;沈军;罗护;付新华【作者单位】桂林电子科技大学计算机科学与工程学院,广西桂林541004;桂林空军学院科研部,广西桂林541003;桂林空军学院科研部,广西桂林541003;桂林空军学院科研部,广西桂林541003【正文语种】中文【中图分类】TP3930 引言随着多媒体应用的增加,对网络服务实时通信的要求也越来越高。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Multiple Description Video Coding over Multiple Path RoutingNetworksShaoshuai Gao, and Hamid GharaviNational Institute of Standards and Technology100 Bureau Drive, Gaithersburg, MD 20899-8920Email: sgao@, gharavi@AbstractThis paper presents a multiple description (MD) video-coding scheme, which uses interlaced high signal to noise ratio (H-SNR) and low signal to noise ratio (L-SNR) coded frames to produce two bit-streams. At the decoder, when both bit-streams are received a high quality video will be reconstructed. If either one is received, a poorer but acceptable quality video can be reconstructed. In this approach, we also considered the mismatch between the encoding and decoding loops due to motion compensation if only one bit-stream is received. We first give the results of the rate distortion performance of our scheme assuming that only one description is received. We then present simulation results under packet loss circumstances, which are simulated by real-world IP networks and ad-hoc networks. It is shown that the proposed scheme has a superior performance when compared with the single description MPEG-4 video coder and MD coding using video redundancy coding.1. IntroductionThe main objective of Multiple Description Coding (MDC) [1]-[12] is to encode a source into two (or more) bit-streams such that a high-quality reconstruction is achieved when both (all) bit-streams are received successfully. On the other hand, a lower but still acceptable quality reconstruction can be accomplished in the presence of only one bit-stream. In a packet loss circumstance, as long as the packets of each description are not lost at the same time, a basic quality can always be obtained. As a result, it makes the compressed signal more error resilient over a packet-loss network. MDC in conjunction with multiple path transport (MPT), enables traffic dispersion and load balancing of the network, which improves the overall throughput of the network. In recent years MPT has been found to be particularly attractive for mobile ad-hoc networks [1], [19], which normally suffer from excessive bursts of packet drops due to their dynamically changing network topologies. To satisfy the requirements of MDC for these applications, it is essential to introduce correlations between the two descriptions such that if one of the descriptions is lost, it can be estimated from the other. Introducing correlations would consequently result in expanding the source bandwidth. Optimizing tradeoffs between network resources, bandwidth expansions, and distortion are the most challenging aspects of MDC/multipath-routing, particularly for real-time signals.In the case of video [10], it is more than just applying an MD image coder [6], [7] to the prediction error signal. Motion-compensated temporal prediction [11], for instance, discusses the use of multiple coding modes and redundancy allocation among them. Although in [11] a mismatch due to motion compensation has been taken into consideration, it is mainly based on the MDC on the spatial field. Wang et. al, proposed a scheme that encodes the GOBs to two thread, either of which is composed by interlaced H-SNR GOBs and L-SNR GOBs [12]. This MDC scheme is also based on the spatial field and doesn’t consider the mismatch between the encoder and the decoder, which is a very important issue in terms of propagation distortion in the temporal direction.To extend MDC on the temporal field, it is possible to modify the Video Redundancy Coding (VRC) approach, which was originally developed to improve the error resilience for a single description video transmission [13]. This approach uses more than one prediction thread to encode each video frame such that when one thread is lost, the frame rate will be reduced. Although VRC is a single description coder, it can be directly extended to an MD coder where each thread of P frame can be sent via a different route. In this case, each coded P-frame will depend entirely on the earlier P-frames of the same thread. This approach has been considered in [14], which uses a complicated multiple frame interpolation method, referred as Mcinterp, toconceal lost information. As our main objective in this paper is to enhance the error resilience of the encoder rather than error concealment, the VRC approach, referred to as MD-VRC, has been used for comparison purposes.As far as our main contribution is concerned, we present a temporal-based MDC scheme that can completely solve the problem of mismatch. In the proposed scheme, video frames are encoded into two descriptions on the temporal field. Each description is composed of interlaced H-SNR and L-SNR frames. The order of H-SNR and L-SNR frames in the temporal direction changes alternatively between the two descriptions. We show that the proposed algorithm can significantly improve the performance compared with the single description (SD) MPEG-4 coder and the MDC-VRC coder under various IP-based test environments. This includes using our dual-path mobile ad-hoc routing testbed.2. Proposed coding schemeThe simplest way to produce two video descriptions is to duplicate the video bit-stream coded by single description coder (In this paper we call this encoder the duplicate coder). That is, either one of the two bit-streams can achieve the highest quality. However, if both are received, one of them will be totally useless. In this case, the redundancy will be 100%. Bear in mind that the basic concept behind MDC coding is to reduce the redundancy to a lower level (at a given distortion). Thus, our main objective is to find a method that can approach the highest quality with minimal added redundancy when only one description is received.The basic idea is to encode the frames using two different quantization step-sizes in an interlaced manner. For one description the frames will be encoded using a lower quantization step-size (i.e., high-quality) and then switching to a higher quantization step-size in turn. For the other description, however, the order of the quantization step-size should be reversed in order to make the bitrate of the two descriptions nearly the same. That is, one description’s step-size should be low, high, low, high, and so on. The other description’s quantizer step-size should be high, low, high, low, and so on.Figure 1 shows the proposed encoder, in which Q1 and Q2 are quantization step-sizes where Q1<Q2. There are two types of outputs for the encoder. One is High quality (H-SNR) coded frame (coded by a lower step-size Q1) and the other is Low quality (L-SNR) coded frame (i.e., re-quantizing the samples by a higher step-size Q2). As shown in Figure 1, it can be observed that the low quality reconstructed frame is used as a reference frame for both L-SNR and H-SNR encoders. (Justifications for this arrangement will be discussed in the next section).Figure 2 shows the block diagram of the decoder, which consists of H-SNR and L-SNR decoders. The received bit-streams 1 and 2 from two channels will switch to the corresponding decoder on a frame-by-frame basis. It should be noted that there are two frame buffers in the H-SNR decoder: one for decoding the H-SNR frame and the other for reconstructing the L-SNR frame. The reconstructed L-SNR frame will then be used as a reference frame to decode the next frame. This is to make sure that both descriptions use the same reference frame to encode the next low or high quality frame. As far as the L-SNR decoder is concerned, it operates just like a SD decoder.In error-free circumstances, the final decoded frame will always have the H-SNR quality whereas its L-SNR reconstructed version will always be used to predict future frames. However, in packet-based transmission environments and under noisy channel conditions, some MBs in the decoded H-SNR frame or in the L-SNR frame may be lost. Thus, to efficiently utilize both H-SNR and L-SNR frames to recover some or all of the missing data, we have designed an MB combiner scheme, which will be described later.ME: Motion Estimation MC: Motion Compensation PFB: Previous Frame BufferiQ: Quantization by quantizer stepsizeiQ1−iQ: Dequatization by quantizer stepsize i QFigure 1. The proposed encoderFigure 2. The proposed decoderFigure 3. The proposed Multiple Description coding scheme using Interlaced High-SNR andLow-SNR framesFigure 3 shows the overall structure of the proposed scheme for transmission of coded bistreams via two channels. For the first frame, which has to be encoded in INTRA mode, low quantization step-size (i.e., H-SNR) is used for both bit-streams. The following frames are encoded in an interlaced manner using two different step-sizes Q1 and Q2, which results in H-SNR and L-SNR coded frames. As mentioned earlier, both H-SNR and L-SNR frames use the L-SNR reference frame for interframe prediction. This is to make sure that a loss of one frame (e.g., H-SNR or L-SNR frame) will not affect the decoding of the following frames. For example, if only the H-SNR frame is lost, the current frame can be decoded as the L-SNR frame without having any effect on decoding the following frames. On the other hand, if only an L-SNR frame is lost, the H-SNR frame can be decoded as an H-SNR frame. In the absence of the L-SNR frame, however, the H-SNR frame has to be re-quantized in order to recover an L-SNR reference frame for predicting its future frames.Figure 4. The effect of reset frame rate—“Foreman”, QCIF, 7.5fps, 100 frames, packet size=200 bytes, Q1=8, Q2=16Figure 5. The effect of reset frame rate—“Coastguard”, QCIF, 10fps, 100 frames, packet size=200 bytes, Q1=8, Q2=16It is obvious that by selecting the reconstructed L-SNR frame as the reference frame for both channels, the prediction error between the high-SNR frame and the low-SNR reference frame will grow larger as the prediction progresses. Consequently, this could result in an increased bitrate, which could even surpass that of the duplicate coder. To overcome this situation, the L-SNR reference frame changes to H-SNR reference frame (reset reference frame) for both channels once every N frames.To find the optimized reset reference frame rate, N, we evaluate the “Foreman” and “Coastguard” sequences (100 frames) with QCIF format for Q1=8 (H-SNR), Q2=16 (L-SNR). We change the reset reference frame rate from 1 (every frame is reset frame, just as the duplicate coder) to 100 (no reset frame). From Figure 4, we can see that for the “Foreman” sequence, when the reset rate is N = 5, the average bits per frame will be the lowest. That is, the reset rate of N = 5 can achieve the minimal redundancy rate. We can also observe that when the frequency of the reset is very low (e.g., always using the reconstructed L-SNR as the reference frame) the bit rate will exceed that of the duplicate coder. For the “Coastguard” sequence as depicted in Figure 5, we notice that N = 6 can achieve the minimal redundancy rate. However, if we set the reset rate to an even number, it will make the reset frames occur in one description and the average bits per frame of the two descriptions will consequently be very different due to the order of interlaced L-SNR and H-SNR frames in the proposed coding structure (Fig 3). For an odd number reset rate, the bitrates of the two descriptions are nearly the same. Therefore, in order to balance the bitrates, the reset reference frame rate, N, should be an odd number. Looking at both Figures we can see that N = 5 for both “Foreman” and “Coastguard” can provide the best results.In [15] a video packet-recovery scheme using redundant packets is considered. The redundant packet only transports the most sensitive information in a coded video frame, such as the header information and the motion vectors (MVs). If there are some losses, the information in the redundancy packet can be used to conceal the lost MBs. Based on the same concept, we use the MB combiner in order to make the decoder get the best quality decoded frame by concealing the effect of the missing MBs.The MB combiner works for two distinct cases. Case 1 assumes that some packets containing a number of MBs within the n th H-SNR frame are lost. In this case, the corresponding decoded MBs in the n th L-SNR frame are utilized to fill in the missing area. As a result, the modified decoded frame not only includes the decoded MBs from the H-SNR frame but also those were transferred from the L-SNR frame. Although there would be some degradation due to MBs replacement from the L-SNR frame, this cannotpropagate to the following frames. Bear in mind that both channels use the L-SNR frame as the reference frame.Case 2 is mainly concerned with losses in the first channel that could only affect the n th L-SNR frame. In this situation, the missing MBs do not affect the final decoded frame but they can degrade the reference frame. To prevent this, it would be necessary to use the reference frame from the H-SNR decoder (via re-quantization) to fill in the lost area in the n th L-SNR frame and thus, there would be no degradation at all. In a more undesirable situation, packets from both channels that share some of the same coded MBs in the n th frame may be lost. Under this condition, we can only estimate the MB by means of error concealment, which will be described in the results section.3. The simulation resultsWe simulated the proposed coder using the MPEG-4 Verification Model (without B frame option and the video packet size = 200 bytes). To evaluate the performance of the proposed MD Video Coding using a different quantization step-size for each description, we use the same test sequences: “Foreman” (QCIF, 7.5fps, and 100 frames) and “Coastguard” (QCIF, 10fps, and 100 frames). In addition, for the sake of comparison, we also designed a MD version of video redundancy coding (MD-VRC). Note that MD-VRC uses the same INTRA coded frame (i.e., frame 0) for both channels. For the remaining frames, the even-indexed frames and the odd-indexed frames are independently encoded for transmission over channel 1 and channel 2, respectively. Obviously, each channel uses its own reference frame for interframe prediction. In addition to the MDC-VRC, in our evaluations we have also included the performance of the original MPEG-4 coder (single description coder).In our first set of experiments, the same quantization step-size is used for Q1, i.e., Q1 = 8, whereas different step-sizes are selected for Q2, i.e., Q2 = 8 (i.e., duplicate encoder), Q2 = 16, and Q2 = 31 (note that 31 is the highest quantization step size that can be selected for the MPEG-4 encoder). Before evaluating each encoder under packet-loss transmission conditions, we first assess the rate distortion performance for one description in the absence of the other. Tables 1 and 2 show the rate distortion performance of different MD encoders for two sequences: “Foreman” and “Coastguard”. For convenience, the proposed encoders are labeled as MDC. It can be seen that when both descriptions are received, the PSNR values are very close to each other. Note that for Q2=8, the MDC behaves like a duplicate encoder. Its PSNR value is the same for one and two descriptions but with 100% added redundancy. The MDC with Q2=16 has slightly lower PSNRs for both one and two-descriptions but with a lower redundancy. Increasing the step-size from Q2 =16 to Q2 = 31 does not appear to have any impact on lowering the redundancy rate but its PSNR quality drops by a wider margin with one description. Although MDC-VRC has the lowest redundancy with a good two-descriptions PSNR, its average PSNR drops sharply in the absence of one description. This is mainly because of the reduced frame rate where the average PSNR is measured by repeating the missing frames. From these initial results, we can observe that the MDC (Q2=16) encoder can provide the best trade off between the redundancy rate and the quality. Therefore, this encoder will be used as our candidate MDC for further evaluations.Table 1. Redundancy rate distortionperformance of different MD coders –“Foreman”C ODERS MDC(Q2=8)MDC(Q2=16)MDC(Q2=31)MDC-VRC Redundancy (%) 100.00 85.09 85.12 26.44 Two-descriptionPSNR (dB) 33.00 32.73 32.72 32.74Average one-descriptionPSNR (dB)33.00 31.21 30.69 22.45Table 2. Redundancy rate distortionperformance of different MD coders –“Coastguard”C ODERS MDC(Q2=8)MDC(Q2=16)MDC(Q2=31)MDC-VRC Redundancy (%) 100.00 79.69 80.33 33.03 Two-descriptionPSNR (dB) 32.10 31.93 31.95 31.75Average one-descriptionPSNR (dB)32.10 30.15 29.62 24.73To evaluate the relative performance of the encoders in more realistic environments, we first ran a series of tests where packets in both bit-streams are discarded using the packet-loss statistics of [17], corresponding to 3%, 5%, 10%, and 20% packet-loss rates. These four error pattern files are used to simulate the Internet backbone (IP networks) performance for video coding experiments.Figure 6. Test Scenario structure Secondly, we evaluate the performance of theseMDC schemes using our mobile ad-hoc network testbed, which had been implemented utilizing the QualNet (Version 3.7) simulation tool. In this testbed, we considered the IEEE 802.11b standard and the DSR routing protocol [18]. However, since our objective is to evaluate the performance of MDC schemes, any discussion about multipath routing protocol aspects developed in our testbed is beyond the scope of this paper. Figure 6 shows our dual-path test scenario where nodes are not equally spaced and the communication is from node s to node d. In these experiments, the transmission power is 8.5 dBm, the receiver sensitivity is –93.0 dBm, the IEEE 802.11b data-rate is 2 Mb/s and the noise factor is 10.0. For simplicity, we assume that there’s no fading and the path loss model is free space. Also, by adjusting the distance between neighboring nodes, we are able to achieve packet loss rates of 3%, 5%, 10%, and 20%, respectively. Note that in a point-to-point CSMA/CA multihop communication, packets are continually competing to access the media in their shared collision domains and this can significantly affect the end-to-end packet loss performance [15], [16], [19].Figure 7. Objective quality comparison ofdifferent encoders over IP networks—“Foreman”, the bit rate is 144kbps.Figure 8. Objective quality comparison ofdifferent encoders over IP networks—“Coastguard”, the bit rate is 144kbps.For fair comparison, we made sure that all the schemes are compared at the same average bitrate, which is achieved by adjusting quantization step-sizes. For the proposed MDC, this is done by changing the quantization step-size, Q1, in such a way that the overall bitrate for both descriptions will remain the same when Q2= 16 is selected. In addition, the MB combiner that plays a crucial role in data recovery has been deployed. Bear in mind that if losses from both channels include the same data the decoder uses a simple error concealment algorithm. For the first frame (I-frame) a simple pixel interpolation algorithm is used to conceal the effect of missing MBs, whereas the following frames use the corresponding MBs from the previous frame. The same error concealment has also been used for the SDC encoder. For the MDC-VRC coder, we use the most adjacent frame to conceal the effect of missing packets (note that the first frame also uses pixel interpolation error concealment). We should point out that all the encoders use a random INTRA block refresh at the rate of 10%. In addition, the average PSNR values are measured by running each experiment 25 times. That is, a total of 2500 frames are tested for the final results.Figure 9. Objective quality comparison ofdifferent encoders over ad-hoc wireless networks—“Foreman”, the bit rate is 144kbpsFigure 10. Objective quality comparison of different encoders over ad-hoc wirelessnetworks—“Coastguard”, the bit rate is144kbps.Figure 7 and Figure 8 show the objective quality comparison of the three encoders over IP networks for “Foreman” and “Coastguard”, respectively. As shown in these figures although the SDC encoder can achieve a much higher PSNR in an error-free case, its PSNR quality degrades rapidly with the increasing packet-loss rates. MDC-VRC can obtain a little improvement over the SDC coder in packet-loss circumstances. For “Foreman”, only a 0.3-1.2 dB improvement can be observed. For “Coastguard” the improvement is even more minimal. For our proposed MDC coder, a much more graceful PSNR degradation can be observed compared with the other two coders and can get 3.5-6 dB improvement in packet-loss circumstances. Figure 9 and Figure 10 show the objective quality comparison of the three encoders over ad-hoc wireless networks for “Foreman” and “Coastguard,” respectively. The similar results can be observed. However, a more graceful degradation can be seen for the proposed coder due to the higher burst packet loss in ad-hoc networks, which can be processed easier by the proposed MDC coder.4. ConclusionIn this paper, we proposed a multiple description video-coding scheme, which uses interlaced H-SNR and L-SNR frames to produce two bit-streams (descriptions). In contrast with other MD encoders, this scheme is based on a temporal information division. In order to minimize the effect of error propagation, both channels always use the L-SNR frames as the reference frame (except the following frame of the reset reference frame, for which both channels use the H-SNR frames). This is to ensure that if only one description is lost, at any given time, it will not affect the decoding of the following frames. The decoder also takes advantage of the MB combiner scheme to improve the data recovery process. The proposed MDC scheme is then compared with the modified VRC coder, which is referred to as MDC-VRC, and the SDC MPEG-4 encoder in two test scenarios. One is assuming that only one description is received and the other one assumes both descriptions suffer from packet losses. Under both test scenarios it has been shown that the proposed MDC can greatly outperform the MDC-VRC and SDC. Moreover, it should be noted that although we realized our MDC scheme based on the MPEG-4 coder, it can also be used on other coders, such as H.263, MPEG-2, and so on.5. AcknowledgmentThe authors would like to thank Dr. Bo Yan for his help in developing mobile ad-hoc network testbed for generating error pattern files. 6. References[1] S. Mao, S. Lin, S. S. Panwar, Y. Wang, and E. Celebi, “Video transport over ad hoc networks: multistream coding with multipath transport,”IEEE J. Select. Areas Commun.,vol. 21, pp. 1721-1737, Dec. 2003.[2] L. Ozarow, “On a source coding problem with two channels and three receivers,” Bell Syst. Tech. J., vol. 59, pp. 1909–1921, Dec. 1980.[3] V. A. Vaishampayan, “Design of multiple description scalar quantizer,” IEEE Trans. Inform. Theory, vol. 39, pp. 821–834, May 1993.[4] Y.Wang, M. Orchard, and A. R. Reibman, “Optimal pairwise correlating transforms for multiple description coding,” in Proc. ICIP98, Oct. 1998.[5] H. Jafarkhani and V. Tarokh, “Multiple description trellis coded quantization,” IEEE Trans. Commun., vol. 47, pp. 799–803, June 1999.[6] Y. Wang, M. Orchard, V. Vaishampayan, and A. R. Reibman, “Multiple description coding using pairwise correlating transforms,” IEEE Trans. Image Processing, vol. 10, pp. 351–366, Mar. 2001.[7] V. K. Goyal, J. Kovacevic, R. Arean, and M. Vetterli, “Multiple description transform coding of images,” in Proc. ICIP98, Oct. 1998.[8] W. Jiang and A. Ortega, “Multiple description coding via polyphase transform and selective quantization,” in Proc. VCIP 99, Feb. 1999.[9] V. K. Goyal, “Multiple description coding: Compression meets the network,” IEEE Signal Processing Mag., vol. 18, pp.74-93, Sep. 2001.[10] Y. Wang, A. Reibman, and S. Lin, “Multiple description coding for video delivery,” Proceedings of the IEEE, vol. 93, pp. 57-70, Jan. 2005.[11] A. Reibman, H. Jafarkhani, Y. Wang, M. Orchard, and R. Puri, “Multiple description coding for video using motion compensated temporal prediction,” IEEE Trans. Circuits Syst. Video Technol., vol. 12, pp. 193–204, Mar. 2002. [12] Y. Wang, C. Wu, “Low Complexity Multiple Description Coding Method for Wireless Video,” in Proc. AINA05, vol. 02, pp. 95-98, Mar. 2005.[13] S.Wenger, “Video redundancy coding in H.263+,” in Proc. AVSPN, Aberdeen, U.K., Sept. 1997.[14] J. G. Apostolopoulos, “Error-resilient video compression through the use of multiple states,” in ICIP00, vol. 3, pp. 352-355, 2000.[15] H. Gharavi and K. Ban, “Dynamic Adjustment Packet Control for Video Communications over Ad-hoc Networks,” in Proc. ICC04, Paris, France, June 2004.[16] H. Gharavi, “Control Based Mobile Ad-hoc Networks For Video Communications,” IEEE Trans. Consumer Electronics, vol. 52, no. 2, May 2006.[17] S. Wenger, “Error patterns for Internet experiments,” ITU Telecommunications Standardization Sector, Red Bank, NJ, Doc. Q15-16r1, Oct. 1999.[18] D. B. Johnson and D. A. Maltz, “Dynamic Source Routing in Ad-Hoc Wireless Networks”, In Mobile Computing, edited by T. Imielinski and H. Korth, Chapter 5, pp. 153-181, Kluwer Academic Publishers, 1996.[19] B. Yan, and H. Gharavi, ”Multi-path Multi-Channel Routing Protocol,” in Proc. IEEE NCA06, July 2006.。