WO2022152452A1 - Verfahren zur wiedergabe eines videostreams durch einen client - Google Patents

Verfahren zur wiedergabe eines videostreams durch einen client Download PDF

Info

Publication number
WO2022152452A1
WO2022152452A1 PCT/EP2021/083632 EP2021083632W WO2022152452A1 WO 2022152452 A1 WO2022152452 A1 WO 2022152452A1 EP 2021083632 W EP2021083632 W EP 2021083632W WO 2022152452 A1 WO2022152452 A1 WO 2022152452A1
Authority
WO
WIPO (PCT)
Prior art keywords
video stream
data
frames
camera
encoder
Prior art date
Application number
PCT/EP2021/083632
Other languages
English (en)
French (fr)
Other versions
WO2022152452A9 (de
Inventor
Hossein Bakhshi GOLESTANI
Original Assignee
Rheinisch-Westfälische Technische Hochschule (Rwth) Aachen
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 Rheinisch-Westfälische Technische Hochschule (Rwth) Aachen filed Critical Rheinisch-Westfälische Technische Hochschule (Rwth) Aachen
Priority to EP21823541.4A priority Critical patent/EP4278608A1/de
Priority to US18/260,755 priority patent/US20240056654A1/en
Publication of WO2022152452A1 publication Critical patent/WO2022152452A1/de
Publication of WO2022152452A9 publication Critical patent/WO2022152452A9/de

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/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4621—Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video

Definitions

  • the digital encoding of video signals is found in many forms in the present day.
  • digital video streams are made available on data carriers such as DVDs, Blu-ray or as a download or video stream (e.g. also for video communication).
  • the aim of video coding is not only to send representations of the images to be transmitted, but also to keep data consumption low at the same time. On the one hand, this allows more content to be stored on media with limited storage space, such as DVDs, or to enable several users to transport (different) video streams at the same time.
  • a coder processes raw video data.
  • a single image is referred to as a frame.
  • a frame can be thought of as a collection of pixels.
  • a pixel represents a point in the frame and indicates its color value and/or its brightness.
  • the amount of data for a subsequent frame can be reduced if a large part of the information is/are already contained in one or more previously encoded frame(s). Then it would be sufficient, for example, if only the difference is transmitted. In doing so, one makes use of the knowledge that a lot of the same content can often be seen in consecutive frames. This is the case, for example, when a camera captures a particular scene from one point of view and only a few things change, or when a camera slowly moves or rotates through the scene (translation and/or affine movement of the camera).
  • this concept reaches its limits when a high proportion changes between frames, e.g. when the camera moves (rapidly) within a scene or when objects move within the scene. In this case, in the worst case, every pixel of two frames could be different.
  • a camera i.e. a monocular recording system
  • a completely different requirement profile results.
  • many areas e.g. in autonomous driving, in drones, in social media video recordings, or even in body cams or action cams, only a single camera is usually used. But it is precisely here that it is necessary to keep the storage space used and/or the amount of data to be transmitted small.
  • FIG. 4 shows a schematic representation for explaining conceptual issues
  • FIG. 5 shows an exemplary relation of frames according to further aspects of the invention.
  • a three-dimensional motion model can therefore also be made available within the invention. Without restricting the generality of the invention, it is also possible to use the invention with all current video (de)coders as long as they are upgraded accordingly. In particular, Versatile Video Coding ITU-T H.266/ISO/IEC 23090-3 can be added to the invention.
  • FIG. 4 a video consisting of (consecutive) encoded images of two-dimensional frames (ie a sequence) is viewed.
  • a frame is also referred to as a two-dimensional representation. Due to the temporal redundancy between consecutive frames, a frame to be (encoded) at time t can be predicted from previously (t-1, t-2 ... (shown t-4) without being limited to four previous frames) encoded frames. These preceding frames are also referred to as reference (reference frames, reference images). It should be noted here that the frame order does not necessarily have to be a chronological order, but that the order shown and the (de)coded order can be different.
  • the conventional encoders are based on the similarity of frames in a two-dimensional model, i.e. only translations and/or affine movements are considered. However, there are a number of movements that cannot be easily expressed as a 2D model.
  • this invention uses an approach based on the three-dimensional environment in which the sequence is recorded and from which a 3D motion model can be displayed.
  • video recording is analogous to projecting a three-dimensional scene into the camera's two-dimensional plane.
  • the invention enables a different provision.
  • the 3D information is reconstructed on the decoder side, while in the example of the flow chart according to FIG. 2 the coder makes the 3D information available (compressed) and the decoder only uses it.
  • the coder makes the 3D information available (compressed) and the decoder only uses it.
  • a mixed form is provided in which the encoder provides the (coarse) 3D information (compressed) and the decoder further processes the 3D information to improve it.
  • the required bandwidth/storage capacity can be less than in the second or third case.
  • the demands on the computing power for the encoder and the decoder are high, while in the second case, the demands on the computing power are lower for the decoder and highest for the encoder.
  • provision can therefore be made for a decoder for example, to make its properties known to the coder, so that the coder may can do without the provision of (more precise) 3D information because the decoder provides a method according to FIG. 1 or 3.
  • the camera is any camera and is not fixed to a specific type.
  • the camera parameters CP and geometry data GD can be inferred.
  • the camera parameters CP can be inferred, for example, by methods such as Structure from Motion, Simultaneous Localization and Mapping or sensors.
  • the camera parameters CP can typically be determined from sensor data from gyroscopes, inertial measurement units (IMU), location data from a global positioning system (GPS), etc., while geometry data GD from sensor data from a LIDAR sensor, stereo cameras, depth sensors , light field sensors, etc. are determined. If both camera parameters CP and geometry data GD are available, the (de-)coding becomes easier and usually of better quality.
  • the encoder SRV can receive a conventional video signal Input Video in step 301, for example.
  • This video signal can advantageously be monitored for movement, ie relative movement of the camera. If a relative movement of the camera is detected, the input video signal Input Video can be subjected to a coding according to the invention, otherwise, if no relative movement of the camera is detected, the signal can be subjected to a usual coding as before and as indicated in step 303, 403, 503 the Decoder C are provided.
  • camera movement can be detected by the encoder, for example by visual data processing of the video signal and/or by sensors such as an IMU (Inertial Measurement Unit), a GPS (Global Positioning System), etc.
  • IMU Inertial Measurement Unit
  • GPS Global Positioning System
  • a corresponding flag Flag_3D or other signaling can be used to signal the presence of inventive content according to step 304, 404, 504 if it is not already per se recognizable from the data stream.
  • the (intrinsic and extrinsic) camera parameters CP can be estimated/determined in step 306, 406, 506, as indicated in step 305, 405, 505.
  • visual data processing such as Structure-from-Motion (SfM), Simultaneous Localization and Mapping (SLAM), Visual Odometry (V.O.), or any other suitable method can be used.
  • SfM Structure-from-Motion
  • SAM Simultaneous Localization and Mapping
  • V.O. Visual Odometry
  • the camera parameters CP can of course also be estimated/determined/taken over as a known value by other sensors.
  • these camera parameters CP can be processed and encoded in step 307, 407, 507 and made available to the decoder C separately or embedded in the video stream VB.
  • the geometry in three-dimensional space can be estimated/determined in step 310, 410, 510.
  • the geometry in three-dimensional space can be estimated from one or more previously encoded frames (step 309).
  • the previously determined camera parameters CP can be included in step 308 for this purpose.
  • the 3D geometry data can be estimated/determined from "raw" data. In the embodiment of Figure 1, this data can be estimated/determined from the encoded data.
  • the visual quality in the embodiments of the figure 2 and 3 can be better than in the embodiment of FIG. 1, so that these embodiments can provide higher-quality 3D geometry data.
  • multi-view computer vision techniques can be used without using other techniques, such as any existing depth sensors, such as LiDAR, or other image sensors that allow depth detection, such as stereo cameras, RGB+ D sensors, light field sensors, etc. to exclude.
  • the geometry determined in this way in three-dimensional space can be represented by a suitable data structure, e.g. a 3D model, a 3D mesh, 2D depth maps, point clouds (sparse or dense), etc.
  • a suitable data structure e.g. a 3D model, a 3D mesh, 2D depth maps, point clouds (sparse or dense), etc.
  • the video signal VB can now be encoded in the three-dimensional space in steps 312, 412, 512 on the basis of the determined geometry.
  • the novel motion-based model can now be applied to the reproduced three-dimensional information.
  • a reference image can be determined/selected in step 311 for this purpose. This can then be presented to the standard video encoder in step 312.
  • the encoding that follows can be applied to one, several or all frames of a predetermined set.
  • the coding can also be based on one, several or all previous frames of a predetermined set.
  • a standard video encoder can be used.
  • An additional reference can be added to the list of reference images (in step 311) or an existing reference image can be replaced.
  • only a specific spatial area can be overwritten with the new reference.
  • the standard video coder can be enabled to independently select, on the basis of the available reference images, the reference image that has a favorable property, for example high compression with low distortions (rate-distortion optimization).
  • the standard video encoder can thus encode the video stream using the synthesized reference and make it available to the decoder C in step 313, 413, 513.
  • the coder SRV can start again at corresponding re-entry points with a recognition according to step 301 and run through the method again.
  • Respawn points can be set at set time intervals based on channel characteristics, video frame rate, application, etc.
  • the 3D geometry can be reconstructed in three-dimensional space or an existing one can be further developed.
  • the 3D geometry will continue to grow as new frames are added until it restarts at the next respawn point.
  • the decoder side C can be operated in a corresponding manner, with the coder SRV and decoder C in FIGS. 1 to 3 being arranged horizontally at approximately the same height in their functionally corresponding components.
  • the decoder C can first check whether a corresponding flag Flag_3D or another signaling was used.
  • the video stream can be treated in step 316 by default. Otherwise the video stream can be treated in the new inventive way.
  • camera parameters CP can be obtained in steps 317, 417, 517.
  • the obtained camera parameters CP can be processed and/or decoded in optional steps 318 .
  • These camera parameters CP can be used, for example, for a depth estimation as well as for generating the geometry in three-dimensional space in step 320 based on previous frames 319 .
  • step 321 it is e.g. possible to render the synthesized reference image in step 321 by transforming the previously decoded frame (step 319) into the frame to be decoded, guided by the decoded camera parameters CP (step 318) and the geometry in three-dimensional space (step 320 ).
  • step 323, 423, 523 the video stream processed according to the invention can be decoded by a standard video encoder and output as a decoded video stream 324, 424, 524.
  • the decoder should be synchronous with the encoder in terms of settings, so that the decoder C uses the same settings (especially for depth determination, reference creation, etc.) as the encoder SRV.
  • the geometry in three-dimensional space can be estimated from raw video frames in step 405.
  • An (additional) bit stream 410.1 can be generated from the data, which, for example, is the subject of further processing, e.g. decimation, (lossless/lossy) compression and coding, which can be made available to the decoder C.
  • This bit stream 2.2 that has been made available can now also--as in the decoder C--be converted back in step 410.2 (to ensure the congruence of the data) and made available for processing in step 411.
  • the geometry in three-dimensional space can also be retained beyond a re-entry point.
  • the method also allows the geometry in the three-dimensional space to be continuously improved on the basis of previous and current frames.
  • This geometry in three-dimensional space can suitably be subject to further processing, eg decimation (e.g. mesh decimation), (lossy/lossy) compression/encoding.
  • the decoder C can receive and decode the bit stream 2.2 obtained in step 419.1 with the data relating to the geometry in three-dimensional space. The decoded geometry in three-dimensional space can then be used in step 420.
  • the decoder can obviously work faster in this variant, since the decoding requires less effort than the reconstruction of the geometry in three-dimensional space (FIG. 1).
  • FIG. 3 combines aspects of the embodiments of FIG. 1 and FIG. 2, spreading the complexity and allowing a flexible and efficient method.
  • the concept of the embodiment in Figure 3 differs from the embodiment in Figure 2 in that the geometry in three-dimensional space, i.e. the 3D data in step 510.1 roughly represents the original geometry in three-dimensional space, i.e. in a slimmed-down version, so that the required bit rate for this decreases.
  • Any suitable data reduction technique such as, but not limited to, sub-sampling, coarse quantization, transform coding, and dimensionality reduction, etc. can be used for this purpose.
  • the 3D data minimized in this way can be coded and made available to the decoder C as before in step 510.2.
  • the bitstream 510.1/510.2 may be subject to further processing, eg decimation, compression (lossless/lossy) and encoding, which may be provided to the decoder C.
  • This bit stream 2.2 that has been made available can now also--as in the decoder C--be converted back in step 510.3 (to ensure the congruence of the data) and made available for processing in step 511.
  • the previously encoded frames 509 and the camera parameters 506 can be used for finer processing of the 3D data.
  • the decoder C can receive the encoded and minimized 3D data in step 519.1 and decode them in step 519.2 and—corresponding to the encoder SRV—the processing can be made available.
  • the previously encoded frames 519.3 and camera parameters 518 can be used for finer processing of the 3D data.
  • a video stream VB is obtained from the encoder SRV, e.g., a streaming server, in a first step 315, 415, 515.
  • the client C decodes the received video stream VB using camera parameters CP and geometry data GD, and then reproduces this as a prepared video stream AVB in step 324, 424, 524.
  • the camera parameters CP can be obtained from the encoder SRV in step 317, 417, 517 (e.g. as bitstream 2.1) or can be determined from the obtained video stream VB.
  • geometry data GD can be obtained from the encoder SRV (e.g. as bitstream 2.2) or determined from the obtained video stream VB.
  • the decoder C before receiving the video stream VB, the decoder C signals the coder SRV that it is able to process it.
  • a set of processing options can also be supplied so that the coder can provide the appropriate format.
  • the format made available can have a corresponding coding with regard to setting data.
  • the geometry data includes depth data.
  • a 3D reconstruction is used both on the encoder and on the decoder side.
  • a 3D reconstruction is carried out only by the encoder and made available to the decoder. This means that the decoder does not have to carry out a 3D reconstruction, but can use the 3D geometry data provided by the encoder. Estimating the 3D geometry data on the part of the coder is usually easier than on the part of the decoder.
  • the configuration according to FIG. 2 is advantageous in particular when the computing power is limited on the part of the decoder.
  • a 3D reconstruction is carried out by the coder and made available to the decoder. However, only a rough version of the 3D geometry data is provided here. This allows the bit rate for the 3D geometry data to be reduced.
  • the decoder now has to complete/postprocess the 3D geometry data (refine).
  • the choice of method can be negotiated between the encoder and the decoder. This can be done, for example, on the basis of previous knowledge (e.g. computing power) or via a control/return channel (adaptive) in order to also take changes in the transmission capacity into account, for example.
  • the configuration according to FIG. 2 will generally be preferred.
  • the invention can therefore also be embodied in computer program products for setting up a data processing system for carrying out a method.
  • this "to-be-encoded frame” can be coded using intra-prediction or inter-prediction tools.
  • a group of pictures English Group of Pictures - abbreviated GOP
  • 16th frame ie frame with order number 0, 16, 32, ...
  • Intra- prediction tools one would use inter-prediction tools to do this.
  • the frames to be encoded by means of inter-prediction tools i.e. in the example frames 1-15, 17-31, 33-47, ... , ... .
  • inter-prediction tools use temporal similarities between consecutive frames. If a block of a frame to be encoded is similar to any frame in the previously encoded frame (e.g. due to relative motion), then instead of re-encoding this block, this already encoded block can simply be referred to. This process can be referred to as motion compensation. For this purpose, a new list of previously encoded frames is used for each frame, which can be used as a reference for the motion compensation. This list is also referred to as a reference picture list.
  • the Coders divide the frame to be encoded into a few non-overlapping blocks, and then the block thus created can be compared with previously encoded blocks according to the corresponding listing to find a high - preferably best - match
  • the relative 2D position of each block found i.e. the motion vector
  • the difference between the created block and the found block i.e. the residual signal
  • At least one novel reference image is created based on 3D information and added to this list of reference images or inserted instead of an existing reference image.
  • the camera parameters CP for a single (monocular) camera and geometry data GD for the 3D scenes are created from a set of 2D images, which were captured by the moving monocular camera.
  • a new type of reference image based on 3D information for frames to be encoded is created, eg by distorting the content of conventional reference images to the position of the image to be encoded.
  • This warping process is guided by the established/estimated camera parameters CP and for the 3D scenes geometry geometry data GD.
  • the novel reference image thus synthesized is created based on 3D information and added to this reference image list.
  • the novel reference picture created in this way allowed improved performance with regard to motion compensation, ie requires a lower bit rate than conventional reference pictures in the reference picture list. In this way, the bit rate required at the end can also be reduced and the coding gain can be increased.
  • R3D is found 20%-30% of the time while RI or R2 is found in the rest of the cases.
  • This information which reference picture is used for which block, can be fed into the video bit stream.
  • the decoder can then simply read this information and create the novel reference image based on 3D information at least for these regions, i.e. not for the entire area. That is, unlike the coder, it may be sufficient for the documenter if only the used part of the R3D reference is created for the inter-prediction, while it is not necessary to create the other parts of the R3D reference as well.
  • frames have a different contribution to the final bit rate, based on their order and position in the encoder structure used.
  • FIG. 5 The circles represent frames with the rendering order.
  • the arrows indicate the conventionally generated reference images that can be used for motion compensation.
  • the frame can use F M Fi and Fi +S as a reference.
  • the frame Fi +g uses, for example, Fi and F M6 as reference images, but they are further apart.
  • the encoder could be (more than) twice as fast.
  • a flag reduced / not reduced
  • the camera parameters CP and for the 3D scene geometry geometry data GD can be made available not just once but repeatedly, individually or in combination, from the encoder to the decoder. A new sentence as well as an update can be made available.

Landscapes

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

Abstract

Die Erfindung betrifft ein Verfahren zur Wiedergabe eines Videostreams durch einen Client (C), wobei der Videostream Frames von genau einer Kamera in Bezug auf ein sich relativ hierzu bewegendes Objekt aus unterschiedlichen Positionen aufweist, aufweisend die Schritte • Erhalten eines Videostreams (VB) von einem Kodierer (SRV), • Dekodieren des erhaltenen Videostreams (VB) unter Verwendung von Kameraparametern (CP) und Geometrie-Daten (GD), • Wiedergabe des aufbereiteten Videostreams (AVB).

Description

Verfahren zur Wiedergabe eines Videostreams durch einen Client
Hintergrund
Die digitale Kodierung von Videosignalen ist in der gegenwärtigen Zeit in vielen Formen zu finden. So werden z.B. digitale Videoströme auf Datenträgern, wie z.B. DVDs, Blu-ray oder als Download bzw. Videostream (z.B. auch für Videokommunikation) zur Verfügung gestellt. Dabei ist es Ziel der Videokodierung nicht nur Repräsentanzen der zu übermittelnden Bilder zu versenden, sondern gleichzeitig auch den Datenverbrauch gering zu halten. Dies erlaubt zum einen auf speicherplatzbeschränkten Medien wie z.B. DVDs mehr Inhalt zu speichern oder aber mehreren Verwendern den gleichzeitigen Transport von (unterschiedlichen) Videostreams zu ermöglichen.
Dabei wird zwischen verlustloser und verlustbehafteter Kodierung unterschieden.
Allen Ansätzen gemein ist, dass aus zuvor übertragenen Bildern Information für nachfolgende Bilder vorherbestimmt wird.
Gegenwärtige Analysen gehen davon aus, dass der Anteil solcher kodierten Videosignale im Jahr 2022 einen Anteil von 82 % des gesamten Netzwerkverkehrs (gegenüber 75 % im Jahr 2017) ausmachen wird, siehe Cisco Visual Networking Index: Forecast and trends, 2017-2022 (white paper), Cisco, Feb. 2019.
Hieraus wird ersichtlich, dass jegliche Einsparung, die hier erreicht werden kann, zu einer großen Einsparung an Datenvolumen und damit zu einer Einsparung an elektrischer Energie für den Transport führen wird.
In aller Regel wird ein Kodierer, ein Trägermedium, z.B. ein Übertragungskanal, und ein Dekodierer benötigt. Der Kodierer verarbeitet rohe Videodaten. Dabei wird in aller Regel ein einzelnes Bild als Frame bezeichnet. Wiederum kann ein Frame als eine Ansammlung von Pixeln verstanden werden. Ein Pixel repräsentiert dabei einen Punkt im Frame und gibt seinen Farbwert und / oder seine Helligkeit an. Dabei kann z.B. die Datenmenge für einen nachfolgenden Frame reduziert werden, wenn bereits ein Großteil der Information in einem oder mehreren zuvor kodierten Frame(s) enthalten ist/sind. Dann wäre es z.B. ausreichend, wenn nur die Differenz übermittelt wird. Dabei macht man sich die Erkenntnis zu nütze, dass in aufeinanderfolgenden Frames häufig viele gleiche Inhalte zu sehen sind. Dies ist z.B. dann der Fall, wenn eine Kamera eine bestimmte Szene aus einem Blickwinkel erfasst und sich nur wenige Dinge ändern, oder wenn sich eine Kamera langsam durch die Szene bewegt oder dreht (Translation und/oder affine Bewegung der Kamera).
Dieses Konzept stößt jedoch dann an seine Grenzen, wenn sich ein hoher Anteil zwischen Frames ändert, wie es z.B. bei einer (schnellen) Bewegung der Kamera innerhalb einer Szene bzw. einer Bewegung von Objekten innerhalb der Szene auftritt. In diesem Fall könnte im schlimmsten Fall jegliches Pixel zweier Frames verschieden sein.
Aus dem Stand der Technik, beispielsweise aus der europäischen Patentanmeldung EP 2 541 943 Al, sind Verfahren für Mehrkamerasysteme bekannt. Allerdings sind diese Mehrkamerasysteme darauf ausgelegt, dass ein vorher bekanntes Setup von Kameras mit vorbekannten Parametern verwendet wird.
Wird jedoch eine Kamera, d.h. ein monokulares Aufnahmesystem, verwendet, so ergibt sich ein völlig anderes Anforderungsprofil. In vielen Bereichen, z.B. bim autonomen Fahren, bei Drohnen, bei Sozial Media Videoaufnahmen, oder auch bei Body-Cams oder Action-Cams, wird hingegen in aller Regel nur eine einzige Kamera verwendet. Aber gerade hier ist es notwendig sowohl den verwendeten Speicherplatz und/oder eine zu übertragende Datenmenge klein zu halten.
Aufgabe
Ausgehend hiervon ist es eine Aufgabe der Erfindung eine Verbesserung für Einkamera-System bereitzustellen.
Kurzdarstellung der Erfindung Die Aufgabe wird gelöst durch ein Verfahren nach Anspruch 1. Weitere vorteilhafte Ausgestaltungen sind Gegenstand der abhängigen Ansprüche, der Beschreibung und der Figuren.
Kurdarstellung der Figuren
Fig. 1 zeigt schematische Ablaufpläne gemäß Aspekten der Erfindung,
Fig. 2 zeigt schematische Ablaufpläne gemäß weiteren Aspekten der Erfindung,
Fig. 3 zeigt schematische Ablaufpläne gemäß weiteren Aspekten der Erfindung,
Fig. 4 zeigt eine schematische Darstellung zur Erläuterung von konzeptionellen Fragen, und Fig. 5 zeigt eine beispielhafte Relation von Frames gemäß weiteren Aspekten der Erfindung.
Ausführliche Darstellung der Erfindung
Nachfolgend wird die Erfindung eingehender unter Bezugnahme auf die Figuren dargestellt werden. Dabei ist anzumerken, dass unterschiedliche Aspekte beschrieben werden, die jeweils einzeln oder in Kombination zum Einsatz kommen können. D.h. jeglicher Aspekt kann mit unterschiedlichen Ausführungsformen der Erfindung verwendet werden, soweit nicht explizit als reine Alternative dargestellt.
Weiterhin wird nachfolgend der Einfachheit halber in aller Regel immer nur auf eine Entität Bezug genommen werden. Soweit nicht explizit vermerkt, kann die Erfindung aber auch jeweils mehrere der betroffenen Entitäten aufweisen. Insofern ist die Verwendung der Wörter „ein", „eine" und „eines" nur als Hinweis darauf zu verstehen, dass in einer einfachen Ausführungsform zumindest eine Entität verwendet wird.
Soweit nachfolgend Verfahren beschrieben werden, sind die einzelnen Schritte eines Verfahrens in beliebiger Reihenfolge anordbar und/oder kombinierbar, soweit sich durch den Zusammenhang nicht explizit etwas Abweichendes ergibt. Weiterhin sind die Verfahren - soweit nicht ausdrücklich anderweitig gekennzeichnet - untereinander kombinierbar.
Nachfolgend werden wir auf verschiedene Aspekte der Erfindung im Zusammenhang mit einem vollständigen System aus Kodierer und Dekodierer eingehen. Fehler, die zwischen dem Kodieren und Dekodieren auftreten können, werden nachfolgend nicht beleuchtet, da sie für das Verständnis des (De-) Kodierens nicht relevant sind. ln den gängigen Videobereitstellungssystemen basiert der Kodierer auf Vorhersage/Prädiktion (engl. Prediction). D.h. je besser man einen zu kodierenden Frame aus einem vorher dekodierten Frame Vorhersagen kann, umso weniger Information (Bit(s)) muss übertragen werden.
In den bisherigen Ansätzen wurde der Ansatz verfolgt, Frames auf Grund von Ähnlichkeiten zwischen den Frames in einem zweidimensionalen Modell vorherzusagen.
Es ist jedoch festzustellen, dass die Aufzeichnung von Videos meistens im dreidimensionalen Raum stattfindet.
Mit nun verfügbarer Rechenleistung Ist es möglich Tiefeninformation auf Seiten des Kodierers und/oder des Dekodierers zu ermitteln/abzuschätzen.
Daher kann innerhalb der Erfindung auch ein dreidimensionales Bewegungsmodell zur Verfügung gestellt werden. Ohne Beschränkung der Allgemeinheit der Erfindung ist es dabei möglich die Erfindung auch mit allen gegenwärtigen Video(de)kodierern einzusetzen soweit sie entsprechend aufgerüstet sind. Insbesondere kann der Erfindung Versatile Video Coding ITU-T H.266/ ISO/IEC 23090- 3 hinzugefügt werden.
Dabei basiert die Erfindung auf der Idee der bewegungskompensierenden Vorhersage (engl. Motion- compensated prediction). Um dies zu motivieren verweisen wir nachfolgend auf Figur 4. Dabei wird ein Video aus (aufeinanderfolgenden) kodierten Bildern von zweidimensionalen Frames (d.h. eine Sequenz) betrachtet. Ein Frame wird dabei auch als zweidimensionale Repräsentation bezeichnet. Aufgrund der zeitlichen Redundanz zwischen aufeinanderfolgenden Frames kann ein zu (kodierender) Frame zum Zeitpunkt t aus zuvor (t-1, t-2 ... (dargestellt t-4) ohne auf vier vorhergehende Frames beschränkt zu sein) kodierten Frames vorhergesagt werden. Diese vorhergehenden Frames werden auch als Referenz (Referenzframes, Referenzbilder) bezeichnet. Es sei dabei angemerkt, dass hier die Framereihenfolge nicht notwendigerweise eine zeitliche Reihenfolge sein muss, sondern dass die dargestellte Reihenfolge und die (de)kodierte Reihenfolge unterschiedlich sein kann. D.h. für das (De- )Kodieren können nicht nur Informationen aus zeitlich vorher liegenden Frames, sondern auch Informationen aus zeitlich nachfolgenden (in der Darstellung / zeitlichen Abfolge zukünftigen) Frames verwendet werden, Falls die bewegungskompensierte Vorhersage präzise genug ist, reicht es aus nur den Unterschied zwischen der Vorhersage und dem zu kodierenden Frame, den sogenannten Vorhersagefehler (engl. prediction error) zu übertragen. Je besser die Vorhersage ist, umso weniger Vorhersagefehler müssen übermittelt werden, d.h. umso weniger Daten müssen zwischen Kodierer und Dekodierer übermittelt bzw. gespeichert werden.
D.h., aus Sicht des Kodierers steigt die Effizienz.
Die herkömmlichen Kodierer basieren auf der Ähnlichkeit von Frames in einem zweidimensionalen Modell, d.h. lediglich Translationen und/oder affine Bewegungen werden in Betracht gezogen. Es gibt jedoch eine Reihe von Bewegungen, die nicht einfach als 2D-Modell ausgedrückt werden können.
Daher verwendet diese Erfindung einen Ansatz der auf der dreidimensionalen Umgebung basiert, in dem die Sequenz erfasst ist und hieraus ein 3D-Bewegungsmodell darstellbar wird.
Praktisch gesehen ist die Videoaufnahme analog zur Projektion einer dreidimensionalen Szene in die zweidimensionale Ebene der Kamera. Da jedoch bei der Projektion die Tiefeninformation verloren geht, ermöglicht die Erfindung eine anderweitige Bereitstellung.
Im Beispiel des Ablaufplanes nach Figur 1 wird auf Seiten des Dekodierers die 3D-lnformation rekonstruiert, während im Beispiel des Ablaufplanes nach Figur 2 der Kodierer die 3D-lnformation (komprimiert) zur Verfügung stellt und der Dekodierer sie lediglich verwendet. Im Beispiel des Ablaufplanes nach Figur 3 wird eine Mischform zur Verfügung gestellt, bei der der Kodierer die (grobe) 3D-lnformation (komprimiert) zur Verfügung stellt, und der Dekodierer die 3D-lnformation weiter aufbereitet, um sie zu verbessern.
Es ist offensichtlich, dass im ersten Fall die notwendige Bandbreite / Speicherkapazität geringer sein kann als im zweiten oder dritten Fall. Andererseits sind die Anforderungen an die Rechenleistung im ersten Fall für den Kodierer und den Dekodierer hoch, während im zweiten Fall die Anforderungen an die Rechenleistung für den Dekodierer geringer und für den Kodierer am höchsten sind. D.h. auf Basis der zur Verfügung stehenden Möglichkeiten können unterschiedliche Szenarien bedient werden. Insbesondere bei einer Abfrage nach einem Videostrom kann es daher vorgesehen sein, dass z.B. ein Dekodierer seine Eigenschaften dem Kodierer bekannt macht, sodass der Kodierer unter Umständen auf die Bereitstellung von (präziser) 3D-lnformation verzichten kann, weil der Dekodierer ein Verfahren nach Figur 1 oder 3 zur Verfügung stellt.
Nachfolgend gehen wir davon aus, dass die Kamera irgendeine Kamera ist und nicht auf einen bestimmten Typ festgelegt ist.
Im Folgenden wird auf eine monokulare Kamera mit unbekannten Kameraparametern als schwierigster Anwendungsfall Bezug genommen werden, ohne jedoch hierdurch die Verwendung anderer Kameratypen, wie. z.B. Lichtfeld, Stereokamera, etc. auszuschließen.
Dabei kann auf die Kameraparameter CP und Geometrie-Daten GD geschlossen werden. Auf die Kameraparameter CP kann z.B. durch Verfahren wie Structure from Motion, Simultaneous Localization and Mapping oder Sensoren geschlossen werden.
Sind solche Daten durch bestimmte Kameratypen, z.B. Stereokameras und/oder durch zusätzliche Sensoren, wie z.B. LIDAR-Sensoren, Gyroskope, etc. bekannt, so können diese alternativ oder zusätzlich übermittelt oder verarbeitet werden und somit den Rechenaufwand vermindern oder obsolet machen. Die Kameraparameter CP können typischerweise aus Sensordaten von Gyroskopen, inertiale Messeinheit (englisch inertial measurement unit, IMU), Ortsdaten eines Global Positioning System (GPS), etc. ermittelt werden, während Geometrie-Daten GD aus Sensordaten eines LIDAR- Sensors, Stereokameras, Tiefensensoren, Lichtfeldsensoren, etc. ermittelt werden. Stehen sowohl Kameraparameter CP und Geometrie-Daten GD zur Verfügung wird die (de-)Kodierung einfacher und in der Regel qualitativ besser.
Der Kodierer SRV kann z.B. ein herkömmliches Videosignal Input Video in Schritt 301 erhalten. Vorteilhafterweise kann dieses Videosignal auf Bewegung, d.h. eine Relativbewegung der Kamera überwacht werden. Wird eine Relativbewegung der Kamera erkannt, so kann das Eingangsvideosignal Input Video einer erfindungsgemäßen Kodierung unterzogen werden, andernfalls, wenn keine Relativbewegung der Kamera erkannt wird, kann das Signal wie bisher einer üblichen Kodierung unterzogen werden und wie in Schritt 303, 403, 503 angedeutet dem Dekodierer C zur Verfügung gestellt werden. Eine Kamerabewegung kann in Ausführungsformen seitens des Kodierers z.B. durch visuelle Datenverarbeitung des Videosignals und/oder durch Sensoren, wie z.B. ein IMU (Inertial Measurement Unit), ein GPS (Global Positioning System), etc. erkannt werden.
Wird hingegen eine Bewegung erkannt, so kann ein entsprechendes Flag Flag_3D oder eine andere Signalisierung verwendet werden, um das Vorhandensein von erfindungsgemäßem Inhalt gemäß Schritt 304, 404, 504 zu signalisieren, sollte er nicht aus dem Datenstrom bereits an sich erkennbar sein.
Wird eine Kamerabewegung festgestellt, können wie in Schritt 305, 405, 505 angedeutet die (intrinsischen und extrinsischen) Kameraparameter CP in Schritt 306, 406, 506 abgeschätzt / bestimmt werden.
Hierzu können Techniken wie z.B. visuelle Datenverarbeitung, wie z.B. Structure-from-Motion (SfM), Simultaneous Localization and Mapping (SLAM), Visual Odometry (V.O.), oder jedes andere geeignete Verfahren verwendet werden.
Die Kameraparameter CP können natürlich auch durch andere Sensoren abgeschätzt / bestimmt / als bekannter Wert übernommen werden.
Ohne Beschränkung der Allgemeinheit der Erfindung können diese Kameraparameter CP in Schritt 307, 407, 507 verarbeitet und kodiert werden und getrennt oder eingebettet in den Videostream VB dem Dekodierer C zur Verfügung gestellt werden.
Die Geometrie im dreidimensionalen Raum kann in Schritt 310, 410, 510 abgeschätzt / bestimmt werden. Insbesondere kann in Schritt 310 die Geometrie im dreidimensionalen Raum aus einem oder mehreren zuvor kodierten Frames (Schritt 309) abgeschätzt werden. Hierzu können die zuvor ermittelten Kameraparameter CP in Schritt 308 einfließen. In den Ausführungsformen der Figuren 2 und 3 können die 3D Geometriedaten aus „rohen" Daten abgeschätzt / bestimmt werden. In der Ausführungsform der Figur 1 können diese Daten aus den kodierten Daten abgeschätzt / bestimmt werden. Typischerweise wird die visuelle Qualität in den Ausführungsformen der Figur 2 und 3 besser sein als in der Ausführungsform der Figur 1, sodass diese Ausführungsformen höherwertige 3D Geometriedaten bereitstellen können. Um die Geometrie im dreidimensionalen Raum abzuschätzen kann man sogenannte Multi-View Computer Vision Techniken verwenden, ohne hierdurch die Verwendung anderer Techniken, wie z.B. eventuell vorhandene Tiefensensoren, wie z.B. LiDAR, oder andere Bildsensoren, die eine Tiefenerkennung erlauben, wie z.B. Stereokameras, RGB+D Sensoren, Lichtfeldsensoren, etc. auszuschließen.
Die so ermittelte Geometrie im dreidimensionalen Raum kann durch eine geeignete Datenstruktur, z.B. ein 3D Modell, ein 3D-Netz, 2D-Tiefenkarten, Punktwolken (dünnbesetzt oder dicht), etc. repräsentiert sein.
Nunmehr kann das Videosignal VB auf Basis der ermittelten Geometrie im drei-dimensionalen Raum in Schritt 312, 412, 512 kodiert werden.
Dabei kann nun das neuartige bewegungsbasierte Modell auf die reproduzierte dreidimensionale Information angewendet werden.
Hierzu kann beispielsweise ein Referenzbild in Schritt 311 bestimmt / gewählt sein. Dies kann dann dem Standard Video Kodierer in Schritt 312 präsentiert werden.
Offensichtlich kann die nun folgende Kodierung auf einen, mehrere oder alle Frames einer vorbestimmten Menge verwendet werden. Entsprechender Weise kann natürlich auch die Kodierung sich auf einen, mehrere oder alle vorherigen Frames einer vorbestimmten Menge stützen.
Es kann auch vorgesehen sein, dass der Kodierer SRV nur einige räumliche Gebiete innerhalb eines Frames in der vorgegebenen erfindungsgemäßen Weise verarbeitet und andere in herkömmlicher Weise.
Wie bereits ausgeführt, kann ein Standard Video Kodierer verwendet werden. Dabei kann eine zusätzliche Referenz zur Liste der Referenzbilder (in Schritt 311) hinzugefügt werden oder aber ein bestehendes Referenzbild ersetzt werden. Ebenso kann wie bereits angedeutet nur ein bestimmter Raumbereich mit der neuen Referenz überschrieben sein. Hierdurch kann der Standard-Videokodierer in die Lage versetzt werden eigenständig auf Basis der vorhandenen Referenzbilder das Referenzbild auszusuchen, dass eine günstige Eigenschaft besitzt, z.B. eine hohe Kompression bei geringen Verfälschungen (rate-distortion optimization).
So kann der Standard-Videokodierer unter Verwendung der synthetisierten Referenz den Videostrom kodieren und in Schritt 313, 413, 513 dem Dekodierer C zur Verfügung stellen.
Wie in bisherigen Verfahren auch, kann der Kodierer SRV an entsprechenden Wiedereinstiegspunkte erneut mit einer Erkennung gemäß Schritt 301 beginnen und das Verfahren erneut durchlaufen.
Wiedereinstiegspunkte können zu festgesetzten Zeitintervallen, auf Basis von Kanaleigenschaften, der Bildrate des Videos, der Anwendung etc. gesetzt werden.
Dabei kann die 3D-Geometrie im dreidimensionalen Raum jeweils neu rekonstruiert werden oder eine bestehende weiterentwickeln. Die 3D-Geometrie wächst mit zunehmend neuen Frames weiter an bis sie beim nächsten Wiedereinstiegspunkt neugestartet wird.
In entsprechender Weise kann auf der Dekoderseite C agiert werden, wobei in den Figuren 1 bis 3 Kodierer SRV und Dekodierer C in ihren funktional entsprechenden Komponenten auf horizontal etwa gleicher Höhe angeordnet sind.
So kann der Dekodierer C zunächst überprüfen, ob ein entsprechendes Flag Flag_3D oder eine andere Signalisierung verwendet wurde.
Ist eine solche Signalisierung (Flag_3D ist z.B. 0) nicht vorhanden, so kann der Videostream standardmäßig behandelt in Schritt 316 behandelt werden. Andernfalls kann der Videostream in der neuen erfindungsgemäßen Art und Weise behandelt werden.
Zunächst können Kameraparameter CP in Schritt 317, 417, 517 erhalten werden. Die erhaltenen Kameraparameter CP können in optionalen Schritten 318 verarbeitet und / oder dekodiert werden. Diese Kameraparameter CP können z.B. für eine Tiefenschätzung als auch für die Erzeugung der Geometrie im dreidimensionalen Raum in Schritt 320 auf Basis von vorhergehenden Frames 319 genutzt werden.
Insgesamt kann dabei die gleiche Strategie in Bezug auf die Referenzbilder wie beim Kodierer (Schritte 309...312, 409...412, 509...512) in entsprechenden Schritten 319...332, 419...432, 519...532 Verwendung finden. Es ist z.B. möglich das synthetisierte Referenzbild in Schritt 321 zu rendern, indem man den zuvor dekodierten Frame (Schritt 319) in den zu-dekodierenden Frame umformt, unter Führung der dekodierten Kameraparameter CP (Schritt 318) und der Geometrie im dreidimensionalen Raum (Schritt 320).
Schließlich kann in Schritt 323, 423, 523 der erfindungsgemäß verarbeitete Videostream durch einen Standard-Videokodierer dekodiert werden und als dekodierter Videostream 324, 424, 524 zur Ausgabe gebracht werden.
Üblicherweise sollten dabei der Dekodierer mit dem Kodierer in Bezug auf die Einstellungen synchron sein, sodass der Dekodierer C die gleichen Einstellungen (insbesondere für die Tiefenbestimmung, Referenzerstellung, etc.) wie der Kodierer SRV verwendet.
In der Ausführungsform der Figur 2 kann im Unterschied zur Ausführungsform der Figur 1 die Geometrie im dreidimensionalen Raum aus rohen Videoframes in Schritt 405 abgeschätzt werden. Dabei kann aus den Daten ein (zusätzlicher) Bitstrom 410.1 erzeugt werden, der z.B. Gegenstand weitere Verarbeitung, z.B. Dezimierung, (verlustfreier/verlustbehafteter) Kompression und Kodierung ist, der an den Dekodierer C zur Verfügung gestellt werden kann. Dieser zur Verfügung gestellte Bitstrom 2.2 kann nun auch - wie im Dekodierer C - in Schritt 410.2 (zur Sicherstellung der Kongruenz der Daten) zurückgewandelt werden und der Verarbeitung in Schritt 411 zur Verfügung gestellt werden.
Ebenso kann die Geometrie im dreidimensionalen Raum auch über einen Wiedereinstiegspunkt hinaus erhalten bleiben. Jedoch erlaubt das Verfahren auch die ständige Verbesserung der Geometrie im dreidimensionalen Raum auf Basis vorheriger und aktueller Frames. Diese Geometrie im dreidimensionalen Raum kann geeignet Gegenstand weitere Verarbeitung, z.B. Dezimierung (z.B. Mesh Decimation), (verlustfreier/verlustbehafteter) Kompression / Kodierung sein. In entsprechender Weise kann den Dekodierer C den in Schritt 419.1 erhaltenen Bitstrom 2.2 mit den Daten betreffend die Geometrie im dreidimensionalen Raum erhalten und dekodieren. Die dekodierte Geometrie im dreidimensionalen Raum kann dann in Schritt 420 verwendet werden.
Offensichtlich kann der Dekodierer in dieser Variante schneller arbeiten, da die Dekodierung geringeren Aufwand als die Rekonstruktion der Geometrie im dreidimensionalen Raum (Figur 1) erfordert.
Während in der Ausführungsform der Figur 1 ein sehr effizientes Verfahren in Bezug auf die Bitratenreduktion vorgestellt wird, kann mit der Ausführungsform der Figure 2 eine geringere Bitratenreduktion erzielt werden, wofür aber die Komplexität auf Seiten des Dekodierers C sinkt. Die Ausführungsform der Figur 3 kombiniert Aspekte der Ausführungsformen der Figur 1 und Figur 2, verteilt die Komplexität und erlaubt ein flexibles und effizientes Verfahren.
Im Wesentlichen unterscheidet sich das Konzept der Ausführungsform der Figur 3 von der Ausführungsform der Figur 2 darin, dass die Geometrie im dreidimensionalen Raum, d.h. die 3D-Daten in Schritt 510.1 grob die ursprüngliche Geometrie im dreidimensionalen Raum repräsentieren, d.h. in abgespeckter Version, sodass die benötigte Bitrate hierfür sinkt. Hierfür kann jedes geeignete Verfahren zur Datenreduktion wie z.B. Unterabtastung (sub-sampling), grobe Quantisierung (coarse quantization), Transformationskodierung und Dimensionsreduktion, etc. verwendet werden, ohne hierauf beschränkt zu sein.
Die so minimierten 3D Daten können wie zuvor in Schritt 510.2 kodiert und an den Dekodierer C zur Verfügung gestellt werden. Der Bitstrom 510.1/510.2 kann Gegenstand weiterer Verarbeitung, z.B. Dezimierung, (verlustfreier/verlustbehafteter) Kompression und Kodierung sein, die dem Dekodierer C zur Verfügung gestellt werden kann. Dieser zur Verfügung gestellte Bitstrom 2.2 kann nun auch - wie im Dekodierer C - in Schritt 510.3 (zur Sicherstellung der Kongruenz der Daten) zurückgewandelt werden und der Verarbeitung in Schritt 511 zur Verfügung gestellt werden. Dabei können die zuvor kodierten Frames 509 und die Kameraparameter 506 zur feineren Erarbeitung der 3D-Daten verwendet werden. Entsprechender Weise kann der Dekodierer C die kodierten und minimierten 3D-Daten in Schritt 519.1 erhalten und in Schritt 519.2 dekodieren und - entsprechend zum Kodierer SRV - der Verarbeitung zur Verfügung gestellt werden. Dabei können die zuvor kodierten Frames 519.3 und Kameraparameter 518 zur feineren Erarbeitung der 3D Daten verwendet werden.
D.h. in allen Ausführungsformen des Dekodierers C wird ein Videostream VB vom Kodierer SRV, z.B. ein Streamingserver, In einem ersten Schritt 315, 415, 515 erhalten.
Der Client C dekodiert den erhaltenen Videostream VB unter Verwendung von Kameraparametern CP und Geometrie-Daten GD, und gibt diesen anschließend als aufbereiteten Videostream AVB in Schritt 324, 424, 524 wieder.
Wie in den Figuren 1 bis 3 aufgezeigt können in Ausführungsformen der Erfindung die Kameraparameter CP von dem Kodierer SRV in Schritt 317, 417, 517 (z.B. als Bitstream 2.1) erhalten werden oder aus dem erhaltenen Videostream VB bestimmt werden.
In Ausführungsformen der Erfindung können Geometriedaten GD von dem Kodierer SRV (z.B. als Bitstream 2.2) erhalten werden oder aus dem erhaltenen Videostream VB bestimmt werden.
Insbesondere kann vorgesehen sein, dass vor Erhalt des Videostreams VB der Dekodierer C dem Kodierer SRV seine Befähigung zur Verarbeitung signalisiert. Dabei kann auch ein Set an Möglichkeiten der Verarbeitung mitgeliefert sein, sodass der Kodierer das geeignete Format zur Verfügung stellen kann. Das zur Verfügung gestellte Format kann hierzu eine entsprechende Kodierung bezüglich Einstellungsdaten aufweisen.
In einer Ausführungsform der Erfindung weisen die Geometriedaten Tiefendaten auf.
Zusammenfassend sei nochmals darauf hingewiesen, dass im Falle der Figur 1 eine 3D Rekonstruktion sowohl auf der Seite des Kodierers als auch des Dekodierers zur Anwendung kommt. Im Beispiel der Figur 2 wird nur durch den Kodierer eine 3D Rekonstruktion durchgeführt und dem Dekodierer zur Verfügung gestellt. D.h. der Dekodierer muss keine 3D Rekonstruktion durchführen, sondern kann die vom Kodierer bereitgestellte 3D Geometriedaten verwenden. Die Abschätzung der 3D Geometriedaten auf Seiten des Kodierers ist dabei in aller Regel einfacher als auf Seiten des Dekodierers. Insbesondere dann, wenn die Rechenleistung auf Seiten des Dekodierers beschränkt ist, ist die Ausgestaltung gemäß Figur 2 vorteilhaft. Im Falle der Figur 3 wird wie in Figur 2 durch den Kodierer eine 3D Rekonstruktion durchgeführt und dem Dekodierer zur Verfügung gestellt. Allerdings wird hierbei nur eine Grobfassung der 3D Geometriedaten zur Verfügung gestellt. Hierdurch kann die Bitrate für die 3D Geometriedaten verringert werden. Zugleich muss aber der Dekodierer nun die 3D Geometriedaten nachvervollständigen/nachbearbeiten (Refine).
Die Wahl des Verfahrens (z.B. gemäß Figur 1, Figur 2 oder Figur 3) kann durch den Kodierer und den Dekodierer ausgehandelt werden. Dies kann z.B. auf Basis vorherigen Wissens (z.B. Rechenleistung) oder aber auch über einen Steuer- / Rückkanal (adaptiv) erfolgen, um z.B. auch Änderungen in der Übertragungskapazität zu berücksichtigen. In einem Broadcast Szenario, dass sich an mehrere Dekodierer richtet, wird in aller Regel die Ausgestaltung gemäß der Figur 2 bevorzugt sein.
Auch wenn die Erfindung in Bezug auf Verfahren beschrieben ist, so ist doch dem Fachmann verständlich, dass die Erfindung auch in Hardware, insbesondere durch Software eingerichtete Hardware zur Verfügung gestellt werden kann. Hierfür können gängige (De-)Kodiereinheiten, spezielle Recheneinheiten wie GPUs und DSPs ebenso wie ASICs oder FPGAs basierte Lösungen zum Einsatz kommen, ohne hierdurch die Anwendbarkeit allgemeiner Mikroprozessoren auszuschließen.
Insbesondere kann die Erfindung demnach auch in Computerprogrammprodukten zur Einrichtung einer Datenverarbeitungsanlage zur Durchführung eines Verfahrens verkörpert sein.
Mit der Erfindung ist es möglich signifikante Einsparungen bei der Bitrate von mehreren Prozent zu erreichen, wenn entsprechend kodierbare Szenen vorliegen.
Nachfolgend sei zunächst angenommen, dass zu einem bestimmten Zeitpunkt eine fortlaufende Videoaufnahme kodiert werden soll. Dabei sind bereits einige Frames kodiert und ein weiterer Frame, der "to-be-encoded frame", soll nun kodiert werden. Je nachdem, wo sich der Frame in der Abfolge befindet und/oder je nach verfügbarer Datenrate bzw. Vidoekodiereinetstellung, kann dieser "to-be- encoded frame" mittels Intra-prediction oder Inter-prediction Werkzeugen kodiert werden. Typischerweise würde man z.B. für jeden ersten Rahmen einer Gruppe von Bildern (engl. Group of Pictures - abgek. GOP), z.B. dem 16ten frame (d.h. frame mit OrdnunungsnummerO, 16, 32, ... ) Intra- prediction Werkzeuge verwenden, während man für die "Zwischenframes" hierzu Inter-prediction Werkzeuge verwenden würde.
Von besonderem Interesse im Rahmen der Erfindung sind die Rahmen, die mittels Inter-prediction Werkzeugen, zu kodieren sind, d.h. im Beispiel die Rahmen 1-15, 17-31, 33-47, ... , ... .
Die wesentliche Idee bei Inter-prediction Werkzeugen ist es zeitliche Ähnlichkeiten zwischen aufeinanderfolgenden Rahmen zu nutzen. Falls ein Block eines zu kodierenden Rahmens ähnlich zu irgendeinem Rahmen in dem zuvor kodierten Rahmen ist (z.B. wegen einer Relativbewegung), so kann anstatt diesen Block erneut zu kodieren einfach auf diesen bereits kodierten Block verwiesen werden. Dieser Vorgang kann als Bewegungsausgleich (engl. „motion compensation") bezeichnet werden. Hierzu wird eine für jeden Rahmen neue Auflistung zuvor kodierter Rahmen verwendet, die als Referenz für den Bewegungsausgleich verwendet werden kann. Diese Liste wird auch Referenzbilderliste bezeichnet. Im Kern kann der Kodierer dabei den zu kodierenden Rahmen in einige nicht-überlappende Blöcke teilen. Anschließend kann der so erstellte Block mit zuvor kodierten Blöcken gemäß der dazu korrespondierenden Auflistung verglichen werden, um eine hohe - bevorzugt beste Übereinstimmung- aufzufinden. Die relative 2D Position des jeweiligen aufgefunden Blocks (d.h. der Bewegungsvektor) und die Differenz zwischen dem erstellten Block und dem aufgefundenen Block (d.h. das Rest-Signal (engl. residual signal)) kann dann (zusammen mit weiteren erstellten Blöcken, deren Position und deren Differenzen) kodiert werden.
Im Rahmen der Erfindung wird mindestens ein neuartiges Referenzbild basierend auf 3D Information erstellt und zu dieser Referenzbilderliste hinzugefügt oder statt eines vorhanden Referenzbildes eingefügt werden. Hierzu wird für eine einzige (monokulare) Kamera die Kameraparameter CP und für die 3D Szenen Geometrie Geometrie-Daten GD aus einem Satz von 2D Bildern erstellt, welchen von der sich bewegenden monokularen Kamera erfasst wurden.
Hieraus wird ein neuartiges Referenzbild basierend auf 3D Information für zu kodierende Rahmen erstellt, z.B. indem der Inhalt herkömmlicher Referenzbilder auf die Position des zu kodierenden Bildes verzerrt wird. Dieser Verzerrungsvorgang wird durch die erstellten / abgeschätzten Kameraparameter CP und für die 3D Szenen Geometrie Geometrie-Daten GD geleitet. Das so synthetisierte neuartiges Referenzbild basierend auf 3D Information erstellt und zu dieser Referenzbilderliste hinzugefügt. Das so erstellte neuartiges Referenzbild erlaubte eine verbesserte Leistungsfähigkeit in Bezug auf den Bewegungsausgleich, d.h. benötigt eine geringere Bitrate als herkömmliche Referenzbilder in der Referenzbilderliste. Hierdurch kann auch die am Ende benötigte Bitrate verringert werden und der Kodiergewinn erhöht werden.
Um die Laufzeit des Dekodierers gering zu halten können verschiedene Ansätze verwendet werden.
Zum einen ist festzustellen, dass die Synthese von Referenzbildern auf Seiten des Dekoders zeitintensiv ist. Es kann jedoch ausreichend sein, den Kodierer mit dem neuartiges 3D-Referenzbild nur für eine oder mehrere Teilbereiche / Regionen in dem zu kodierenden Rahmen zu verwenden, z.B. 20 % - 30 % der Fläche / Pixel, nämlich insbesondere für jene, bei denen es eine gute Inter-Frame Vorhersage durch Optimierung gibt. Beispeilhaft sei dies wie folgt illustriert. Es sei angenommen, dass es 3 Referenzen RI, R2, R3D gibt und ein zu-kodierender Frame sei in nicht übverschneidende Blöcke unterteilt. R3D wäre dann eine der durch die Erfindung bereitgestellten Referenzen. Dann würde der Kodierer zunächst einen ersten Block wählen und überprüfen, welches der ähnlichste Block in einem der Referenzen ist; dies würde dann nach und nach für jeden Block durchgeführt. Typischerweise wird in 20 % - 30 % der Fälle R3D aufgefunden während im Rest der Fälle RI oder R2 aufegefunden wird. Diese Information, welches Referenzbild für welchen Block verwendet wird kann in den Videobitstrom eingespeist werden. Der Dekodierer kann dann diese Information einfach lesen und das neuartiges Referenzbild basierend auf 3D Information zumindest für diese Regionen, d.h. nicht für den gesamten Bereich, zu erstellen. D.h., anders als der Kodierer, reciht es für den Dokidierer unter unständen aus, wenn nur der verewndete Teil der Referenz R3D für die Inter-Prediction erstellt wird, während es nicht notwendig ist die anderen Teile der Refererenz R3D ebenfalls zu erstellen.
Zum anderen kann festgestellt werden, dass Rahmen eine unterschiedliche Anteil zur finalen Bitrate haben, basierend auf deren Reihenfolge und Position in der verwendeten Kodiererstruktur. Hierzu sei auf Figur 5 verwiesen. Die Kreise stellen Rahmen mit der Darstellungsreihenfolge dar. Die Pfeile zeigen die konventionell erstellten Referenzbilder an, die für den Bewegungsausgleich verwendet werden können. Zum Beispiel kann der Rahmen FM Fi und Fi+S als Referenz verwenden. In der hierarchischen Kodierstruktur tragen Rahmen mit einer zeitlichen Kennung 4 (TI D=4) weniger zu finalen Bitrate bei als Rahmen mit einer zeitlichen Kennung von TID<3. Dies liegt hauptsächlich daran, dass diese für den Bewegungsausgleich ihren jeweils unmittelbaren (vorhergehenden / nachfolgenden) Rahmen für den Bewegungsausgleich verwenden, die jedoch fast gleichen Inhalt aufweisen. Dagegen verwendet der Rahmen Fi+g beispielsweise Fi und FM6 als Referenzbilder, die jedoch weiter voneinander entfernt sind.
Wir nehmen für die folgende Überlegung an, dass die im Rahmen der Erfindung vorgeschlagenen Vorgehensweise die Bitrate für jeden Rahmen um 5 % gegenüber dem bisherigen Vorgehen reduziert. Da Rahmen mit TID=4 weniger zu dem finalen Kodiergewinn / der finalen Bitrate beitragen (Annahme 10 % der gesamten Bitrate entfällt auf TID=4) fällt der Anteil der durch die Erfindung hier erzielt werden könnte entsprechend gering aus (5 % von 10 %). Man könnte daher für diesen Bereich auf die Verwendung des erfindungsgemäßen Verfahrens verzichten, da der Beitrag eher gering ist. Damit kann Rechenzeit / Speicherplatz gespart werden, um die Geschwindigkeit hoch zu halten bzw. für Bereiche bereitzuhalten, in denen das erfindungsgemäße Verfahren einen größeren Beitrag zu dem finalen Kodiergewinn / der finalen Bitrate beiträgt.
Wird z.B. angenommen, dass der Gewinn durch das erfindungsgemäße Verfahren bei Anwendung auf alle Rahmen einen finalen Kodiergewinn 3 % bereitstellen würde, so würde das Auslassen der Rahmen mit TID=4 diesen finalen Kodiergewinn auf circa 2,7 % abschmelzen. Hingegen könnte der Kodierer (mehr als) doppelt so schnell sein.
Selbst wenn man das erfindungsgemäße Verfahren nur auf TID<1 anwenden würde, so würde das Auslassen der anderen Rahmen diesen finalen Kodiergewinn auf circa 1 % abschmelzen.
Sinnvollerweise wird der Dekodierer über einen solchen Umstand informiert, falls der Kodierer eine oder mehrere Rahmen mit bestimmten TIDs nur kodiert bzw. nicht kodiert. Je nach Ausgestaltung kann dies durch ein Flag (reduziert / nicht-reduziert) oder durch ein Code-Wort (z.B. 1 für nur TID=l, 2 nur für TID=2, 4 nur TID=3 bzw. 3 für TID 1 und 2, ... ) verwendet werden.
Es sei angemerkt, dass die Kameraparameter CP und für die 3D Szenen Geometrie Geometrie-Daten GD nicht nur einmalig sondern wiederkehrend einzeln oder im Verbund vom Kodierer an den Dekodierer zur Verfügung gestellt werden können. Dabei kann jeweils ein neuer Satz als auch ein Update zur Verfügung gestellt werden.

Claims

Ansprüche Verfahren zur Wiedergabe eines Videostreams durch einen Client (C), wobei der Videostream Frames von genau einer Kamera in Bezug auf ein sich relativ hierzu bewegendes Objekt aus unterschiedlichen Positionen aufweist, aufweisend die Schritte
• Erhalten eines Videostreams (VB) von einem Kodierer (SRV),
• Dekodieren des erhaltenen Videostreams (VB) unter Verwendung von Kameraparametern (CP) und Geometrie-Daten (GD),
• Wiedergabe des aufbereiteten Videostreams (AVB). Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Kameraparameter (CP) von dem Kodierer (SRV) erhalten werden oder aus dem erhaltenen Videostream (VB) bestimmt werden. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Geometrie-Daten (GD) von dem Kodierer (SRV) erhalten werden oder aus dem erhaltenen Videostream (VB) bestimmt werden. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass vor Erhalt des Videostreams (VB) der Client (C) dem Kodierer (SRV) seine Befähigung zur Verarbeitung signalisiert. Verfahren nach einem der der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Geometriedaten Tiefendaten aufweisen. Vorrichtung zur Durchführung eines Verfahrens gemäß einem der Ansprüche 1 bis 5. Computerprogrammprodukt zur Einrichtung einer Datenverarbeitungsanlage zur Durchführung eines Verfahrens gemäß einem der vorhergehenden Ansprüche 1 bis 5. Verfahren zur Bereitstellung eines Videostreams durch einen Kodierer (SRV) an einen Client (C), wobei der Videostream Frames von genau einer Kamera in Bezug auf ein sich relativ hierzu bewegendes Objekt aus unterschiedlichen Positionen aufweist, aufweisend die Schritte
• Erhalten von Frames von einer Kamera in Bezug auf ein Objekt aus unterschiedlichen Positionen in Form eines Videostreams (eVB)
• Encodieren des erhaltenen Videostreams (eVB) unter Verwendung von Kameraparametern (CP) und Geometrie-Daten (GD),
• Streamen des Videostreams (VB). 9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Kameraparameter (CP) von einer externen Quelle erhalten werden oder aus dem erhaltenen Videostream (VB) bestimmt werden.
10. Verfahren nach Anspruch 8 oder 9 dadurch gekennzeichnet, dass die Geometrie-Daten (GD) von einer externen Quelle erhalten werden oder aus dem erhaltenen Videostream (VB) bestimmt werden.
11. Verfahren nach einem der vorhergehenden Ansprüche 9 oder 10, dadurch gekennzeichnet, dass die externe Quelle ein Sensor und/oder die Kameras sind.
12. Verfahren nach einem der der vorhergehenden Ansprüche 8 bis 11, dadurch gekennzeichnet, dass vor dem Streamen des Videostreams (VB) der Kodierer (SRV) von dem Client (C) seine
Befähigung zur Verarbeitung signalisiert bekommt.
13. Verfahren nach einem der der vorhergehenden Ansprüche 1 bis 12, dadurch gekennzeichnet, dass die Geometriedaten Tiefendaten aufweisen.
14. Vorrichtung zur Durchführung eines Verfahrens gemäß einem der Ansprüche 8 bis 13. 15. Computerprogrammprodukt zur Einrichtung einer Datenverarbeitungsanlage zur
Durchführung eines Verfahrens gemäß einem der vorhergehenden Ansprüche 8 bis 13.
PCT/EP2021/083632 2021-01-12 2021-11-30 Verfahren zur wiedergabe eines videostreams durch einen client WO2022152452A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21823541.4A EP4278608A1 (de) 2021-01-12 2021-11-30 Verfahren zur wiedergabe eines videostreams durch einen client
US18/260,755 US20240056654A1 (en) 2021-01-12 2021-11-30 Method for playback of a video stream by a client

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021200225.0 2021-01-12
DE102021200225.0A DE102021200225A1 (de) 2021-01-12 2021-01-12 Verfahren zur Wiedergabe eines Videostreams durch einen Client

Publications (2)

Publication Number Publication Date
WO2022152452A1 true WO2022152452A1 (de) 2022-07-21
WO2022152452A9 WO2022152452A9 (de) 2022-09-01

Family

ID=78829424

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/083632 WO2022152452A1 (de) 2021-01-12 2021-11-30 Verfahren zur wiedergabe eines videostreams durch einen client

Country Status (4)

Country Link
US (1) US20240056654A1 (de)
EP (1) EP4278608A1 (de)
DE (1) DE102021200225A1 (de)
WO (1) WO2022152452A1 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2541943A1 (de) 2010-02-24 2013-01-02 Nippon Telegraph And Telephone Corporation Mehrfachansichts-videokodierungsverfahren, mehrfachansichts-videodekodierungsverfahren, mehrfachansichts-videokodierungsvorrichtung, mehrfachansichts-videodekodierungsvorrichtung und programm dafür
US20140293016A1 (en) * 2011-08-31 2014-10-02 Metaio Gmbh Method for estimating a camera motion and for determining a three-dimensional model of a real environment

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2541943A1 (de) 2010-02-24 2013-01-02 Nippon Telegraph And Telephone Corporation Mehrfachansichts-videokodierungsverfahren, mehrfachansichts-videodekodierungsverfahren, mehrfachansichts-videokodierungsvorrichtung, mehrfachansichts-videodekodierungsvorrichtung und programm dafür
US20140293016A1 (en) * 2011-08-31 2014-10-02 Metaio Gmbh Method for estimating a camera motion and for determining a three-dimensional model of a real environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GOLESTANI HOSSEIN BAKHSHI ET AL: "Reference Picture Synthesis for Video Sequences Captured with a Monocular Moving Camera", 2019 IEEE VISUAL COMMUNICATIONS AND IMAGE PROCESSING (VCIP), IEEE, 1 December 2019 (2019-12-01), pages 1 - 4, XP033693886, DOI: 10.1109/VCIP47243.2019.8965883 *

Also Published As

Publication number Publication date
DE102021200225A1 (de) 2022-07-14
WO2022152452A9 (de) 2022-09-01
US20240056654A1 (en) 2024-02-15
EP4278608A1 (de) 2023-11-22

Similar Documents

Publication Publication Date Title
DE60015566T2 (de) Verfahren und vorrichtung zur komprimierung eines bewegungsvektorfeldes
DE69530908T2 (de) Verfahren und Vorrichtung zur Bildkodierung
DE69834902T2 (de) Bewegungskompensierte prädiktive bildkodierung und -dekodierung
EP2614647B1 (de) Kompression und dekompression von referenzbildern in einem videokoder
DE112017006638T5 (de) Verbesserte Videobitstromkodierung
DE102013015821B4 (de) System und Verfahren zur Verbesserung der Videokodierung unter Verwendung von Inhaltsinformation
DE102007049351A1 (de) Verfahren und Vorrichtung zum Erstellen eines kodierten Ausgangsvideostroms aus mindestens zwei kodierten Eingangsvideoströmen, sowie Verwendung der Vorrichtung und kodierter Eingangsvideostrom
DE10113880B4 (de) Verfahren zur Komprimierung und Dekomprimierung von Videodaten
EP2521357A1 (de) Verfahren und Vorrichtung zur Filterung von kodierten Bildpartitionen
DE112018005899T5 (de) System und Verfahren zum Konstruieren einer Ebene für planare Prädiktion
DE69915843T2 (de) Teilbandkodierung/-dekodierung
DE112012006541B4 (de) Verfahren zur Videokompression
EP0773690A2 (de) Verfahren zur Codierung eines Videodatenstroms
DE10296787B4 (de) Selektive Prädikation für ein Intra-Codieren eines Videodatenblocks
DE60107149T2 (de) Digitales Bildausgabegerät
DE102016003681A1 (de) Datenkompression mittels adaptiven Unterabtastens
DE102011006036B4 (de) Verfahren und Vorrichtungen zur Bildung eines Prädiktionswertes
LU102424B1 (de) Verfahren zur Wiedergabe eines Videostreams durch einen Client
WO2022152452A1 (de) Verfahren zur wiedergabe eines videostreams durch einen client
EP1829378B1 (de) Bildencodierverfahren, sowie dazugehöriges bilddecodierverfahren, encodiervorrichtung und decodiervorrichtung
EP0346635A2 (de) Bildcodierverfahren und Einrichtung
DE19749655B4 (de) Verfahren und Vorrichtung zum Kodieren eines Bewegungsvektors
EP1285537B1 (de) Verfahren und eine anordnung zur codierung bzw. decodierung einer folge von bildern
DE102012202315A1 (de) Videosystem zur Darstellung von Bilddaten, Verfahren und Computerprogramm
DE2703854A1 (de) Bilduebertragungsanlage

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: 21823541

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18260755

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021823541

Country of ref document: EP

Effective date: 20230814