Before you continue
Before submitting a bug report, please review our troubleshooting documentation at Redirect | /docs/vega/0.24/troubleshoot-overview.html
If you still want to file a bug report, please make sure to fill in all the details below and provide the necessary information.
NOTE: PLEASE ONLY REPORT A SINGLE BUG USING THIS TEMPLATE.
If you’re experiencing multiple issues, please file a separate report for each.
Bug Description
1. Summary
App Name: M327 PRO
App Link on Amazon Appstore: N/A — currently under development/testing on Vega Virtual Device.
Bug Severity:
-
Impacts operation of app
-
Blocks current development
-
Improvement suggestion
-
Issue with documentation
-
Other
We are seeing repeatable video micro-stutters when playing HLS content through MSE using MPEG-TS SourceBuffers on Amazon Vega.
The source MPEG-TS has continuous video frame timing, but Vega introduces repeated video TrackBuffer gaps equivalent to approximately 2–3 video frames.
During the visible stutters, the Vega media pipeline reports:
No Time update in Playing
At the same time:
media.currentTime stops advancing
totalVideoFrames continues increasing
droppedVideoFrames increases
This indicates that video frames continue to be produced while the media clock temporarily stops progressing.
2. Steps to Reproduce
-
Create and initialize a
VideoPlayerusing@amazon-devices/react-native-w3cmedia. -
Attach it to a
KeplerVideoSurfaceViewusing the surface handle. -
Create a
MediaSource. -
Add a MPEG-TS SourceBuffer containing H.264 High@L3.1 video and AAC-LC audio:
const sourceBuffer = mediaSource.addSourceBuffer(
'video/mp2t; codecs="avc1.64001F, mp4a.40.2"',
);
- Use:
sourceBuffer.mode = 'segments';
- Append MPEG-TS segments from an HLS stream using:
sourceBuffer.appendBuffer(tsSegment);
-
Start playback and allow it to run continuously.
-
Observe recurring visible micro-stutters.
-
Monitor the Vega device logs and media playback counters.
-
Repeat the same test using:
sourceBuffer.mode = 'sequence';
The problem remains reproducible at essentially the same rate.
3. Observed Behavior
Playback starts normally and audio/video are generally synchronized, but the video repeatedly exhibits short visible stutters.
During those events Vega reports:
No Time update in Playing
Our device-side measurements show:
media.currentTime:
temporarily stops advancing
totalVideoFrames:
continues increasing
droppedVideoFrames:
increases
We also compared the timing of the original MPEG-TS video frames with the timing observed in the Vega media pipeline.
Source stream:
435 / 435 measured frame intervals were consistent
Video rate: 29.97 fps
Expected frame interval: ~33.37 ms
On the Vega device, during the same type of playback:
543 video TrackBuffer gaps were observed.
The gaps correspond to exact multiples of approximately
2–3 video frames.
The equivalent discontinuities were not present in the MPEG-TS source timing.
We also performed a controlled SourceBuffer.mode comparison:
segments:
143.7 gap events / minute
sequence:
144.9 gap events / minute
Therefore, switching to sequence mode did not materially change the issue.
4. Expected Behavior
MPEG-TS media with continuous timestamps should be appended and presented without introducing additional periodic TrackBuffer gaps.
When sufficient media is already buffered and the incoming MPEG-TS timestamps are continuous, we expect:
media.currentTime to progress continuously
video frames to be presented continuously
droppedVideoFrames not to increase periodically because of media-clock stalls
Using the Amazon-recommended sequence mode for MPEG-2 TS/HLS content should also not exhibit the same recurrent TrackBuffer discontinuities if SourceBuffer timestamp handling is contributing to the issue.
4.a Possible Root Cause & Temporary Workaround
We have not identified the exact internal root cause.
The evidence currently points to timing/TrackBuffer handling within the Vega native MPEG-TS/MSE playback pipeline.
We have tested and ruled out several application-level candidates.
Network starvation
Not observed.
The issue occurs while approximately 20 seconds of playable media remain buffered ahead.
Buffer size
Not causal.
The same micro-stutters occur both with a stable ~20-second buffer and with substantially larger buffered ranges.
SourceBuffer append/remove contention
No temporal correlation was found between append/trim operations and the visible stalls.
Video surface lifecycle
The KeplerVideoSurfaceView remains mounted and attached during the stalls.
The surface is not recreated or detached.
Decoder stopping
Not observed.
totalVideoFrames continues increasing during media-clock stalls.
Dropped frames
droppedVideoFrames increases while media.currentTime is stalled.
Channel-switch teardown warnings
Messages such as:
Invalid Sink Type
flush failed
abortPendingReconfiguration
occur during channel teardown/switching, but not during the recurring micro-stutters.
SourceBuffer mode
Both modes were tested:
segments: 143.7 gaps/min
sequence: 144.9 gaps/min
No meaningful improvement was observed.
At this time we do not have a reliable application-side workaround.
5. Logs or crash report
There is no application crash.
Relevant device logs can be provided as a sanitized attachment.
The most relevant native playback message observed during the issue is:
No Time update in Playing
Our diagnostic instrumentation additionally records:
media.currentTime
totalVideoFrames
droppedVideoFrames
corruptedVideoFrames
bufferAhead
SourceBuffer updating state
append activity
trim activity
network request activity
surface generation / attachment state
We can provide sanitized logs containing these signals if required.
No authentication credentials, tokens, media URLs, or provider hostnames will be included.
6. Environment
-
SDK Version: [INSERT OUTPUT OF
vega --version] -
React Native Version: [INSERT EXACT VERSION]
-
App State: Foreground
-
Device: Vega Virtual Device — TV x86_64
-
@amazon-devices/react-native-w3cmedia: [INSERT EXACT VERSION]
-
@amazon-devices/kepler-video-view: [INSERT EXACT VERSION]
OS Information:
Please insert the exact output of:
vega exec vda shell
cat /etc/os-release
[INSERT /etc/os-release OUTPUT HERE]
7. Example Code Snippet / Screenshots / Screengrabs
Minimal playback configuration:
const mediaSource = new MediaSource();
videoPlayer.src = URL.createObjectURL(mediaSource);
mediaSource.addEventListener('sourceopen', () => {
const sourceBuffer = mediaSource.addSourceBuffer(
'video/mp2t; codecs="avc1.64001F, mp4a.40.2"',
);
sourceBuffer.mode = 'segments';
// MPEG-TS segments from the HLS playlist are fetched sequentially
// and appended through the SourceBuffer.
sourceBuffer.appendBuffer(tsSegment);
});
We also reproduced the same issue after changing only:
sourceBuffer.mode = 'sequence';
No buffer-size, network, append-queue, surface, or playback-timing changes were made during the A/B comparison.
Playback Issues
This is a Live HLS playback issue using MSE.
Pipeline:
HLS playlist
→ MPEG-TS media segments
→ MediaSource
→ video/mp2t SourceBuffer
→ Vega native MPEG-TS parser
→ VideoPlayer
→ KeplerVideoSurfaceView
The stream plays successfully, but recurrent video micro-stutters occur.
The source itself was inspected separately and showed continuous video frame intervals:
435 / 435 measured intervals consistent
29.97 fps
~33.37 ms/frame
The Vega playback pipeline subsequently reports hundreds of short TrackBuffer gaps corresponding to approximately 2–3 frames.
-
Player SDK:
@amazon-devices/react-native-w3cmedia/ custom MSE player -
Player SDK Version: [INSERT EXACT VERSION]
-
Audio Codecs: AAC-LC (
mp4a.40.2) -
Video Codecs: H.264 High@L3.1 (
avc1.64001F) -
Manifest Types: HLS / M3U8
-
Media segments: MPEG-TS
-
Architecture: x86_64 Vega Virtual Device
Q: If applicable, please provide your media/content URL
The production media URL is authenticated/tokenized and cannot be posted publicly.
We can provide a controlled reproduction stream or additional sanitized
stream characteristics privately if required.
Q: Are there any special headers required to reproduce the issue you are facing?
No special application-defined request headers are required beyond the
authentication mechanism used by the media provider.
Additionally please provide the following if possible
The key comparison from our device measurements is:
SOURCE
435 / 435 video frame intervals consistent
VEGA — mode=segments
143.7 TrackBuffer gap events/min
VEGA — mode=sequence
144.9 TrackBuffer gap events/min
During a gap:
media.currentTime → stops temporarily
totalVideoFrames → continues increasing
droppedVideoFrames → increases
We can provide sanitized logs and additional device captures if requested.
Additional Context
Any Additional Context you would like to provide?
We performed several controlled experiments before filing this report because we wanted to distinguish an application buffering issue from a native playback issue.
The following conditions have already been tested:
Healthy buffered media remains available during stalls.
Network fetches are not starved.
SourceBuffer append/trim operations do not correlate with the stalls.
The video surface remains attached.
The decoder continues producing video frames.
Dropped frames increase when media.currentTime stalls.
The incoming MPEG-TS frame timing is continuous.
Both SourceBuffer "segments" and "sequence" modes reproduce the issue.
We understand that sequence mode is recommended for HLS/MPEG-2 TS playback on Vega, which is why we specifically performed the A/B comparison.
We would appreciate guidance on the following:
-
Is recurrent
No Time update in Playingwith MPEG-TS over MSE a known Vega issue? -
Are there Vega-specific requirements for MPEG-TS PTS/DTS continuity or TrackBuffer timestamp handling beyond the standard MSE requirements?
-
Is there additional native media-pipeline logging or instrumentation we can enable to determine exactly where the 2–3-frame TrackBuffer gaps are introduced?
We are happy to provide sanitized device logs and further diagnostics if needed.