Provision of multiple videos in an android automotive operating system

Abstract

A virtual camera emulator (500) for an automotive operation system, AOS, media system (100) which operates according to a standardized AOS, the AOS including an AOS standard camera input APIs block (502) requiring, in input, a video signal of a pre-defined AOS format, the virtual camera emulator being configured to receive a plurality of video input signals, the plurality of video input signals including: a first video input signal (302a); and, simultaneously, at least a second video input signal (302b); a video signal encapsulation unit (110), configured to encapsulate the plurality of video input signals into one single, encapsulated video signal (112); and a camera hardware abstraction layer, HAL block (202), to transmit the encapsulated video signal (112) to the camera input APIs block (502).

Description

[0001] PROVISION OF MULTIPLE VIDEOS IN AN ANDROID AUTOMOTIVE OPERATING SYSTEM

[0002] There are disclosed techniques for providing multiple videos in a single video e.g. in a video-call for an automotive operating system (AOS). An application regards providing remote device cameras in a vehicle.

[0003] Vehicles often make use of applications operating according to AOSs, e.g. for entertainment, video-calling, etc. A well-known AOS is Android AOS (AAOS).

[0004] Many AOSs (and in particular AAOS) provide application programming interfaces (APIs), which allow for performing tasks. A known APIs block may be a standardized camera input APIs block, which provides standard APIs, output a standardized camera video, to be provided the video-call application. The standardized camera input APIs block is meant to receive a standardized video input signal, in a pre-defined, standard format. A camera hardware abstraction layer, HAL block, is known. The HAL block may be understood as a virtual camera providing video signals to the APIs block (e.g. for sending the video to a remote entity and / or for displaying the video in a local display and / or for further processing the video).

[0005] However, the standardized camera input APIs block has been proven particularly difficult to be adapted or customized to several applications. Indeed, the APIs are resident, and cannot be easily changed. Or, the APIs could be changed, to deviate from the AOS, which would increase the burden for the compatibility with the application layer. APIs could be received from a remote server, for example, but in that case time delay should be necessary. Moreover, a continuous changing of these APIs and routines may endanger the operability of the application. In particular, several AOSs (and in particular AAOS) are quite irksome when concerning the adaptation of the transmission and processing of multiple video signals.

[0006] The standardized camera input APIs block has been conceived for providing one single video. This means that it is arduous to perform teleconferencing when multiple users are in a single vehicle environment (e.g. cockpit), despite multiple videos would be necessary.

[0007] Summary

[0008] There is provided a virtual camera emulator for an automotive operation system, AOS, media system which operates according to a standardized AOS, the AOS including an AOS standard camera input APIs block requiring, in input, a video signal of a pre-defined AOS format, the virtual camera emulator being configured to receive a plurality of video input signals, the plurality of video input signals including: a first video input signal; and, simultaneously, at least a second video input signal; a video signal encapsulation unit, configured to encapsulate the plurality of video input signals into one single, encapsulated video signal; a camera hardware abstraction layer, HAL block, to transmit the encapsulated video signal to the camera input APIs block,

[0009] There is provide an automotive operating system, AOS, media system, comprising the virtual camera emulator and the APIs block (502) to provide a standardized version of the encapsulated video signal to a higher-layer media communication application.

[0010] There is provided a method for supporting the processing of multiple video input signals for an application operating according to an automotive operation system, AOS, the method including: installing a video signal encapsulation unit to encapsulate two video signals into one single encapsulated video signal, and a camera HAL block for providing the single encapsulated video signal according to a standardized, pre-defined format.

[0011] There is provided a media communication method for a vehicle environment, the method using an automotive operation system, AOS, media system operating according to an AOS including an application programming interfaces, APIs, block requiring, in input, one video signal in a pre-defined format, the method comprising: receiving: a first video input signal; and, simultaneously, a second video input signal; encapsulating the first video input signal and the second video input signal into one single, encapsulated video signal; transmitting to an hardware abstract layer, HAL, the encapsulated video signal, so as to convert the single, encapsulated video signal, onto the pre-defined format.

[0012] There is provided a non-transitory storing unit storing code which, when executed by a processor, causes the processor to perform a method as above.

[0013] Figure

[0014] Fig. 1 shows an example. Examples

[0015] Here below there are shown examples of tricking a standardized APIs block 502 by inputting an encapsulated video signal 112 from multiple video signals (e.g. 302a, 302b, 300c). The encapsulation is performed by a virtual camera emulator 500, and in particular by a video signal encapsulation unit 110. The standardized APIs block 502 is “tricked”, because it only receives one single video signal 112 in input, without having the knowledge of receiving two videos signals at all. The output of the standardized APIs block 502 (here indicated as processed version 212 of the encapsulated video signal 112) may be provided to a higher application layer 105 (e.g. a higher-layer media communication application 260), which may, for example, transmit the processed version 212 of the encapsulated video signal 112 to a remote entity 400 (Figs. 1 and 2) e.g. through a remote connection 401 , and / or to a head unit display (not shown). The application layer 105 may further process the processed version 212 of the encapsulated video signal (e.g. for rendering, features recognizing, etc.). In general terms, the higher application layer 105, the remote entity 400, and the display are identified as “destinations”.

[0016] Fig. 1 shows an example of the environment in which the present technique operates. Reference numeral 200 indicates a vehicle environment (e.g., a car or another vehicle). The vehicle environment 200 includes a head unit 250. The head unit 250 may be part of a dashboard of the vehicle 200, or anyhow connected to it (e.g., fixedly mounted, e.g. integrally part of it). The head unit 250 be or include a hardware component onto which software components operate, and therefore includes processing units (e.g. CPUs, GPUs, processors, microcontrollers, FPGAs, etc.).

[0017] The head unit 250 may include an automotive operating system (AOS) media system 100 and an application layer 105 with a media communication application 260 operating on the AOS media system 100. The applications of the application layer 105. The AOS media system 100 may be implemented in software and hardware. The AOS media system 100 may provide specific services (e.g. media and / or communication applications, such as video call applications see also below) to the applications 260. The AOS media system 100 may operate according to an AOS. The AOS may provide specific services (e.g. APIs) to particular higher-layer applications (e.g. 260). An example of the AOS may be Android Automotive Operating System (AAOS). Other examples include a Linux-based system and QNX (QNX).

[0018] The AOS media system 100 may include, as a software element, a standardized camera input APIs block 502. The standardized camera input APIs block 502 may provide a video signal 212 according to a pre-defined format, specified by the AOS. Application program interfaces (APIs) through which the camera input APIs block 502 operates are in principle standardized and not modifiable if not with a new release or a reinstallation of the AOS (or at the price of a deviation from the standard). The standardized camera input APIs block 502has been conceived to be inputted with one video signal provided by a camera. Accordingly, the standardized camera input APIs block 502 is meant to be inputted with a video signal formatted according to a straightforward format without too many possibilities for customization or formatting or adaptation. It will be seen later that the input of the standardized camera input APIs block 502 will be an encapsulated video signal 112, and the output 212 of the standardized camera input APIs block 502 (here indicated as processed version of the encapsulated video signal 112) will be a version that can be easily processed by the higher-layer media communication application 260. Fig. 1 shows that the processed version 212 of the encapsulated video signal 112 as outputted by the HAL 202 is provided to a the higher-layer media communication application 260, which in turn transmits it, to a remote provider 400 through a remote connection 401. The media communication application 260 may provide media content 262 (including, in some cases, the processed version 212 of the encapsulated video signal 112) to a remote provider 400 and / or another video destination (for example, another video destination could be a display, not shown in Fig. 1 , which could be in addition or as an alternative to the provision of the media content 262 212 to the remote provider 400). Fig. 1 shows that media content 262 (including audio content 262’ and / or video content 262”) may be provided to a standardized user interface (III) 263” and / or to aa standardized audio output unit 263’, which is in turn provided to a audio HAL block 265’.

[0019] The remote provider 400 may be in cloud. The remote connection 401 may be performed through a remote communication network (like LTE, 5G and so on).

[0020] It is now explained how the encapsulated video signal 112, inputted to the HAL 202, is obtained. In an internal space (e.g., cockpit e.g. vehicle cockpit) 210 there may be a plurality of devices (e.g. mobile devices). The plurality of devices may be or at least include video acquiring devices (e.g. camera devices), but in some examples at least one of the plurality of devices may be or include at least one device (e.g. multiple devices) which provides an image or a video even if it has not been acquired by it (e.g., even if it has no camera). Fig. 1 shows only a first device (first mobile device) 300a and a second device (second mobile device) 300b, but the example is generalizable to any plurality of devices (e.g. including at least one or more mobile devices). Examples of mobile devices are user equipments (UEs), mobile phones, tablets, personal computers, and other mobile devices. The devices (e.g. mobile devices) may be connected, for example, to the head unit 250 (and more in particular to the media communication controller 102) a local communication network (e.g. WLAN, Wi-Fi, Bluetooth, ZigBee). One or more (e.g. more than one, e.g. all) of the devices 300a, 300b of the plurality of devices may actually be a non-mobile device. One or more (e.g. all) of the mobile devices 300a, 300b of the plurality of devices may be a DASHcam or a physically connected camera 562 (locally connected, e.g. through wired connection). The camera 562 may output its video signal 302c to a camera HAL 564, which sends the video signal 302c (in its version 566) to the standardized APIs block 502 for sending the video signal 566 to the higher layer application 260. In some cases, however, the video signal 566 (in its standardized version 568) may be provided to the e video signal encapsulation unit 110. At least one (e.g. more than one, e.g. all) of the devices 300a, 300b of the plurality of devices may be connected through a wireless connection (e.g. WLAN, WiFi, Bluetooth, ZigBee), while it is possible that at least one of the devices of the plurality of devices is connected through a wired communication (e.g. electric or optical communication).

[0021] As shown in Fig. 1 , the AOS media system 250 may include a media communication controller 102 as a part of the virtual camera emulator 500 (the virtual camera emulator 500 may also include a media communication control user interface 102v, e.g. for interacting with the user, e.g. so that the user commands the video encapsulation). In some examples, the media communication controller 102 may also perform further tasks (e.g. to send video signals towards the plurality of device). The AOS media system 250 may be configured to receive the video input signals from the plurality of devices 300a, 300b, 300c. For example, the media communication controller 102 (and in particular the video signal encapsulation unit 110) may receive a first video input signal 302a from the first device 300a, the second video input signal 302b from the second mobile device 300b or from the locally connected camera 562, and so on. In examples, the media communication controller 102 does not need to be part of the ASO media system 250. The media communication controller 102 (and in particular the video signal encapsulation unit 110) may be an internal to the AOS head unit 100.

[0022] The video signal encapsulation unit 110 (or more in general the media communication controller 102) may receive the first video input signal 302a and the second video input signal 302b or 568 (302c). In examples the video signal encapsulation unit 110 (or more in general the media communication controller 102) may decode (e.g. decompress) both of the video inputs 302a, 302b, 568 (or at least one of them). In examples the video signal encapsulation unit 110 (or more in general the media communication controller 102) may decrypt both of the video inputs 302a, 302b, 566 (or at least one of them). The video signal encapsulation unit 110 (or more in general the media communication controller 102) may encapsulate the first video signal 302a and at least the second video input signal 302b, 566 into one single encapsulated video signal 112. The video signal encapsulation unit 110 may provide the encapsulated video signal 112 in the pre-defined, standardized format that is processable by the camera input APIs block 202. The camera input APIs block 202 is natively configured to only receive one single video signal. Notwithstanding, in this way, the camera input APIs block 202 receives one single encapsulated video (112) which notwithstanding contains video content acquired by different devices (300a, 300b, 562, and so on). For this reason, the APIs of the camera input APIs block 202 need not to be modified, and the AOS media system 100 may continue operating according to AOS in full compliance with the specification of the operating system. Subsequently, the application 260 may receive the video content 212 without being aware of the fact that it comes from different video sources. Notably, the encapsulated video signal may be recompressed, so as to be in encoded form.

[0023] The media communication controller 102 may include a media communication interface 104 which receives (e.g. simultaneously) both the first video input signal 302a and second video input signal 302b (and possibly other video signals) from the plurality of mobile devices (as explained above, it is possible to have more than two video input signals at a time). The media communication interface 104 may provide the plurality of video input signals (including at least one of the first and second input signals 302a, 302b) to the video signal encapsulation unit 110. In some examples, at least one of the first and second input signals (or more in general of the plurality of video input signals) may be received from the physically connected camera 562. The video signal encapsulation unit 110 (or more in general the media communication controller 102) may provide the encapsulated video signal 112 (as signal 501) to a camera HAL block 104. The camera HAL block 104 may provide the encapsulated video signal 112 to the standardized camera input APIs block (502).

[0024] Fig. 1 also shows media content 262 (which may be voice content or other kinds of streams) from the remote provider 400. This media content 262 may reach the media communication controller 102 and the media communication controller 102 may provide it (as indicated in Fig. 1 as 268’ or 268”, respectively received from 263’ and 263”). Basically, the media communication controller 102 of Figs. 1 and 2 may perform a voice communication with the provision of multiple videos (encapsulated in one single video).

[0025] The encapsulated video signal 112 may be obtained different ways:

[0026] • The encapsulated video signal 112 may be generated by side-by-side juxtaposing the plurality of video signals, e.g. by side-by-side juxtaposing the first video signal 302a (e.g. images of the first video input signal 302a) with the second video signal 302b (e.g. images of the second video input signal 302b), thereby generating side-by-side juxtaposed images constituting the encapsulated video signal 112. By side-by-side juxtaposing the plurality of video input signals 302a and 302b and / or 568 encapsulated, they may be (e.g. spatially skewed from each other) in reduced resolution and / or in reduced size in the encapsulated video signal 112. One or more blank portions (not displaying any valuable image) can also be provided, thereby reducing the required band for the transmission to the remote entity 400. In this case, the time length of the encapsulated video signal 112 may be the same of the time lengths of the plurality of video input signals 302a and 302b encapsulated. o In some examples, the plurality of video input signals 302a and 302b as received by the media communication controller 102 may be associated with time stamps (e.g., as metadata accompanying the plurality of received video input signals 302a and 302b, or as generated by the media communication controller 102 itself when receiving the video input signals 302a and 302b). Hence, the media communication controller 102 may retrieve a succession of first time stamps for the first video input signal 302a and a succession of second time stamps for the second video input signal 302b, and perform the side-by-side juxtaposing process based on the successions of first and second first time stamps. o For example, if the knowledge of time is shared between the first and second devices 300a and 300b (e.g. through a distributed synchronization algorithm), then the video signal encapsulation unit 110 knows which image of the first video input signal 302a to juxtapose side-by-side with which image of the second video input signal 302b. o In other examples (e.g. in the case in which there is not a distributed synchronization algorithm, e.g. where the time stamps are progressive numbers associated to the packets of the video input signals 302a and 302b and are incoherent with each other), the media communication controller 102 may determine the first images of the both video input signals 302a and 302b which are supposed to be synchronous, and juxtapose side-by- side the subsequent images of the video input signals 302a and 302b by maintaining a constant progression. For example, in the case that the first image (in time order) of the first video input signal 302a has time stamp TS1 and the first image (in time order) of the second video input signal 302b has time stamp TS2 (therefore causing an offset OFS=TS1-TS2), then the video signal encapsulation unit 110 will subsequently juxtapose side-by-side those images having the same offset OFS=TS1-TS2. o Notably, in case the different videos have different frame rates, it is possible to perform frame rate conversion (e.g. by discarding some frames of the video signal having higher frame). The time stamps may be used for synchronizing the input video signal.

[0027] • In addition or alternatively, the encapsulated video signal 112 may be generated by stacking the sequence of images of the first video input signal 302a with the sequence of images of the second video input signal 302b, thereby increasing the time length of the entire video (e.g., if the first video 302a has time length T 1 and the second video 302b has time length T2, the length of the encapsulated video signal 112 will be T1+T2). The video signal encapsulating unit 110 may decide which video to stack first for example based of the time stamp of the first image (in time order) of the first video input signal 302a has time stamp TS1 and the first image (in time order) of the second video input signal 302b.

[0028] In examples, the media communication controller 102 unit may request a particular resolution and / or quality to the plurality of devices 300a, 300b. For example, in the case that only one single device 300a sends the video signal 300a, a high resolution and / or quality may be required. However, in the case that more than one devices starts sending the video signal (e.g., whether there is two devices 300a and 300b), then the media communication controller 102 unit may request a reduced resolution and / or quality of the video signals 302a and 302b (in particular in the case of side-by-side juxtaposition). In general terms, the more video signals are to be side-by-side juxtaposed, the more reduced (worse) the resolution and / or the quality required.

[0029] There is also disclosed a method for supporting the processing of multiple video input signals (302a, 302b)for an application (260) operating according to an automotive operation system, AOS. The method includes installing a video signal encapsulation unit (1 10) to encapsulate two video signals (302a, 302b) into one single encapsulated video signal (1 12), and a camera HAL block (202) for providing the single encapsulated video signal (1 12) according to a standardized, pre-defined format.

[0030] There is also disclosed a media communication method for a vehicle environment (200), the method using an automotive operation system, AOS, media system (100) operating according to an AOS including an application programming interfaces, APIs, block requiring, in input, one video signal in a pre-defined format, the method comprising: receiving: a first video input signal (302a); and, simultaneously, a second video input signal (302b); encapsulating the first video input signal (302a) and the second video input signal (302b) into one single, encapsulated video signal (112); transmitting to an hardware abstract layer, HAL (202), the encapsulated video signal (112), so as to convert the single, encapsulated video signal (112), onto the predefined format.

[0031] Discussion

[0032] Remote Device Cameras in a car

[0033] Android Automotive Operating System (AAOS) is available for the head-units of cars:

[0034] AAOS (but more in general other AOSs) also contains camera HALs (HAL=Hardware Abstraction Layer) e.g. 202, which is an abstraction to integrate cameras to be recognizable by Android (or by another AOS):

[0035] In examples, one or more mobile devices (phone, tablet, etc.) are used to capture the mobile device camera streams, and to connect such devices via a remote connection with the head-unit (client / server). Then, the mobile devices will send the camera streams to a software component running on the AAOS (or more in general AOS) head unit. This component will then combine the received camera streams into a side-by-side or stacked view and create one single resulting video stream. This video stream is fed to a AAOS (or more in general AOS) camera HAL, such that the HAL offers the resulting video stream in a way that emulates a standard camera.

[0036] Hence, any application running on AAOS (or more in general AOS) can access this emulated camera and does not require adaptations for this.

[0037] Use cases are for example as following:

[0038] When a videocall is started on the head-unit, passengers are invited to use their phone or tablets to participate. The video caller outside the car will be able to see all passengers inside the car.

[0039] The driver introduces a dashcam video stream into the video call.

[0040] Instead of their device cameras, passengers share their screen into the video call. In an example, one can enable video calls with multiple participants and showing them side by side. In an example, this use case is enabled through AAOS (or more in general AOS) HALs to enable any video call application to use a remote camera, in a way that the application is not even aware of it.

[0041] It is to be mentioned here that all alternatives or aspects as discussed before and all aspects as defined by independent claims in the following claims can be used individually, i.e., without any other alternative or object than the contemplated alternative, object or independent claim. However, in other examples, two or more of the alternatives or the aspects or the independent claims can be combined with each other and, in other examples, all aspects, or alternatives and all independent claims can be combined to each other.

[0042] Although some aspects have been described in the context of an apparatus, it is clear that these aspects also represent a description of the corresponding method, where a block or device corresponds to a method step or a feature of a method step. Analogously, aspects described in the context of a method step also represent a description of a corresponding block or item or feature of a corresponding apparatus.

[0043] Depending on certain implementation requirements, examples can be implemented in hardware or in software. The implementation can be performed using a digital storage medium, for example a floppy disk, a DVD, a CD, a ROM, a PROM, an EPROM, an EEPROM or a FLASH memory, having electronically readable control signals stored thereon, which cooperate (or are capable of cooperating) with a programmable computer system such that the respective method is performed.

[0044] Some examples comprise a data carrier having electronically readable control signals, which are capable of cooperating with a programmable computer system, such that one of the methods described herein is performed.

[0045] Generally, examples can be implemented as a computer program product with a program code, the program code being operative for performing one of the methods when the computer program product runs on a computer. The program code may for example be stored on a machine readable carrier.

[0046] Other examples comprise the computer program for performing one of the methods described herein, stored on a machine readable carrier or a non-transitory storage medium.

[0047] In other words, an example of the inventive method is, therefore, a computer program having a program code for performing one of the methods described herein, when the computer program runs on a computer.

[0048] A further example of the inventive methods is, therefore, a data carrier (or a digital storage medium, or a computer-readable medium) comprising, recorded thereon, the computer program for performing one of the methods described herein. A further example of the inventive method is, therefore, a data stream or a sequence of signals representing the computer program for performing one of the methods described herein. The data stream or the sequence of signals may for example be configured to be transferred via a data communication connection, for example via the Internet.

[0049] A further example comprises a processing means, for example a computer, or a programmable logic device, configured to or adapted to perform one of the methods described herein.

[0050] A further example comprises a computer having installed thereon the computer program for performing one of the methods described herein.

[0051] In some examples, a programmable logic device (for example a field programmable gate array) may be used to perform some or all of the functionalities of the methods described herein. In some examples, a field programmable gate array may cooperate with a microprocessor in order to perform one of the methods described herein. Generally, the methods are preferably performed by any hardware apparatus.

[0052] The above described examples are merely illustrative for the principles of the present technique. It is understood that modifications and variations of the arrangements and the details described herein will be apparent to others skilled in the art. It is the intent, therefore, to be limited only by the scope of the impending patent claims and not by the specific details presented by way of description and explanation of the examples herein.

[0053] Some general aspects are:

[0054] 1. Mobile device (e.g. 300a, 300b) or method of operating a mobile device as described above.

[0055] 2. Head unit or method of operating a head unit as described above.

[0056] 3. Cloud service or method of operating a cloud service as described above.

[0057] 4. Communication method as described above.

[0058] 5. Computer program configured for performing any one of the methods in aspect 1 - 3 when running on a computer or a processor.

Claims

Claims1. A virtual camera emulator (500) for an automotive operation system, AOS, media system (100) which operates according to a standardized AOS, the AOS including an AOS standard camera input APIs block (502) requiring, in input, a video signal of a predefined AOS format, the virtual camera emulator being configured to receive a plurality of video input signals, the plurality of video input signals including: a first video input signal (302a); and, simultaneously, at least a second video input signal (302b); a video signal encapsulation unit (110), configured to encapsulate the plurality of video input signals into one single, encapsulated video signal (112); and a camera hardware abstraction layer, HAL block (202), to transmit the encapsulated video signal (112) to the camera input APIs block (502).

2. The virtual camera emulator (500) of any of the preceding claims, configured to provide the encapsulated video signal (112) as one single video signal.

3. The virtual camera emulator (500) of any of the preceding claims, configured to receive at least one of the first video input signal (302a) and the second video input signal (302b) as a live camera video.

4. The virtual camera emulator (500) of claim 3, configured to receive at least one of the first video input signal (302a) and the second video input signal (302b) from a mobile device (300a, 300b) through a local connection.

5. The virtual camera emulator (500) of any of the preceding claims, wherein the video signal encapsulation unit (110) is configured to generate the encapsulated video signal (112) by side-by-side juxtaposing versions of images of the first video input signal (302a) with versions of images of at least the second video input signal (302b), thereby generating side-by-side juxtaposed images constituting at least one portion of the encapsulated video signal (112).

6. The virtual camera emulator (500) of any of the preceding claims, wherein the video signal encapsulation unit (110) is configured, in case the plurality of video signals have different frame rates, to perform a frame rate conversion of at least one of the first video input signal (302a) and the second video input signal (302b).

7. The virtual camera emulator (500) of any of claims 5-6, wherein the video signal encapsulation unit (110) is configured to retrieve a first succession of time stamps for the first video input signal (302a) and a second succession of time stamps for at least the second video input signal (302b), wherein the video signal encapsulation unit (110) is configured to select the versions of the images of the first video input signal (302a) and the versions of the images of at least the second video input signal (302b) based on the first time stamps and the second time stamps.

8. The virtual camera emulator (500) of any of the preceding claims, wherein the video signal encapsulation unit (110) is configured to generate the encapsulated video signal (112) by stacking one of the first video input signal (302a) and the second video input signal (302b) one behind the other.

9. The virtual camera emulator (500) of any of the preceding claims, configured to receive the first video input signal (302a) from a first external device (300a) through a first communication session and the second video input signal (302b) from a second external device (300b) through a second communication session.

10. The virtual camera emulator (500) of claim 9, configured to receive the first video input signal (302a) from the first external device (300a) through the first communication session of a local wireless connection, and the second video input signal (302b) from the second external device (300b) through the second communication session of the local wireless connection.

11. The virtual camera emulator (500) of any of the preceding claims, configured to receive at least one of the first video input signal (302a) and at least the second video input signal (302b) from a physically connected camera (562).

12. The virtual camera emulator (500) of any of the preceding claims, configured to request or control a display of the encapsulated video signal (112), to a display controller, so that the encapsulated video signal (112) is displayed on a display.

13. The virtual camera emulator (500) of any of the preceding claims, configured to receive a media content (262) and to provide the media content (264a, 264b) to at least oneor more among the first external device (300a) and the second external device (300b) and another media rendering media device.

14. The virtual camera emulator (500) of any of the preceding claims, configured to perform a voice communication session with transmission of voice content in downlink and / or in uplink and transmission of the single, encapsulated video signal in uplink, wherein the media communication interface is configured to provide, to at least one of the first and second mobile devices or to a loudspeaker, voice content in downlink from the remote provider.

15. The virtual camera emulator (500) of any of the preceding claims, wherein the video signal encapsulation unit (110) is configured to decompress at least one of the first video input signal (302a) and the second video input signal (302b) before encapsulating, and, after encapsulating, compressing the encapsulated video signal (112) according to the pre-defined AOS format.

16. The virtual camera emulator (500) of any of claims 1-14, wherein the video signal encapsulation unit (110) is configured to decompress at least one of the first video input signal (302a) and the second video input signal (302b) before encapsulating, and, after encapsulating, provide the encapsulated video signal (112) uncompressed.

17. The virtual camera emulator (500) of any of the preceding claims, wherein the video signal encapsulation unit (110) is configured do downsample the plurality of video input signals.

18. The virtual camera emulator (500) of any of the preceding claims, wherein the video signal encapsulation unit (110) is configured to decrypt at least one of the first video input signal (302a) and the second video input signal (302b) before encapsulating.

19. The virtual camera emulator (500) of any of the preceding claims, configured to request a particular quality and / or resolution to each of the first and second external devices (300a, 300b), in such a way that the more input vides signals are received, the worse the quality and / or resolution.

20. The virtual camera emulator (500) of any of the preceding claims, wherein the AOS is Android AOS, AAOS.

21. An automotive operating system, AOS, media system (100), comprising the virtual camera emulator (500) of any of the preceding claims and the APIs block (502) to provide a standardized version (212) of the encapsulated video signal (112) to a higher-layer media communication application (260).

22. The AOS media system (100) of claim 21 , comprising a camera HAL (562) for receiving a local camera video signal (302c) from a local, physically connected camera (564).

23. The AOS media system (100) of any of claims 21-22, configured to provide the local camera video signal (302c) to the virtual camera emulator (500), to operate as any of the plurality of video input signals.

24. The AOS media system (100) of claim 23, configured to provide the local camera video signal (302c) to the virtual camera emulator (500) in a standardized version (502) through the APIs block (502).

25. The AOS media system (100) of any of claims 21-24, configured to request or control a transmission of the encapsulated video signal (212), downstream to the HAL (202), to a remote entity (400) through a remote connection (401).

36. A method for supporting the processing of multiple video input signals (302a, 302b)for an application (260) operating according to an automotive operation system, AOS, the method including: installing a video signal encapsulation unit (110) to encapsulate two video signals (302a, 302b) into one single encapsulated video signal (112), and a camera HAL block (202) for providing the single encapsulated video signal (112) according to a standardized, pre-defined format.

37. A media communication method for a vehicle environment (200), the method using an automotive operation system, AOS, media system (100) operating according to an AOS including an application programming interfaces, APIs, block requiring, in input, one video signal in a pre-defined format, the method comprising: receiving: a first video input signal (302a); and, simultaneously, a second video input signal (302b);encapsulating the first video input signal (302a) and the second video input signal (302b) into one single, encapsulated video signal (112); transmitting to an hardware abstract layer, HAL (202), the encapsulated video signal (112), so as to convert the single, encapsulated video signal (112), onto the pre-defined format.

38. A non-transitory storing unit storing code which, when executed by a processor, causes the processor to perform a method according to claim 36 or 37.

Images