131 that can receive user tactile/touch input. As a touch screen device, integrated display 130 allows a user to provide input to or to control electronic device 100 by touching features within the user interface presented on display 130. Tactile, touch screen interface 131 can be utilized as an input device. The touch screen interface 131 can include one or more virtual buttons, indicated generally as 115. In one or more embodiments, when a user applies a finger on the touch screen interface 131 in the region demarked by the virtual button 115, the touch of the region causes the processor 102 to execute code to implement a function associated with the virtual button. In some implementations, integrated display 130 is integrated into a front surface of electronic device 100 along with front ICDs, while the higher quality ICDs are located on a rear surface. In other embodiments, multiple of integrated display 130 are provided, including both a front and a rear display, for example,

Electronic device 100 further includes haptic touch controls 145, vibration device 146, fingerprint/biometric sensor 147, global positioning system (GPS) module 160, and motion sensor(s) 162. Vibration device 146 can cause electronic device 100 to vibrate or shake when activated. Vibration device 146 can be activated during an incoming call or message in order to provide an alert or notification to a user of electronic device 100. According to one aspect of the disclosure, integrated display 130, speakers 144, and vibration device 146 can generally and collectively be referred to as output devices.

Biometric sensor 147 can be used to read/receive biometric data, such as fingerprints, to identify or authenticate a user. In some embodiments, the biometric sensor 147 can supplement an ICD (camera) for user detection/identification.

GPS module 160 can provide time data and location data about the physical location of electronic device 100 using geospatial input received from GPS satellites. Motion sensor(s) 162 can include one or more accelerometers 163 and gyroscope 164. Motion sensor(s) 162 can detect movement of electronic device 100 and provide motion data to processor 102 indicating the spatial orientation and movement of electronic device 100. Accelerometers 163 measure linear acceleration of movement of electronic device 100 in multiple axes (X, Y and Z). Gyroscope 164 measures rotation or angular rotational velocity of electronic device 100. Electronic device 100 further includes a housing 137 (generally represented by the thick exterior rectangle) that contains/protects the components internal to electronic device 100 and defines the front, back, and sides of electronic device.

Electronic device 100 also includes a physical interface 165. Physical interface 165 of electronic device 100 can serve as a data port and can be used as a power supply port that is coupled to charging circuitry 135 and device battery 143 to enable recharging of device battery 143 and/or powering of device.

Electronic device 100 further includes wireless communication subsystem (WCS) 142, which can represent one or more front end devices (not shown) that are each coupled to one or more antennas 148. In one or more embodiments, WCS 142 can include a communication module with one or more baseband processors or digital signal processors, one or more modems, and a radio frequency (RF) front end having one or more transmitters and one or more receivers. Example communication module 158 within system memory 120 enables electronic device 100 to communicate with wireless communication network 176 and with other devices, such as server 175 and other connected devices, via one or more of data, audio, text, and video communications. Communication module 158 can support various communication sessions by electronic device 100, such as audio communication sessions, video communication sessions, text communication sessions, exchange of data, and/or a combined audio/text/video/data communication session.

WCS 142 and antennas 148 allow electronic device 100 to communicate wirelessly with wireless communication network 176 via transmissions of communication signals to and from network communication devices, such as base stations or cellular nodes, of wireless communication network 176. Wireless communication network 176 further allows electronic device 100 to wirelessly communicate with server 175, and other communication devices, which can be similarly connected to wireless communication network 176. In one or more embodiments, various functions that are being performed on communications device 100 can be supported using or completed via/on server 175. In one or more embodiments, server 175 can store audio and/or video assets that can be streamed to the electronic device 100.

Electronic device 100 can also wirelessly communicate, via wireless interface(s) 178, with wireless communication network 176 via communication signals transmitted by short range communication device(s). Wireless interface(s) 178 can be a short-range wireless communication component providing Bluetooth, near field communication (NFC), and/or wireless fidelity (Wi-Fi) connections. In one or more embodiments, electronic device 100 can receive Internet or Wi-Fi based calls, text messages, multimedia messages, and other notifications via wireless interface(s) 178. In one or more embodiments, electronic device 100 can communicate wirelessly with external wireless device 166, such as a WiFi router or BT transceiver, via wireless interface(s) 178. In one or more embodiments, WCS 142 with antenna(s) 148 and wireless interface(s) 178 collectively provide wireless communication interface(s) of electronic device 100.

Electronic device 100 of FIG. 1 is only a specific example of a device that can be used to implement the embodiments of the present disclosure. Devices that utilize aspects of the disclosed embodiments can include, but are not limited to, a smartphone, a tablet computer, a laptop computer, a desktop computer, a television, a wearable computer, and/or other suitable electronic device.

FIG. 2 is an example illustration of an electronic device transmitting a request to an application server 280 to initiate playback of a media asset, according to one or more embodiments. Device 201 includes a display 230 on which a media asset 231 is rendered. Device 201 can be an implementation of electronic device 100, having similar components and/or functionality. In one or more embodiments, at least some of the dynamic media playback rate functions may be implemented on a network-accessible application server, such as indicated by application server 280. Application server 280 is communicatively coupled to Internet/WAN 254. In one or more embodiments, Internet/WAN 254 can include one or more wide area networks (WANs) and/or the Internet. In one or more embodiments, electronic device 201 can communicate wirelessly with wireless network 250 via transmissions of communication signals 294 to and from network communication devices, such as base stations or cellular nodes, that can include components of network 250. Network 250 enables exchange of data between electronic device 201 and application server 280, via Internet/WAN 254.

Application server 280 can host AV media hosting application 282. The AV media hosting application 282 can support streaming and/or download of media assets to electronic device 201. In one or more embodiments, the application server 280 and/or the AV media hosting application 282 can provide the functionality of storing user preferences in online account 286, including preferences for a preferred playback speed, based on criteria such as genre, subject matter, speech rate, media source, and/or other criteria. The application server 280 and electronic device 201 may communicate with each other via Internet/WAN 254. In one or more embodiments, the application server 280 and electronic device 201 may communicate using one or more protocols, including, but not limited to, HTTP Live Streaming (HLS), and/or Dynamic Adaptive Streaming over HTTP (MPEG-DASH). These formats support adaptive bitrate streaming, which adjusts the quality of the video stream in real-time based on network conditions. Additionally, protocols such as RTSP (Real-Time Streaming Protocol) may be used for controlling various aspects of media playback. In one or more embodiments, the request 260 and response 262 may utilize Hypertext Transfer Protocol (HTTP) and/or its secure counterpart HTTPS. Embodiments may use RESTful APIs, JavaScript Object Notation (JSON), Simple Object Access Protocol (SOAP), and/or other communication techniques for exchanging information.

In one or more embodiments, in order to support scalability and/or case of maintenance, application server 280 may be implemented via virtualization, such as utilizing hypervisors like VMware, Hyper-V, or KVM. One or more embodiments may include containerization services such as docker, LXC, or other suitable container framework to enable multiple isolated user-space instances. Additionally, one or more embodiments may include load balancing and/or orchestration, such as utilizing Kubernetes, or other suitable orchestration framework.

FIG. 3 depicts a user interface 300 for establishing video playback preferences, according to one or more embodiments. In one or more embodiments, the user interface shown in FIG. 3 may be rendered on a display 302 of a device such as device 100 of FIG. 1. In one or more embodiments, the user interface can be associated with (e.g., generated by) media player 154 on device 100. In one or more embodiments, the user interface can be generated at application server 280 and presented during user setup of playback features within online account 286. The user interface 300 includes a media source field 304, where a name of a given media source, along with a corresponding preferred playback rate can be specified. In the case of video streaming from a platform, the source provider can be indicated as a channel name, uniform resource locator (URL), and/or other designation. To further illustrate the specification of playback speed preferences, referring to additional details within media source field 304, a channel ‘Fun2doMath’ is specified at 351, and has a preferred playback speed of 1.0× as indicated at 352, indicating that content played from the Fun2doMath channel (media source) is to be played at its default (normal) playback speed. Similarly, a channel ‘ChemLessons’ is specified at 353, and has a preferred playback speed of 0.75× as indicated at 354, indicating that content played from the ChemLessons channel (media source) is to be played at a speed of 75 percent of the default (normal) playback speed. That is, playback of media assets from the ChemLessons channel are to be played back at a rate that is slower than the default playback speed. Similarly, a channel ‘PhysicsLessons’ is specified at 355, and has a preferred playback speed of 1.25× as indicated at 356, indicating that content played from the PhysicsLessons channel (media source) is to be played at a speed of 125 percent of the default (normal) playback speed. That is, playback of media assets from the PhysicsLessons channel are to be played back at a rate that is faster than the default playback speed.

The aforementioned examples are well-suited for consumption of educational content. In a scenario where a user is strong in the subject of physics, but less so in the subject of chemistry, the user can opt to play physics material at a faster than normal playback rate, to enable consuming the content more quickly. For example, a 40-minute physics video lesson can be consumed in 32 minutes at a rate of 1.25× (e.g., as indicated at 356) thereby saving time for a user in a case where the user can comprehend the subject material at the accelerated rate. Conversely, for a subject that is more challenging for a user (chemistry, in this example), the playback rate can be set slower than normal (e.g., as indicated at 354). Other topics (math, in this example), can be played at a default playback rate (e.g., as indicated at 352). Embodiments can include determining a topic for the media asset by retrieving metadata from the media asset (e.g., a source of the media asset); and computing the recommended playback rate, based at least in part on the determined topic. In one or more embodiments, where the metadata may not overtly indicate the topic, AI engine 105 (FIG. 1) can perform analysis of the speech produced by reply of the content to identify specific words and terminology that can be correlated to a specific topic utilizing a database of historical data or other user preferences data. Disclosed embodiments can automatically adjust the playback speed based on the media source, subject matter, and/or other criteria, creating a more enjoyable and fulfilling content consumption experience for a user.

A similar concept can be applied to a genre of content, as indicated in media genre field 314. Embodiments can include determining a genre for the media asset by retrieving metadata from the media asset; and computing the recommended playback rate, based at least in part on the determined genre. As an example, a genre of ‘News’ as indicated at 363 has a preferred playback speed of 1.2×, as indicated at 364. Similarly, a genre of ‘Documentaries’ as indicated at 365 has a preferred playback speed of 0.75×, as indicated at 366. One or more embodiments may further include a closed-caption option selection field 316 for an automatic activation of closed-caption for particular playback rates. In one or more embodiments, the option for automatic closed-caption may be activated via a radio button 322. When the radio button is set to on (as illustrated in FIG. 3), closed-captioning may be automatically activated when a playback speed of less than the default (i.e., normal speed) is automatically set, based on the user preferences. Accordingly, even if the closed-caption is disabled on the device, in cases where a computed recommended playback rate is less than a default rate, the closed-captions are automatically activated during the playback of the media asset at the reduced rate. On playback of a subsequent media asset at a normal or faster rate, the closed-captions may then be automatically disabled again.

Once the media playback options are configured as desired, the Save button 306 can be invoked by a user. In one or more embodiments, in response to the invoking of the Save button 306, the preferences can be saved to onboard memory of the electronic device (e.g., 120 of FIG. 1), and/or saved remotely on an application server (e.g., 280 of FIG. 2). The user interface 300 can further include a cancel button 308, that when invoked, closes the user interface 300 without saving any changes.

FIG. 4 depicts an additional user interface 400 for establishing video playback preferences, according to one or more embodiments. In one or more embodiments, the user interface shown in FIG. 4 may be rendered on a display 402 of a device such as device 100 of FIG. 1. The user interface 400 includes an accent field 404, where a detected speaker accent, along with a corresponding preferred playback rate can be specified. In one or more embodiments, the automatic identification of a speaker accent may be implemented using machine learning techniques as part of an automatic speech recognition (ASR) and speaker identification process, which involves analyzing audio signals to extract various features to identify the speaker's accent. The process can include feature extraction, in which a machine learning (ML) model analyzes acoustic features of speech, such as pitch, tone, rhythm, and intonation, which vary across different accents. The machine learning models used to implement features of disclosed embodiments may execute on artificial intelligence (AI) engines 105 of FIG. 1. Additionally, a phonetic analysis may be performed to identify differences in pronunciation of phonemes for further distinguishing between accents. The ML models may be tried using supervised learning and/or multi-class classification techniques. Embodiments may further perform speaker diarization (i.e., partitioning into homogeneous segments based on each of multiple speakers). For scenarios where multiple speakers are present, disclosed embodiments may separate the speech segments of each speaker before identifying their respective accents. Embodiments can include determining an accent of the speaker; comparing the determined accent of the speaker to an accent list in a user profile, each accent having an associated specified rate relative to a normal playback rate; and in response to the determined accent being included in the accent list, adjusting the recommended playback rate based on the associated specified rate for the determined accent.

The user interface 400 includes a speaker identity field 414, where a detected speaker, along with a corresponding preferred playback rate can be specified. Embodiments can include identifying a person in the video file, and adjusting the recommended playback rate based on the identified person. One or more embodiments can perform speaker identification and set a playback rate for media in response to detecting that a user preference exists for a given speaker. One or more embodiments may utilize machine learning (ML) models to analyze specific characteristics of a person's voice, such as pitch, timbre, cadence, and pronunciation. These features are unique to each individual. One or more embodiments may further analyze Mel-Frequency Cepstral Coefficients (MFCCs). MFCCs represent the short-term power spectrum of a sound and are effective in capturing the unique aspects of a speaker's voice. The user interface 400 further includes a save button 406 and a cancel button 408 that operate similar to as described in FIG. 3. In one or more embodiments, when multiple parameters indicate different playback speeds, the lowest indicated playback speed is used. As an example, if the genre of a media asset is associated with a playback speed of 0.9×, and the detected accent of the speaker in the media asset is associated with a playback speed of 0.8×, then the lowest playback speed of 0.8× is used.

FIG. 5 depicts a user interface 500 indicating accelerated media playback based on the identified speaker and/or type of media content, according to one or more embodiments. In one or more embodiments, the user interface shown in FIG. 5 may be rendered on a display 502 of a device such as device 100 of FIG. 1. The user interface 500 includes a video window 504, which renders video, including video of a speaker 506. The speaker 506 can be providing instruction, narration, and/or other types of verbally-presented information. Based on user preferences, such as those specified in FIG. 3 and/or FIG. 4, a playback rate may be automatically adjusted, as indicated at 508. In one or more embodiments, the default (normal) rate may be the playback rate at which the content was created or recorded. The feature of automatically speeding up the playback rate under certain conditions is useful for speakers that tend to speak slowly, and/or have lengthy pauses in between words and/or sentences, thus generating a bursty pattern of speech. Accordingly, one or more embodiments can include determining a burstiness level of the speech, based on identifying an average duration of silence between one or more words spoken by the speaker; and in response to the burstiness level exceeding a predetermined threshold, increasing the recommended playback rate. As shown at 508, in this example, the playback rate is increased to 1.2×, thus playing back the video at a faster rate than the default (normal) rate.

FIG. 6 depicts a user interface 600 indicating reduced speed media playback based on the identified speaker and/or type of media content, according to one or more embodiments. In one or more embodiments, the user interface shown in FIG. 6 may be rendered on a display 602 of a device such as device 100 of FIG. 1. The user interface 600 includes a video window 604, which renders video, including video of a speaker 606. The speaker 606 can be providing instruction, narration, and/or other types of information. Based on user preferences, such as those specified in FIG. 3 and/or FIG. 4, a playback rate may be automatically adjusted, as indicated at 608. As shown at 608, in this example, the playback rate is reduced to 0.8×, thus playing back at a slower rate than the default (normal) rate. The feature of automatically reducing the playback rate under certain conditions is useful for speakers that tend to speak quickly, speak with an accent that the user has difficulty understanding, and/or are speaking about a complex or hard-to-understand topic.

FIG. 7 depicts a user interface 700 illustrating selectively setting an operating playback rate of the media player to the lowest recommended playback speed for playback involving multiple speakers, according to one or more embodiments. In one or more embodiments, the user interface shown in FIG. 7 may be rendered on a display 702 of a device such as device 100 of FIG. 1. The user interface 700 includes a video window 704, which renders video, including video of two speakers, indicated at 506, and 606. Referring again to FIG. 5, the example user preferences for speaker 506 are to accelerate the playback to 1.2× (as shown at 508 in FIG. 5). Referring again to FIG. 6, the example user preferences for speaker 606 are to reduce the playback to 0.8× (as shown at 608 in FIG. 6). However, in the scenario depicted in FIG. 7, both speaker 506 and speaker 606 are present in the video. As an example, the video can include a back-and-forth discussion between speaker 506 and speaker 606. In one or more embodiments, when multiple speakers are present, and the recommended playback rates for the multiple speakers differ, the lowest recommended playback speed is used for playback of the media asset, as indicated at 708. Embodiments can include analyzing the audio data of recorded speech of a second speaker to determine one or more speech parameters of the second speaker; computing a second recommended playback rate, based at least in part on the playback rate preferences and the one or more speech parameters of the second speaker; setting an operating playback rate of the media player to the lower of the recommended playback rate and the second recommended playback rate; and rendering the media asset at the operating playback rate, using the media player.

FIG. 8 depicts a user interface 800 illustrating automatic adjustment of the recommended playback speed from the example of FIG. 7, based on identifying a change in the people speaking in a video, according to one or more embodiments. In one or more embodiments, the user interface shown in FIG. 8 may be rendered on a display 802 of a device such as device 100 of FIG. 1. The user interface 800 includes a video window 804, which renders video, including video of two speakers, indicated at 506 and 606, along with another individual, indicated at 806 that is not currently speaking. In one or more embodiments, the playback rate can be adjusted based on the detection of presence of the newest arriving speaker, individual 806. One or more embodiments may utilize ML-based facial recognition and facial identification to determine the identity of the individual, and adjust a playback rate based on the presence of the individual, even if the individual has not spoken. These embodiments enable a playback speed to be preset, based on the presence of a specific individual whose identity is known. In this way, if or when the individual does speak, the playback speed is already set to the user-preferred playback rate. In the example shown in FIG. 8, the individual 806 has an associated playback rate of 0.7× established. Accordingly, as indicated at 808, the playback rate of the video is set to 0.7×, which is the lowest recommended playback speed, compared with the playback speeds corresponding to speaker 506 and speaker 606. Embodiments can include identifying a person in a video file within the media asset and adjusting the playback rate based on the identified person.

FIG. 9 depicts a user interface 900 illustrating automatic activation of closed caption based on a recommended playback rate for the media content being presented, according to one or more embodiments. In one or more embodiments, the user interface shown in FIG. 9 may be rendered on a display 902 of a device such as device 100 of FIG. 1. The user interface 900 includes a video window 904, which includes speaker 606. Continuing from the example shown in FIG. 6, the playback speed is set to 0.8×, as indicated at 608 of FIG. 6. In the example shown in FIG. 9, the automatic closed-caption activation option is enabled (refer to 316 of FIG. 3). Accordingly, captions 942 are automatically rendered for the media asset. In one or more embodiments, the captions can be included in metadata for the asset, such as a subtitle track. In one or more embodiments, the captions can be decoded on-the-fly using real-time speech recognition. One or more embodiments may utilize a search algorithm such as the Viterbi algorithm to find the most likely sequence of words given the acoustic signals and language model probabilities. Additionally, disclosed embodiments may utilize incremental transcription techniques, which continuously updates and refines the transcription as more audio data becomes available. The incremental transcription techniques can enable improved disambiguation processing. Disambiguation in Automatic Speech Recognition (ASR) is crucial because it directly affects the accuracy and reliability of transcriptions. Ambiguity arises in speech recognition due to homophones, context variations, accents, background noise, and other factors. Disambiguation ensures that the recognized text correctly represents the intended meaning of the spoken words. For example, homophones (words that sound the same, but have different meanings) can be distinguished through context analysis (e.g., “their” versus “there,” “I” versus “eye,” etc.).

Automatically activating captions on videos on which the user prefers reduced playback speed offers numerous benefits for aiding comprehension, making content more accessible and enhancing the viewing experience for the user. Thus, the disclosed embodiments can assist with understanding speech of a person whose audible speech can be difficult to comprehend or whose speech covers complex terminology that the listener may not be familiar with or able to grasp from listening to the slowed audio. Additionally, disclosed embodiments can assist non-native speakers to understand content better by enabling the user to read along with the audio for media assets that they may have difficulty comprehending. Moreover, exposure to written words can help in learning new vocabulary and improving language proficiency, thereby improving overall understanding.

Referring now to the flowcharts presented by FIG. 10 and FIG. 11, the descriptions of the methods shown by FIG. 10 and FIG. 11 are provided with general reference to the specific components and features illustrated within the preceding FIGS. 1-9. Specific components referenced in the methods of FIG. 10 and FIG. 11 may be identical or similar to components of the same name used in describing preceding FIGS. 1-9. In one or more embodiments, processor 102 (FIG. 1) configures electronic device 100 (FIG. 1) to provide the described functionality of the methods of FIG. 10 and FIG. 11 by executing program code for one or more modules or applications provided within system memory 120 of electronic device 100, including SA module 152 and media player 154, utilizing user preferences data from preferences database 157 (FIG.