2000420 - playback wants to buffer the whole file if mkv

Status: NEW

(Core :: Audio/Video: Playback, defect, P2)

Description

[ivan g]

after upgrading to firefox 145 in macos I started seeing problems when playing my files, which all are mkv. specially with h264 I am able to reproduce the issue many times in which when clicking playing, it tries to buffer the whole file and the playback doesn't start

try with either of these files, first download them then run an http server that support ranges

• https://repo.jellyfin.org/archive/jellyfish/media/jellyfish-30-mbps-hd-hevc.mkv
• https://repo.jellyfin.org/archive/jellyfish/media/jellyfish-30-mbps-hd-h264.mkv

$ pip install rangehttpserver
$ python3 -m RangeHTTPServer

more context is avail in https://github.com/jellyfin/jellyfin/issues/15521

Comment 1

[ivan g]

Attachment: huge download when trying to playback

shows that it's buffering too much and no playback starts

Comment 2

[ivan g]

I want to add the helpful feedback from github/afontenot user

here are two 30 second clips. Opening the first one in Firefox refuses to play until it's buffered the entire file (~60 MB). The second one starts playing immediately, even though you can see that it has not loaded the whole file.

audio.mkv << issue

noaudio.mkv << no issue

I reproduced this in 147 nightly (via AppImage) so this is definitely not fixed.

Comment 3

[Alastor Wu [:alwu]]

I can reproduce this, I will take a look. Keep NI.

Comment 4

[rpnpif]

Please enable the mkv files playback as soon as possible by the #1422891 bug that is very old. Webm files work fine. And MP4 that are very closed as architecture work also fine. Today we cannot play MKV on Firefox for security reason (sic).

Comment 5

[harry75369]

I found a concrete full-file-buffering mechanism on the MKV+AAC path that
likely explains (at least the audio part of) this bug.

MatroskaDemuxer::SetContainerAudioCodecInfo() calls
nestegg_read_total_frames_count() during ReadMetadata for AAC tracks, and
that function loops ne_read_cluster_frames_count() until EOS, i.e. it
sequentially reads the entire file before "Read metadata OK" is reached,
so playback cannot start until the whole file is downloaded.

Reproduced locally with a throttled (3 MB/s) HTTP server and the jellyfish
file from this bug (jellyfish-30-mbps-hd-hevc.mkv, 114 MB) remuxed with an
AAC track:

• video-only file: "Read metadata OK" quickly, first frame decoded early.
• same video + AAC: the demuxer log stops at "Read metadata, track 1,
  codec id 7" (the AAC track); no "Read metadata OK" and no decoded frame
  within 32 s, while the single progressive download runs to completion.

The frame count feeds AacCodecSpecificData::mMediaFrameCount, consumed for
gapless trimming by AppleATDecoder and WMFAudioMFTManager. The MP4 demuxer
gets the same value for free from the sample table (DecoderData.cpp), so
only the MKV+AAC path pays a full scan at startup. Computing it lazily (or
skipping it when the decoder doesn't need trimming) should fix the
AAC-in-MKV startup buffering.

Note this covers MKV+AAC; the video-only jellyfish buffering reported here
may have an additional cause, since the video-only file does not hit this
code path.

Comment 6

[harry75369]

Attachment: Bug 2000420 - Don't scan the whole file for AAC frame count in MatroskaDemuxer. r=alwu

SetContainerAudioCodecInfo called nestegg_read_total_frames_count()
during ReadMetadata for AAC tracks. That function reads clusters until
EOS, so playback cannot start until the entire file is downloaded.

Nothing reads AacCodecSpecificData::mMediaFrameCount downstream (it is
only copied into never-read decoder members), so leave it at 0 and skip
the scan. This also removes a hard failure path: a counting error used
to reject the whole file.

Verified over throttled HTTP: ReadMetadata now completes 0.4s after
start (previously never within 32s) and A/V samples demux and decode
normally.