WO2017020021A1 - Codage vidéo à haute efficacité extensible pour transcodage de codage vidéo à haute efficacité - Google Patents

Codage vidéo à haute efficacité extensible pour transcodage de codage vidéo à haute efficacité Download PDF

Info

Publication number
WO2017020021A1
WO2017020021A1 PCT/US2016/044909 US2016044909W WO2017020021A1 WO 2017020021 A1 WO2017020021 A1 WO 2017020021A1 US 2016044909 W US2016044909 W US 2016044909W WO 2017020021 A1 WO2017020021 A1 WO 2017020021A1
Authority
WO
WIPO (PCT)
Prior art keywords
bitstream
ilr
transcoding
depth
processor
Prior art date
Application number
PCT/US2016/044909
Other languages
English (en)
Inventor
Srinivas GUDUMASU
Yuwen He
Yan Ye
Original Assignee
Vid Scale, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vid Scale, Inc. filed Critical Vid Scale, Inc.
Publication of WO2017020021A1 publication Critical patent/WO2017020021A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/40—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video transcoding, i.e. partial or full decoding of a coded input stream followed by re-encoding of the decoded output stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/136—Incoming video signal characteristics or properties
    • H04N19/14—Coding unit complexity, e.g. amount of activity or edge presence estimation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H04N19/147—Data rate or code amount at the encoder output according to rate distortion criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/187—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a scalable video layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability

Definitions

  • Digital video services may refer to TV services over satellite, cable and/or terrestrial broadcasting channels.
  • Video coding support for high resolutions such as high definition (HD), fullHD, ultra-HD (UHD) in consumer devices may be useful.
  • Video distribution over the internet may promote efficient video coding algorithm development.
  • High Efficiency Video Coding is a video compression standard jointly developed by The International Telecommunication Union (ITU-T) Video Coding Experts Group (VCEG) and ISO/IEC Moving Picture Experts Group (MPEG) together.
  • ITU-T International Telecommunication Union
  • VCEG Video Coding Experts Group
  • MPEG Moving Picture Experts Group
  • HEVC supports different picture partition strategies such as slices, wave-front parallel processing (WPP) and tiles.
  • Systems, methods, and instrumentalities are provided for reusing coding information extracted from scalable HEVC (SHVC) bitstream during transcoding process, refining the coding information, and/or using the refined coding information in transcoding.
  • a complexity adaptive SHVC to HEVC transcoder using one or more transcoding modes may be used. The complexity of the transcoding may be reduced by a good trade-off with the video quality. Some of information such as depth, encoding mode, merge mode, motion information, intra-direction information, and/or transform unit (TU) depth information from the SHVC decoder may be reused.
  • the content may be transcoded with a single layer HEVC encoder.
  • Transcoding can include reusing encoder coding tree unit coding information from SHVC bitstream, and/or refining the coding information extracted from the bitstream and/or using those refined coding information in transcoding.
  • a refined search range for motion estimation may be applied using the motion information obtained from SHVC bitstream coding parameters.
  • a first bitstream such as an SHVC bitstream that may include a base layer (BL) and an enhancement layer (EL) may be received.
  • Coding information such as coding unit depth, coding unit prediction mode, motion information, intra direction mode, and/or TU depth may be extracted from the first bitstream.
  • the first bitstream can be transcoded into a second bitstream (e.g., such as an HEVC bitstream) by reusing at least part of the extracted coding information.
  • the transcoder may be configured with various complexity transcoding modes such as high, medium, and/or low based on application requirements.
  • the transcoder can (e.g., adaptively) select a coding information reuse transcoding mode from a plurality of transcoding modes, perhaps for example based on one or more video signal characteristics.
  • a transcoding device may comprise a memory and/or a receiver.
  • the receiver may be configured to receive a first bitstream.
  • the first bitstream may include information regarding a base layer (BL) of one or more video frames.
  • the device may include a processor.
  • the processor may be configured to decode the BL to produce one or more BL frames of the one or more video frames.
  • the processor may be configured to predict at least one enhancement layer (EL) frame of the one or more video frames from the one or more BL frames of the one or more video frames.
  • the processor may be configured to extract one or more parameters from the at least one EL frame of the one or more video frames.
  • the one or more parameters may include a coding unit (CU) depth.
  • the processor maybe configured to encode at least a part of a second bitstream with a single layer of the one or more video frames using the one or more parameters.
  • the second bitstream may be a single layer bitstream.
  • a transcoding device may comprise a memory and/or a receiver.
  • the receiver may be configured to receive a first bitstream.
  • the first bitstream may include information regarding a base layer (BL) of one or more video frames.
  • the device may include a processor.
  • the processor may be configured to decode the BL to produce one or more BL frames of the one or more video frames.
  • the processor may be configured to predict at least one enhancement layer (EL) frame of the one or more video frames from the one or more BL frames of the one or more video frames.
  • the processor may be configured to extract one or more parameters from the at least one EL frames of the one or more video frames.
  • EL enhancement layer
  • the one or more parameters may include one or more transform unit (TU) depths, one or more coding unit (CU) partition sizes, one or more reference picture indexes, one or more motion vectors, or merge mode information.
  • the processor may be configured to encode at least a part of a second bitstream with a single layer of the one or more video frames using the one or more parameters.
  • the second bitstream may be a single layer bitstream.
  • FIG. 1 is a diagram of example HTTP based video streaming.
  • FIG. 2 is a diagram of an example of a block-based video encoder.
  • FIG. 3 illustrates example modules in video playback.
  • FIG. 4 is a diagram of an example of a block-based video decoder.
  • FIG. 5 illustrates example prediction unit modes in HEVC.
  • FIG. 6 shows an example scalable video coding system with N layers.
  • FIG. 7 shows an example hierarchical coding structure in HEVC.
  • FIG. 8 shows an example coding tree unit (CTU) structure of a frame.
  • CTU coding tree unit
  • FIG. 9 shows example inter coding unit(s) (CUs).
  • FIG. 10 shows example mixed CU(s).
  • FIG. 11 shows example intra coded interlay er reference (ILR) coding units CU(s).
  • ILR intra coded interlay er reference
  • FIG. 12 shows an example mixed ILR CU(s).
  • FIG. 13 shows example rate distortion (RD) performance comparison of Park Scene bitstream with single layer (SL) encoding, re-encoding, partial depth reuse and full depth reuse.
  • RD rate distortion
  • FIG. 14 shows example RD performance comparison of Park Scene bitstream between mode motion vector (MV) reuse and ILR CU MV reuse.
  • FIG. 15 shows example RD performance comparison of Park Scene bitstream between mode MV reuse, ILR CU MV reuse and Intra direction mode reuse.
  • FIG. 16 shows example RD performance comparison of Park Scene bitstream between mode MV reuse, ILR CU MV reuse, intra direction mode reuse and transform units (TU) depth reuse.
  • FIG. 17 shows example available neighbor PU(s) of a collocated prediction unit (PU) in ILR picture.
  • FIG. 18 shows example RD performance comparison of Park Scene bitstream between mode MV reuse, ILR CU MV reuse, Intra direction mode reuse TU depth reuse and MV refinement.
  • FIG. 19 shows example adaptive transcoding mode selection.
  • FIG. 20 shows example RD performance comparison between re-encoding, low/medium/high complexity transcoding modes (Basketball drive 1080P 1.5x spatial resolution bitstream with ELQP22, BLQP-22).
  • FIG. 21 shows example RD performance comparison between re-encoding, low/medium/high complexity transcoding modes (Park Scene 1080P 1.5x spatial resolution bitstream with ELQP22, BLQP-22).
  • FIG. 22A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.
  • FIG. 22B is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 21A.
  • WTRU wireless transmit/receive unit
  • FIG. 22C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 21A.
  • FIG. 22D is a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 21A.
  • FIG. 22E is a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 21A.
  • Figure 1 shows an example HTTP based video streaming system.
  • the captured content may be compressed and/or chopped into small segments.
  • the segment period may be between 2 and 10 seconds in many or most streaming systems, for example.
  • Those segments may be stored in HTTP streaming server and/or distributed via content delivery network (CDN).
  • CDN content delivery network
  • Figure 2 is a block diagram of a generic block-based single layer video encoder that can, for example, be used to generate bitstreams for streaming system in Figure 1.
  • a layer e.g., single layer
  • the encoder may include one or more mode decision logics that may choose a suitable form of prediction, for example, based on one or more criterion such as a combination of rate and/or distortion considerations.
  • the encoder may transform and/or quantize the prediction residual (e.g., the difference signal between the input signal and the prediction signal).
  • the quantized residual perhaps for example with the mode information (e.g., intra and/or inter prediction) and/or prediction information (e.g., motion vectors, reference picture indexes, intra prediction modes, etc.) may be further compressed at the entropy coder and/or may be packed into the output video bitstream.
  • the encoder may generate the
  • the reconstructed video signal may go through one or more loop filter (LF) process (for example, deblocking filter (DB), Sample Adaptive Offsets (SAO), and/or Adaptive Loop Filters (ALF).
  • LF loop filter
  • the reconstructed video signal may be stored in the reference picture store and for example may be used to predict future video signal(s).
  • Figure 3 is a block diagram of an example video playback system.
  • the system may include a receiver, a decoder and/or a display (renderer).
  • Figure 4 is a block diagram of an example block-based single layer decoder that may receive a video bitstream produced by the encoder in Figure 2 and/or may reconstruct the video signal to be displayed.
  • the bitstream may be parsed by the entropy decoder.
  • the residual coefficients may include inverse quantized and/or inverse transformed to obtain the reconstructed residual.
  • the coding mode and/or prediction information may be used to obtain the prediction signal using spatial prediction and/or temporal prediction.
  • the prediction signal and/or the reconstructed residual may be added together to get the reconstructed video.
  • the reconstructed video may go through loop filtering, perhaps for example before being stored in the reference picture store to be displayed and/or to be used to decode future video signal.
  • HEVC is a block based hybrid video coding standard.
  • quadtree partition may be used to signal block coding information.
  • the picture and/or slice may be partitioned into one or more coding tree units (CTU) with the same size (e.g., 64x64).
  • CTU coding tree units
  • a CTU may be partitioned into one or more coding units (CU) with quadtree, and/or a CU may be partitioned further into prediction units (PU) and/or TUs, perhaps for example also with quadtree-based partition.
  • PU prediction unit
  • its prediction unit (PU) can be one of 8 partition modes, as shown in Figure 5.
  • the encoding process for inter-picture prediction may include choosing motion data comprising the selected reference picture and/or motion vector(s) (MV) to be applied for predicting the samples of a block.
  • the encoder and/or decoder may generate identical inter-picture prediction signals by applying motion compensation (MC) using the MV and/or mode decision data, which may be transmitted as part of the bitstream.
  • MC motion compensation
  • one or more linear filters may be applied to obtain pixel values at fractional positions.
  • the interpolation filters may be associated with 7 or 8 taps for luma and 4 taps for chroma, for example.
  • the residual signal of the intra or inter picture prediction may be transformed by a linear spatial transform.
  • the transform coefficients may be scaled, quantized, entropy coded, and/or transmitted together with the prediction information.
  • the encoder may duplicate the decoder processing loop, perhaps for example such that either may generate (e.g., identical) predictions for subsequent data.
  • the quantized transform coefficients may be constructed by inverse scaling and/or may be inverse transformed to generate the decoded approximation of the residual signal.
  • the residual may be added to the prediction.
  • the result may be fed to deblocking (DB) and/or SAO may filter to smooth out artifacts induced by block-wise processing and quantization.
  • the final picture representation may be stored in a decoded picture buffer, perhaps for example to be used for the prediction of subsequent pictures.
  • the deblocking filter in HEVC may be content based. For example, different deblocking filter operations may be applied at the TU and/or PU boundaries, perhaps for example depending on one or more actors, such as coding mode difference, motion difference, reference picture difference, and/or pixel value difference, etc.
  • CABAC context- based adaptive binary arithmetic coding
  • By-pass coding e.g., a special case in CABAC coding
  • Video data may be transmitted over a combination of wired networks and/or wireless networks. This may complicate the underlying transmission channel characteristics.
  • the premise of scalable video coding may improve the quality of experience for video applications running on devices with different capabilities over heterogeneous networks.
  • Scalable video coding may encode the signal once at highest representation (temporal resolution, spatial resolution, quality, etc.), and/or may enable decoding from subsets of the video streams, perhaps for example depending on the specific rate and/or representation required by certain applications running on specific client device. It can save backbone network bandwidth and/or storage compared to non- scalable solutions.
  • the international video standards MPEG-2 Video, H.263, MPEG4 Visual and H.264 may have tools and/or profiles that support some modes of scalability.
  • FIG. 6 is a block diagram of a simple block-based hybrid scalable video encoding system.
  • the spatial/temporal signal resolution to be represented by the layer 1 (BL) may be generated by down-sampling of the input video signal.
  • a setting of the quantizer (Ql) may lead to a certain quality level of the base information.
  • the base-layer reconstruction Yl an approximation of the higher layer resolution levels, can be utilized in the encoding/decoding of the subsequent layers.
  • the up-sampling unit may perform up-sampling of the BL reconstruction signal to layer-2's resolution. Down-sampling and/or up- sampling can be performed throughout the layers (1, 2... N).
  • Downsamping and/or upsampling ratios may be different depending on the dimension of the scalability between two given layers.
  • differential signal may be generated by subtracting an upsampled lower layer signal (e.g., layer n-1 signal) from the current layer n signal.
  • the difference signal obtained may be encoded.
  • the corresponding down-sampling and/or up-sampling operations may be by -passed.
  • a given layer n (l ⁇ n ⁇ N) and/or a plurality of layers can be decoded without using decoded information from higher layers. Coding of the residual signal (e.g., difference signal between two layers) can be relied on for one or more layers, perhaps for example except the BL.
  • the residual signal may be quantized and/or normalized to restrict its dynamic range. Additional quantization may be performed during coding of the residual.
  • Some or all of the higher layer encoders may adopt motion estimation and/or motion compensated prediction as an encoding mode.
  • Standards scalability capability may refer to the type of scalability when the BL may be encoded with an earlier standard such as H.264/AVC, and/or MPEG2.
  • the one or more ELs may be encoded using a more recent standard, such as the HEVC standard.
  • Standards scalability may provide backward compatibility for legacy content that may already be encoded using previous standards and/or may enhance the quality of the legacy content with one or more ELs encoded with upcoming standards like HEVC that provides better coding efficiency.
  • Scalability types may include, but not limited to, aspect ratio scalability, bit-depth scalability, color gamut scalability, and/or chroma format scalability are tied to the BL and EL video formats.
  • bit depth scalability the BL video may be in 8 bits, whereas the EL video may be higher than 8-bit.
  • color gamut scalability the BL video may be color graded in BT.709 color gamut.
  • the EL video may be color graded in BT.2020 color gamut.
  • chroma format scalability the BL video may be the YUV4:2:0 format widely used by consumer video applications.
  • the EL video may be in YUV4:2:2 or YUV4:4:4 format.
  • Scalable HEVC video content can be transcoded to (e.g., single) layer video content and/or can be transmitted to the client devices.
  • the transcoded video content may have reduced bitrate with (e.g., minimal) quality loss perhaps for example when compared with the SHVC bitstream.
  • a (e.g., simple) drift free transcoding could be achieved by cascading a decoder and/or an encoder (e.g., also referred to as pixel-domain transcoding).
  • the video may be encoded with regards to target platform specifications.
  • Transcoding may reduce the complexity by reusing the information in the existing bitstream while keeping the quality.
  • the information for conversion may be extracted by fully or partially decoding.
  • the information may be re-coded in another format (e.g., efficiently).
  • a video transcoding could be open-loop or closed-loop. In open-loop architecture, transcoding may be performed without the reconstruction loop.
  • a video picture may be transcoded without buffering. The next picture may be transcoded independently from previous pictures. Closed-loop transcoding may reconstruct pictures and/or may use a buffer to store pictures for future pictures transcoding. Transcoding can be carried out in pixel domain, transform domain, and/or in hybrid domain.
  • Pixel-domain transcoding may reuse motion vectors such that the most time consuming operation can be skipped.
  • Motion vector calculations may account for up to 70% of the calculations of encoders.
  • Transcoding may be carried out in pixel domain by decoding the bit-stream, inverse quantization, inverse transforms, and/or motion compensation, and reapplying them.
  • the coding mode and/or motion vector can be reused directly and/or refined depending on the application requirement. Transcoding in pixel-domain can be drift free.
  • the input bit-stream may be decoded and/or inverse quantized.
  • Re-quantization may be performed with different parameters in transform- domain.
  • Motion data may be reused.
  • the transcoding can be performed through quantization of higher frequencies and/or keeping the old motion data.
  • Hybrid-domain transcoding may be a combination of pixel and transform-domain architectures. Pixel-domain architecture can be drift-free. Transform-domain architecture may require less computation. Hybrid-domain transcoding may exploit the benefits of, one or more, or each transcoding. For example, non-reference pictures of a video bit-stream could be transcoded in transform-domain, perhaps for example since the error generated in those pictures might not propagated to future coded pictures. Reference pictures may be transcoded in pixel- domain to maintain accurate prediction.
  • the service providers can reuse the existing internet infrastructure as is, and may try to store and/or provide the scalable HEVC video coding content to the end users.
  • the bitstreams of ELs together with the bitstream of base-layer may be downloaded.
  • Transcoding scalable bitstream to single layer coded bitstream can relieve the burden of network. Transcoding may include (e.g., fully) decoding and/or encoding the content based on the characteristics of the end client.
  • Encoders may be considered for optimizing coding efficiency, perhaps for example while maintaining a certain video quality, measured with objective quality metrics such as peak signal to noise ratio (PSNR), video quality metric VQM, structural similarity index (SSIM), and/or measured subjectively with human observers.
  • PSNR peak signal to noise ratio
  • VQM video quality metric
  • SSIM structural similarity index
  • a complexity adaptive SHVC to HEVC transcoder using one or more, or various, transcoding modes may be used.
  • the complexity of the transcoding may be reduced by a (e.g., good) trade-off with the video quality.
  • Some of information such as depth, encoding mode, merge mode, motion information, intra-direction information, and/or TU depth information from the SHVC decoder may be reused.
  • the content may be transcoded with a single layer HEVC encoder.
  • the high computational complexity of HEVC encoder for mode decision of P/B frames may arise due to different possible combinations of block sizes for every CTU.
  • One or more, or every, CU may have different modes for one or more, or every, block, as well as motion estimation for one or more, or each, prediction unit of one or more, or every, inter-mode with different partitions.
  • Information extracted from the SHVC bitstream may be utilized.
  • Early termination may be applied for the block sizes (e.g., one or more, or each, of the block sizes) perhaps for example, based on the corresponding CTU/frame coding parameters information obtained from the SHVC decoder.
  • Motion estimation may involve a full search, and/or an Enhanced Predictive Zonal Search (EPZS).
  • Full search and/or EPZS may apply a fixed search range while encoding.
  • a refined search range for motion estimation may be applied, perhaps for example using the motion information obtained from SHVC bitstream coding parameters.
  • the motion information from SHVC decoder may be reused in transcoding.
  • Some PUs may be coded using inter-layer reference (ILR) pictures as reference in SHVC bitstream.
  • ILR inter-layer reference
  • a transcoder can be a high latency, high complexity, and/or high performance transcoder (HL-HCHP).
  • An encoder may queue one group of pictures (GOP) of frames from the video decoder EL output and/or may transcode in hierarchical coding structure.
  • Low latency, high complexity, and/or high performance transcoder (LL-HCHP) can function in such a way that encoder may fetch a frame from the decoder in decoding order and/or may present it for encoding (e.g., immediately).
  • the encoder can follow the same GOP structure as in the bitstream.
  • the decoder can output the reconstructed YUV data frames as in decoding order.
  • the transcoding optimization can include reusing encoder coding tree unit coding information from SHVC bitstream during transcoding process.
  • the transcoding optimization can include refining the coding information extracted from the bitstream and/or using those refined coding information in transcoding.
  • Coding information reuse can be applied.
  • CTU coding information from the SHVC bitstream may be extracted and/or reused (e.g., in low latency, low complexity, high performance (LL-LCHP) transcoding).
  • Such frame/CTU coding information may include CU depth, CU prediction mode, motion information including merge mode information reuse, intra direction mode, and/or TU depth.
  • one or more, or some PUs at the one or more EL may use the ILR picture as reference generated from the reconstructed picture at BL, which may be different from those one or more, or some PUs coded with inter-prediction mode using temporal reference pictures.
  • these kind of CUs may be referred to as inter-layer reference CU (ILR CU).
  • the PU within the CU at EL may use the ILR picture as reference, and/or it can be referred to as inter-layer reference PU (ILR PU).
  • CUs can be classified into categories, such as inter CUs, intra CUs, mixed CUs, and/or and ILR CUs.
  • inter CUs e.g., all PUs
  • ILR CUs ILR CUs.
  • the PUs e.g., all PUs
  • the CU may be referred to as inter CU as shown in Figure 9.
  • Those CUs coded using intra prediction mode at EL in SHVC bitstream may be referred to as intra CUs.
  • the CU may be referred to as mixed CUs as shown in Figure 10.
  • ILR CU can be classified into one or more categories, such as intra coded ILR CU and/or mixed ILR CU.
  • the PUs e.g., all PUs
  • the CU e.g., as shown in Figure 11
  • intra coded ILR CU the CU
  • the ILR CU may be referred to as a mixed ILR CU.
  • CU depth information may be reused.
  • the transcoder may recursively traverse the CTU till the CU depth (CUDec) extracted from EL in the input bitstream is reached.
  • the corresponding CU in transcoder may be transcoded by re-using the input CUDec coding information.
  • the input CTU structure may be replicated in the transcoded CTU.
  • CU depth may be partially and/or fully reused.
  • Figure 8 shows an example CTU structure of an SHVC EL bitstream.
  • the depth of a CU can be denoted by Dx with x being equal to the depth. Coding prediction modes are shown as INTRA and INTER.
  • the prediction unit partition sizes are shown as 2NX2N, NXN, 2NXnU, nLX2N and so on.
  • the transcoder may start with the root node with the largest CU size as 64X64.
  • the transcoder may extract the CU split flag information from the corresponding CTU at EL in SHVC bitstream.
  • a transcoder may reuse this CU depth information.
  • the transcoder may extract the CU depth information from the SHVC bitstream and/or may reuse that information during encoding.
  • Transcoder may recursively traverse the CTU till the depth extracted from EL in the input bitstream is reached.
  • the transcoder may restrict the coding CU depth to the CU depth value obtained from the input bitstream such that:
  • the transcoder may transcode for the nodes (e.g., all nodes) till the depth specified in the input bitstream is reached and/or may choose the one based on rate-distortion optimization (RDO) cost.
  • RDO rate-distortion optimization
  • the transcoder may recursively traverse the CTU till the depth from the EL in the SHVC bitstream is reached.
  • the transcoder might not check RD cost at those depths smaller than the depth coded in the collocated block position in the input bitstream.
  • Full CU depth reuse mode can reduce the transcoding complexity without losing much quality.
  • Table 2 shows the transcoding results of "Park Scene” bitstream (1.5x scaling ratio with BL 720P and EL 1080P spatial resolutions) with EL QP as 22 and BL QP as 22.
  • Figure 13 shows the RD performance of the SHVC transcoder comparing the re-encode with CU depth reuse including partial CU depth reuse mode and full CU depth reuse mode.
  • the transcoding complexity has been reduced by about 70% without having any significant performance loss compared with LL-HCHP (e.g., re-encoding).
  • This CU depth reuse may be combined with other optimization techniques to further reduce the transcoding complexity.
  • Prediction mode (e.g., inter or intra mode of CU) may be reused in transcoding.
  • the transcoder may (e.g., fully) reuse CU depth information along with the prediction mode obtained from the SHVC bitstream to encode the corresponding CU.
  • the transcoder may recursively traverse the CTU till the CU depth obtained from corresponding block at EL is reached and/or may encode the CUs (e.g., one or more, or each CU) with the coding mode provided by SHVC bitstream.
  • Intra coded ILR CUs as shown in Figure 11 may be transcoded in intra mode.
  • the other ILR CUs may be transcoded in inter mode (e.g., only) and/or in a better mode from inter and/or intra mode based on RDO cost.
  • Motion and/or merge mode information may be reused in transcoding.
  • merge mode information and/or motion information may be reused for inter coded CUs. This may be applied to CUs in EL, which may be coded using inter prediction mode, and the PUs may use enhancement later temporal pictures as reference pictures.
  • the transcoder may extract the motion information including CU partition size information, reference picture index used for motion compensation, and/or motion vector of a PU from the EL corresponding block in input bitstream.
  • the transcoder may reuse the information during inter prediction coding by avoiding inter prediction search of the corresponding CU.
  • the transcoder may reuse (e.g., directly reuse) the prediction mode information in the bitstream for the current CU transcoding.
  • Inter coded CUs as shown in Figure 9 may reuse merge information from the SHVC bitstream during transcoding, for example.
  • Merge mode can save the number of bits.
  • Motion vector related information such as the index of MV predictor (MVP) and/or the difference (MVD) between MV and MVP can be inferred at decoder side.
  • MVP index of MV predictor
  • MVD difference between MV and MVP
  • the transcoder may select the merge mode for transcoding. If the motion information in SHVC bitstream matches with one or more of the merge candidates of current PU in transcoding, RD cost calculation may be performed with the matched one. The other merge candidates may be skipped. If the motion information from the input bitstream does not match with any of the merge candidates, RD cost calculation may be performed for the merge mode candidates, perhaps for example along with motion information obtained from the SHVC bitstream. For example, the candidate may be selected for transcoding based on RDO cost.
  • ILR CU MV may be reused in transcoding.
  • the transcoder may reuse motion information from the ILR picture for the EL CUs, perhaps for example if motion information is present at the collocated block in ILR picture.
  • the motion information from the ILR picture may be extracted and/or may be reused during the transcoding.
  • the PU(s) e.g., all the PU(s)
  • the referenced CU in ILR picture are coded as intra as shown in Figure 11, that CU may be transcoded in intra mode.
  • Table 3 shows the results of SHVC Park Scene bit stream (with EL-QP 22 and BL-QP 22) transcoding when reusing the ILR CU MV. The results shown are using the coding information and input YUV bitstream for prediction from the original bitstream (EL-QP 22, BL- QP 22).
  • Figure 14 shows the RD performance curves of the SHVC transcoder comparing the MV reuse with ILR CU MV reuse.
  • Table 3 Example Performance comparison of Park Scene bitstream between MV reuse and ILR CU MV reuse
  • Intra-direction mode may be reused in transcoding.
  • the transcoder may extract the intra direction information from the input SHVC bitstream and/or may reuse it to transcode the corresponding CU at the depth of corresponding CU in SHVC EL. This may be applied in combination with (e.g., on top of) the ILR CU MV reuse process described herein.
  • the transcoder may extract the intra direction information from the SHVC bitstream for intra predicted CUs and/or may reuse the direction mode during intra prediction. Intra prediction search for the other direction modes may be bypassed.
  • Intra direction mode may be reused for temporal layer 1/2/3 pictures transcoding.
  • intra direction mode search may be performed for the one or more possible modes.
  • a suitable mode or modes may be selected.
  • Intra direction mode may be reused for inter slices (e.g., one or more, or all, inter slices).
  • the intra slices may be re-encoded (e.g., fully encoded).
  • intra direction mode information may be reused for transcoding of intra CUs in inter slices.
  • intra direction mode search may be performed for one or more possible modes. A suitable mode or modes may be selected.
  • Intra direction mode may be reused for intra coded CUs (e.g., one or more, or all, intra coded CUs).
  • intra direction mode information may be reused for inter slices and/or intra slices.
  • intra direction information might not be present in SHVC bitstream EL.
  • Intra direction mode information from BL may be reused during transcoding of this picture.
  • intra direction mode information might not be present in SHVC bitstream EL, for example as it may be inter coded.
  • the direction information from BL picture can be reused in transcoding, perhaps for example when intra direction mode information is absent in EL, and/or perhaps for example if the corresponding block in reference picture is coded in intra mode.
  • Table 4 shows the results of SHVC Park Scene bit stream (with EL-QP 22 and BL-QP 22) transcoding with the intra direction mode information reuse.
  • Intra direction mode information reuse has reduced the complexity of the transcoder by around 30-35% with a slight decrease in performance as shown in Table 4 when compared with ILR CU MV reuse.
  • Figure 15 shows the RD performance curves of the transcoder comparing the MV reuse, ILR CU MV reuse and Intra direction mode information reuse.
  • TU depth may be reused in transcoding.
  • the transcoder may determine the depth of CU transform unit based on the SHVC bitstream and/or may reuse it during RDO calculation of the corresponding CU.
  • TU depth reuse may be applied in combination with (e.g., on top of) the intra direction mode reuse. For example, TU depth search may be performed recursively till the respective CU transform depth from the SHVC bitstream is reached.
  • Intra CU transform unit depth may be reused in transcoding.
  • the transcoder may reuse the intra CU transform unit depth information during transcoding of the respective CU, perhaps for example if the CU is intra coded in SHVC bitstream.
  • the TU depth information may be reused during the transcoding based on one or more conditions. For example, for the SHVC bitstream with spatial resolution 1.5x, TU depth reuse may be applied when (e.g., only when) the EL CU depth is equal to BL CU depth or BL CU depth plus one.
  • TU depth reuse may be applied when (e.g., only when) the EL CU depth is equal to the BL CU depth plus 1, perhaps for example except for EL CU depth 0.
  • BL CU depth can be 0 or 1.
  • Inter CU transform unit depth may be reused in transcoding.
  • the transcoder may reuse inter CU transform unit depth information during the transcoding if the corresponding CU in SHVC bitstream is an inter-coded CU.
  • the transcoder might not apply TU depth reuse for ILR PUs that may be coded in inter mode at ILR picture.
  • Motion information refinement may be applied for ILR PUs that may be coded in inter mode at ILR picture.
  • Table 5 shows the results of SHVC Park Scene bit stream (with EL-QP 22 and BL-QP 22) transcoding using TU depth information reuse.
  • Figure 16 shows the RD performance curves of the SHVC transcoder comparing the MV reuse, ILR CU MV reuse, intra direction mode information reuse, and/or TU depth reuse.
  • Coding information may be refined. Different refinement techniques may be applied to the ILR CUs motion information.
  • ILR PU MV refinement may be applied.
  • a CU may be an ILR CU and/or may be coded as inter mode in ILR picture.
  • Motion information from ILR picture may be refined such that if the respective PU is a bi-prediction PU in the SHVC bitstream and/or if any of the motion vector information is not available in the ILR picture, among other scenarios, a suitable neighboring candidate may be selected.
  • the nearest available neighbors e.g., from the list of PUs shown in Figure 17
  • motion information and/or the MV predictors may be considered.
  • One or more neighboring candidates may be selected based on the sum of absolute transformed differences (SATD) cost.
  • SATD cost with the available MV from ILR picture may be calculated by treating a current PU as uni-predicted PU.
  • the SATD cost may be calculated with the one or more possible MVP candidates and/or the MVs from available nearest neighbors.
  • the one with a lowest SATD cost may be selected as the refined MV (e.g., a refined ILR PU) and/or may be reused during transcoding of the respective PU.
  • Motion information from the collocated CU in ILR picture may be reused.
  • RDO process in transcoder may be processed for the possible partitions (e.g., 2Nx2N, NxN, 2NxN, and/pr Nx2N etc.).
  • a partition size may be selected based on the RDO cost. Perhaps for example, if the motion information is unavailable for an ILR PU partition, the neighboring block (e.g., a nearest PU with motion vector information, from the available list in Figure 17) motion information from ILR picture may be copied to the respective partition.
  • Mixed CUs, intra coded ILR CUs, and/or mixed ILR CUs may be handled differently.
  • some PUs may be coded as inter PUs and others are ILR PUs that may be intra coded in ILR picture.
  • Inter PU(s) in mixed CU may be transcoded in inter mode by reusing the motion information from SHVC bitstream.
  • ILR PUs may be re-encoded using motion search by reusing the CU depth, prediction mode (e.g., inter), and/or partition information.
  • Intra coded ILR CUs shown in Figure 11 may be transcoded with intra prediction reuse by extracting intra direction mode and/or transform depth information from the respective SHVC BL CU.
  • the CU depth information check may be performed between BL and/or transcoder CU depth.
  • Motion vector refinement may be performed in combination with (e.g., on top of) the ILR PU MV refinement.
  • a small integer search window of [-1, 1] may be performed on the motion information obtained from the ILR PU during transcoding to select a motion.
  • the start search point may be selected between the AMVP candidate and the motion vector obtained from the SHVC bitstream.
  • Integer motion search on a small window of [-1, 1] may be applied on that start point.
  • Motion search start point may be determined based on the cost calculated using SATD and/or bit cost obtained from motion information. One or more candidate with the minimal cost may be selected as motion search start point.
  • Fractional motion search refinement may be applied after the integer motion search refinement.
  • Table 6 shows the results of SHVC Park Scene bit stream (with EL-QP 22 and BL-QP 22) transcoding with the above motion vector refinement.
  • Figure 18 shows the RD performance curves of the SHVC transcoder comparing the MV reuse, ILR CU MV reuse, intra direction mode information reuse, TU depth reuse, and/or ILRPU MV refinement.
  • High quality YUV input and/or coding information may be used in transcoding.
  • the transcoder can use the reconstructed YUV bit-stream from the SHVC bitstream output.
  • the transcoder can use the available high quality YUV data as input.
  • the high quality YUV data may be used as source during transcoding.
  • SHVC bitstream coding information can be used from the selected bitstream.
  • SHVC bitstream coding information can be used from the high quality SHVC bitstream.
  • SHVC bitstream coding information can be used from the high quality SHVC bitstream, perhaps for example when there are one or more, or multiple, bitrate SHVC bitstreams in the streaming server and/or the client requests for a medium bitrate bitstream.
  • the high quality bitstream coding information can be used, perhaps along with high quality YUV data for transcoding and/or streaming in medium bitrate.
  • Various coding information extracted from the SHVC bitstream can be reused using one or more, or various, approaches discussed herein.
  • Various coding information extracted from the SHVC bitstream can be refined using one or more, or various, approaches discussed herein to configure SHVC transcoder in high, medium, and/or low complexity modes.
  • One or more applications can select the mode of transcoding based on one or more
  • an application may select high complexity transcoding mode. For example, if fast transcoding mode is required, an application may select low complexity transcoding mode. For example, if a good trade-off between quality and complexity is required, an application may select medium complexity transcoding mode.
  • a high complexity transcoding mode can be selected, perhaps for example if high quality video is required/selected.
  • the CU depth and/or prediction mode information may be reused in transcoding (e.g., for inter CUs transcoding).
  • Motion information from the SHVC bitstream may be reused for inter CUs transcoding.
  • ILR CUs may perform an inter-prediction search at the CU depth extracted from the SHVC bitstream.
  • Intra-direction information may be reused for intra coding.
  • Intra-directional mode information reuse may be applied to intra CUs, perhaps for example with DC and/or planar modes information extracted from the SHVC bitstream. For example, where the intra CUs with intra prediction mode may be a directional prediction mode, full intra prediction mode search may be performed.
  • TU depth may be reused, for example, for DC and/or planar modes.
  • TU depth search may be conducted recursively, for example till it reaches the depth extracted from the input bitstream. For such modes and/or one or more other intra directional modes, full TU depth search may be applied.
  • a medium complexity transcoding mode may be selected.
  • CU depth information from SHVC bitstream may be reused in transcoding.
  • Prediction mode information may be reused for inter CUs and/or ILR CUs of temporal layer (TL)-l, TL-2, and/or TL-3 pictures.
  • Inter CUs transcoding may use the MV reuse.
  • Non TL-0 pictures ILR CUs may use the ILR PU MV refinement as described herein.
  • ILR CUs in TL-0 pictures may be transcoded with full mode decision by considering intra and/or inter coding modes.
  • MV refinement as described herein may be used for inter-mode decision and/or a full intra-prediction mode search may be performed for intra prediction.
  • Intra coded CUs may use intra-directional mode reuse for DC and/or one or more planar modes. For such modes and/or one or more other modes, among other scenarios, an intra prediction search may be performed with one or more of the other possible intra-directional modes.
  • Intra CUs with DC and/or planar mode intra prediction and/or inter coded CUs may use the TU depth reuse discussed herein.
  • a low complexity transcoding mode may be selected.
  • the transcoder may use full CU depth reuse, prediction mode reuse, MV reuse for inter CUs, and/or ILR CUs, perhaps for example along with intra directional mode reuse and/or TU depth reuse as described herein.
  • ILR CUs in TL-0 pictures may be transcoded with inter prediction mode.
  • ILR CUs in TL-0 pictures may be transcoded with inter prediction mode (e.g., perhaps only in some scenarios).
  • the transcoder may use the ILR PU MV refinement. The refinement of the motion information on a search window of [-1 , 1] might not be applied in some scenarios.
  • Table 7 compares examples of various coding parameter reuse using high, medium and/or low complexity transcoding modes and/or the refinements applied to those coding parameters.
  • Example medium Yes Yes for Yes (for Yes (e.g., Yes Yes (MV Yes (e.g., complexity mode non directional only MV refinement only for DC
  • coding may use intra
  • a transcoding mode can be adaptively selected based at least in part on the available coding information from the SHVC bitstream and/or the statistics from the previous transcoded pictures.
  • the percentage of intra-coded area in a picture may be calculated and/or compared with a threshold value. For example, perhaps if the calculated intra coded area percentage of the current picture is greater than the threshold value, among other scenarios, the transcoder may select the medium complexity transcoding mode. In some scenarios, a transcoder may select the low complexity transcoding mode.
  • Intra-coded area calculation may include, among other things, intra CUs coded area, intra coded ILR CU area, and/or intra coded mixed ILR CU area.
  • CUs in a picture coded using intra-prediction mode may be coded in intra-prediction mode during transcoding.
  • the transcoder may reuse the CU depth, prediction mode, and/or CU partition information.
  • the percentage area occupied by such CUs may be referred to as intra-CU coded area.
  • one or more, or some, CUs in an EL picture coded using inter-prediction mode and/or the PUs in that CU may be coded as ILR PUs using intra-prediction mode in the BL.
  • These CUs may be encoded using intra-prediction mode reusing the CU depth, intra-direction mode, and TU depth information.
  • the percentage area occupied by these CUs in a picture may be referred to as intra coded ILR CU area.
  • mixed ILR CUs in a BL may be transcoded using inter- prediction mode and/or intra-prediction mode.
  • the mode with better RD cost may be selected.
  • refined motion information from the SHVC bitstream may be reused and/or a (e.g., small) search window of [-1, 1] may be applied during motion refinement along with CU depth reuse.
  • the percentage area occupied by these CUs (e.g., CUs with intra prediction mode as selected mode) in a picture may be referred to as mixed ILR CU intra coded area.
  • the transcoder may (e.g., adaptively) switch between complexity modes (e.g., between medium and low complexity modes) perhaps for example based on the SHVC bitstream statistics of current TL-0 picture and/or previous TL-0 pictures as shown in Figure 19.
  • complexity modes e.g., between medium and low complexity modes
  • the intra CU coded area percentage is low or medium (2 - 5%) and/or the intra coded ILR CU area percentage is lower than a medium threshold (e.g., 50%) and/or the intra CUs coded area percentage is higher (e.g., above 5%)
  • the CUs with ILR PUs e.g., that may be coded using inter mode in BL
  • the coding mode with a "best" RDO cost (e.g., a lower cost) may be selected.
  • a transcoder may select the low transcoding mode for the next TL-0 pictures. Those mixed ILR CUs of the next TL-0 pictures may be transcoded (e.g., only) in inter mode. If a current TL-0 picture's intra CU coded area percentage is low or medium (e.g., less than 5%) and/or the intra coded ILR CU area is high (e.g., greater than 50%), the CUs with ILR PUs may be coded (e.g., only) in inter mode reusing the motion, CU depth, and/or transform depth information from the SHVC bitstream.
  • the CUs with ILR PUs (e.g., coded as inter in base/interface layer) in that TL-0 picture may be coded in inter mode as described in regard to the low complexity transcoding mode.
  • One or more example SHVC transcoding simulations were performed on a desktop with Intel Core i7 2600 processor having 4 cores running at 2.6 GHz.
  • An example transcoder reduced the transcoding complexity by around 98-99% using low complexity- performance transcoding when compared with LL-HCHP (e.g., re-encoding).
  • the overall SHVC transcoding speed achieved with various techniques is shown in Table 8 and Table 9 for Basketball Drive and Park Scene test sequences, respectively.
  • the transcoder performance results are listed for the following transcoding configurations, among others: LL-HCHP (e.g., Low latency high complexity high performance - Re-encoding), low complexity -performance transcoding, medium complexity-performance transcoding, and/or high complexity-performance transcoding.
  • Example rate-distortion (RD) curves of the fast SHVC transcoder with various configurations described herein are provided in Figure 20 and Figure 21 for Basketball Drive and Park Scene test sequences, respectively.
  • FIG. 22A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented.
  • the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc. , to multiple wireless users.
  • the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
  • the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal FDMA
  • SC-FDMA single- carrier FDMA
  • the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
  • Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment.
  • the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.
  • UE user equipment
  • PDA personal digital assistant
  • smartphone a laptop
  • netbook a personal computer
  • a wireless sensor consumer electronics, and the like.
  • the communications systems 100 may also include a base station 114a and a base station 114b.
  • Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112.
  • the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
  • the base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.
  • BSC base station controller
  • RNC radio network controller
  • the base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown).
  • the cell may further be divided into cell sectors.
  • the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, e.g., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple-input multiple output
  • the base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.).
  • the air interface 115/116/117 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like.
  • the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA).
  • UMTS Universal Mobile Telecommunications System
  • UTRA Universal Mobile Telecommunications System
  • WCDMA wideband CDMA
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
  • HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
  • HSPA High-Speed Packet Access
  • HSDPA High-Speed Downlink Packet Access
  • HSUPA High-Speed Uplink Packet Access
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE- A).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • LTE Long Term Evolution
  • LTE-A LTE-Advanced
  • the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.16 e.g., Worldwide Interoperability for Microwave Access (WiMAX)
  • CDMA2000, CDMA2000 IX, CDMA2000 EV-DO Code Division Multiple Access 2000
  • IS-95 Interim Standard 95
  • IS-856 Interim Standard 856
  • GSM Global System for Mobile communications
  • GSM Global System for Mobile communications
  • EDGE Enhanced Data rates for GSM Evolution
  • GERAN GSM EDGERAN
  • the base station 114b in FIG. 22A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like.
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
  • the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell.
  • a cellular-based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.
  • the base station 114b may have a direct connection to the Intemet 110.
  • the base station 114b may not be used to access the Internet 110 via the core network 106/107/109.
  • the RAN 103/104/105 may be in communication with the core network
  • the core network 106/107/109 may be any type of network configured to provide voice, data, applications, and/or voice over intemet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d.
  • the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
  • the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT.
  • the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.
  • the core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112.
  • the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite.
  • the networks 112 may include wired or wireless
  • the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.
  • One or more of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.
  • the WTRU 102c shown in FIG. 22A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
  • FIG. 22B is a system diagram of an example WTRU 102.
  • the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138.
  • GPS global positioning system
  • the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include one or more of the elements depicted in FIG. 22B and described herein.
  • the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of
  • the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
  • the processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 22B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface
  • the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
  • the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
  • the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122.
  • the WTRU 102 may have multi-mode capabilities.
  • the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
  • the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit).
  • the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128.
  • the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
  • the non-removable memory 130 may include random- access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
  • the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
  • the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
  • the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
  • the processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
  • the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player
  • FIG. 22C is a system diagram of the RAN 103 and the core network 106 according to an embodiment.
  • the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 115.
  • the RAN 103 may also be in communication with the core network 106.
  • the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115.
  • the Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103.
  • the RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.
  • the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC142b.
  • the Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface.
  • the RNCs 142a, 142b may be in communication with one another via an Iur interface.
  • Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected.
  • each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.
  • the core network 106 shown in FIG. 22C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MGW media gateway
  • MSC mobile switching center
  • SGSN serving GPRS support node
  • GGSN gateway GPRS support node
  • the RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface.
  • the MSC 146 may be connected to the MGW 144.
  • the MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and land-line communications devices.
  • the RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface.
  • the SGSN 148 may be connected to the GGSN 150.
  • the SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
  • FIG. 22D is a system diagram of the RAN 104 and the core network 107 according to an embodiment.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 16.
  • the RAN 104 may also be in communication with the core network 107.
  • the RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
  • the eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 16.
  • the eNode-Bs 160a, 160b, 160c may implement MIMO technology.
  • the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 22D, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.
  • the core network 107 shown in FIG. 22D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MME mobility management gateway
  • PDN packet data network
  • the MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S I interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer
  • the MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
  • the serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the S I interface.
  • the serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c.
  • the serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
  • the serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the PDN gateway 166 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the core network 107 may facilitate communications with other networks.
  • the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and land-line communications devices.
  • the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108.
  • IMS IP multimedia subsystem
  • the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
  • FIG. 22E is a system diagram of the RAN 105 and the core network 109 according to an embodiment.
  • the RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117.
  • ASN access service network
  • the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.
  • the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment.
  • the base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117.
  • the base stations 180a, 180b, 180c may implement MIMO technology.
  • the base station 180a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • the base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like.
  • the ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.
  • the air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification.
  • each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109.
  • the logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for
  • the communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations.
  • the communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point.
  • the R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.
  • the RAN 105 may be connected to the core network 109.
  • the communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example.
  • the core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
  • MIP-HA mobile IP home agent
  • AAA authentication, authorization, accounting
  • the MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks.
  • the MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
  • the AAA server 186 may be responsible for user authentication and for supporting user services.
  • the gateway 188 may facilitate interworking with other networks.
  • the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and land-line communications devices.
  • the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
  • the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks.
  • the communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs.
  • the communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.
  • one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, Node B 140a-c, RNC 142a-b, MSC 146, SGSN 148, MGW 144, CGSN 150, eNode-B 160a-c, MME 162, Serving Gateway 164, PDN Gateway 166, Base Station 180a-c, ASN Gateway 182, AAA 186, MIP-HA 184, and/or Gateway 188, or the like, may be performed by one or more emulation devices (not shown) (e.g., one or more devices configured to emulate one or more, or all, of the functions described herein).
  • the one or more emulation devices may be configured to perform the one or more, or all, functions in one or more modalities.
  • the one or more emulation devices may perform the one or more, or all, functions while being fully or partially
  • the one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network.
  • the one or more emulation devices may perform the one or more, or all, functions while not being implemented/deployed as part of a wired and/or wireless communication network (e.g., such as in a testing scenario in a testing laboratory and/or a non-deployed (e.g. testing) wired and/or wireless communication network, and/or testing performed on one or more deployed components of a wired and/or wireless communication network).
  • the one or more emulation devices may be test equipment.
  • IBC intra block copy
  • SCC screen content coding
  • IBC may be enabled/disabled for multiple slices in a picture.
  • a flag in a slice segment header may indicate whether a current picture is included in a reference picture list for a current slice. The value of the flag may be consistent for all slices in a picture.
  • Decoding complexity may be reduced, for example, by constraining IBC search range.
  • horizontal block vector (BV) and/or vertical BV may have limited maximum values.
  • Error propagation from inter predicted samples to intra predicted samples may be prevented in constrained intra prediction (CIP), for example, by (i) disabling IBC mode, (ii) using samples of intra-coded CUs as reference samples for intra prediction while disallowing samples of neighboring inter-coded and IBC-coded CUs, (iii) using samples of IBC-coded CUs and intra-coded CUs as references for intra prediction when the IBC-coded CUs are constrained to use samples of intra-coded CUs as references; (iv) disabling temporal motion vector prediction (TMVP) for IBC mode.
  • CIP constrained intra prediction
  • Chroma sample interpolation for IBC mode may (i) use fractional BVs for chroma components of IBC-coded CUs, (ii) disallow use of unavailable chroma reference samples (e.g. samples from un-decoded area or different slices or tiles), (iii) use padded samples from the current slice/tile or decoded region for fractional sample interpolation (e.g. by replicating the value of a sample to an unavailable sample across a slice boundary).
  • SCC IBC mode efficiency may be improved, for example, by generating initial reference picture lists of the current picture with a pseudo reference picture comprising already coded samples of the current picture.
  • a constraint may disable the combination of two reference blocks from the pseudo reference picture.
  • Weighted prediction may be disabled for IBC mode, for example, when a reference picture has the same picture order count (POC) as the current picture.
  • POC picture order count
  • Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • ROM read only memory
  • RAM random access memory
  • register cache memory
  • semiconductor memory devices magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

L'invention concerne des systèmes, des procédés et des instrumentalités permettant de réutiliser des informations de codage extraites d'un train de bits SHVC pendant un processus de transcodage, affiner les informations de codage, et/ou utiliser les informations de codage affinées dans le transcodage. Un premier train de bits, tel qu'un train de bits SHVC qui peut comprendre une couche de base et/ou une ou plusieurs couches d'amélioration, peut être reçu. Des informations de codage, telles qu'une profondeur d'unité de codage, un mode de prédiction d'unité de codage, des informations de mouvement, un mode intradirectionnel, et/ou une profondeur d'unité de transformation peuvent être extraites du premier train de bits. Le premier train de bits peut être transcodé en un deuxième train de bits (par exemple, un train de bits HEVC) en affinant et/ou réutilisant au moins une partie des informations de codage extraites. Le transcodeur peut sélectionner de manière adaptative un mode de transcodage de réutilisation d'informations de codage à partir d'au moins un mode de transcodage, ou d'une pluralité de ceux-ci, peut-être par exemple en fonction de caractéristiques de signal vidéo.
PCT/US2016/044909 2015-07-29 2016-07-29 Codage vidéo à haute efficacité extensible pour transcodage de codage vidéo à haute efficacité WO2017020021A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562198239P 2015-07-29 2015-07-29
US62/198,239 2015-07-29

Publications (1)

Publication Number Publication Date
WO2017020021A1 true WO2017020021A1 (fr) 2017-02-02

Family

ID=56610034

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/044909 WO2017020021A1 (fr) 2015-07-29 2016-07-29 Codage vidéo à haute efficacité extensible pour transcodage de codage vidéo à haute efficacité

Country Status (1)

Country Link
WO (1) WO2017020021A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108235026A (zh) * 2018-02-01 2018-06-29 重庆邮电大学 一种空间可伸缩的快速编码方法
CN111316639A (zh) * 2018-04-09 2020-06-19 腾讯美国有限责任公司 用于子块运动矢量预测的方法和装置
CN111602401A (zh) * 2018-01-16 2020-08-28 Vid拓展公司 用于360度视频译码的自适应帧封装
CN114520914A (zh) * 2022-02-25 2022-05-20 重庆邮电大学 一种基于shvc质量可伸缩帧间视频编码方法
WO2023056445A1 (fr) * 2021-09-30 2023-04-06 Bytedance Inc. Procédé, appareil et support de traitement vidéo
CN116320398A (zh) * 2023-03-22 2023-06-23 重庆邮电大学 基于神经网络优化的质量shvc编码方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030202579A1 (en) * 2002-04-24 2003-10-30 Yao-Chung Lin Video transcoding of scalable multi-layer videos to single layer video
US20120155554A1 (en) * 2010-12-20 2012-06-21 General Instrument Corporation Svc-to-avc rewriter with open-loop statistal multplexer
US20140010294A1 (en) * 2012-07-09 2014-01-09 Vid Scale, Inc. Codec architecture for multiple layer video coding
WO2015053697A1 (fr) * 2013-10-11 2015-04-16 Telefonaktiebolaget L M Ericsson (Publ) Procédé et agencement permettant le transcodage d'un train de bits vidéo
WO2015053673A1 (fr) * 2013-10-11 2015-04-16 Telefonaktiebolaget L M Ericsson (Publ) Procédé et agencement de transcodage vidéo utilisant des informations de mode ou de mouvement ou de filtre en boucle

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030202579A1 (en) * 2002-04-24 2003-10-30 Yao-Chung Lin Video transcoding of scalable multi-layer videos to single layer video
US20120155554A1 (en) * 2010-12-20 2012-06-21 General Instrument Corporation Svc-to-avc rewriter with open-loop statistal multplexer
US20140010294A1 (en) * 2012-07-09 2014-01-09 Vid Scale, Inc. Codec architecture for multiple layer video coding
WO2015053697A1 (fr) * 2013-10-11 2015-04-16 Telefonaktiebolaget L M Ericsson (Publ) Procédé et agencement permettant le transcodage d'un train de bits vidéo
WO2015053673A1 (fr) * 2013-10-11 2015-04-16 Telefonaktiebolaget L M Ericsson (Publ) Procédé et agencement de transcodage vidéo utilisant des informations de mode ou de mouvement ou de filtre en boucle

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KENNETH ANDERSSON ET AL: "Transcoder-friendly scalable coding", 15. JCT-VC MEETING; 23-10-2013 - 1-11-2013; GENEVA; (JOINT COLLABORATIVE TEAM ON VIDEO CODING OF ISO/IEC JTC1/SC29/WG11 AND ITU-T SG.16 ); URL: HTTP://WFTP3.ITU.INT/AV-ARCH/JCTVC-SITE/,, no. JCTVC-O0127, 15 October 2013 (2013-10-15), XP030115133 *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111602401A (zh) * 2018-01-16 2020-08-28 Vid拓展公司 用于360度视频译码的自适应帧封装
CN111602401B (zh) * 2018-01-16 2024-01-09 Vid拓展公司 用于360度视频译码的自适应帧封装
CN108235026A (zh) * 2018-02-01 2018-06-29 重庆邮电大学 一种空间可伸缩的快速编码方法
CN108235026B (zh) * 2018-02-01 2021-09-28 重庆邮电大学 一种空间可伸缩的快速编码方法
CN111316639A (zh) * 2018-04-09 2020-06-19 腾讯美国有限责任公司 用于子块运动矢量预测的方法和装置
CN111316639B (zh) * 2018-04-09 2023-12-15 腾讯美国有限责任公司 视频解码方法和装置、及存储介质
WO2023056445A1 (fr) * 2021-09-30 2023-04-06 Bytedance Inc. Procédé, appareil et support de traitement vidéo
CN114520914A (zh) * 2022-02-25 2022-05-20 重庆邮电大学 一种基于shvc质量可伸缩帧间视频编码方法
CN114520914B (zh) * 2022-02-25 2023-02-07 重庆邮电大学 一种基于shvc质量可伸缩帧间视频编码方法
CN116320398A (zh) * 2023-03-22 2023-06-23 重庆邮电大学 基于神经网络优化的质量shvc编码方法
CN116320398B (zh) * 2023-03-22 2024-04-05 重庆邮电大学 基于神经网络优化的质量shvc编码方法

Similar Documents

Publication Publication Date Title
US10841615B2 (en) Systems and methods for model parameter optimization in three dimensional based color mapping
US20220400254A1 (en) Reference picture set (rps) signaling for scalable high efficiency video coding (hevc)
JP6307650B2 (ja) スケーラブルビデオ符号化のための動き情報シグナリング
US10218971B2 (en) Adaptive upsampling for multi-layer video coding
US9973751B2 (en) Slice base skip mode signaling for multiple layer video coding
KR102136666B1 (ko) 스케일가능한 비디오 코딩을 위한 계층간 예측
US20140010291A1 (en) Layer Dependency and Priority Signaling Design for Scalable Video Coding
WO2017020021A1 (fr) Codage vidéo à haute efficacité extensible pour transcodage de codage vidéo à haute efficacité
US9936215B2 (en) Reference picture set mapping for standard scalable video coding
WO2014138325A1 (fr) Codage vidéo conscient de la complexité pour un flux continu vidéo conscient de l'énergie

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16748034

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16748034

Country of ref document: EP

Kind code of ref document: A1