On Fri, 24 Jul 2026 00:02:19 GMT, Alexander Matveev <[email protected]> 
wrote:

>> * Replaced `qtdemux` with a Media Foundation-based MP4 demuxer on Windows.
>> * The Media Foundation-based MP4 demuxer supports **pull mode only** due to 
>> the design of the Media Foundation APIs. For fragmented MP4 (fMP4) segments, 
>> each segment is demuxed independently because of API limitations. After 
>> processing each segment, the demuxer internally creates a new Source Reader.
>> * **HLSConnectionHolder:** Headers are now sent with every segment because 
>> the MP4 demuxer reloads the Source Reader for each segment. Headers are 
>> intentionally not cached to avoid unnecessary connections. Additionally, HLS 
>> streams with separate audio renditions now seek to the last segment when 
>> seeking to the end of the stream, matching the behavior of standard HLS 
>> streams.
>> * **JavaSource:** Removed the unused `update` flag and moved caps setting 
>> into a dedicated switch case.
>> * Added trace support for Media Foundation-based plugins (both the demuxer 
>> and decoder). The tracing infrastructure is still a work in progress and 
>> will be expanded as needed for debugging. It is disabled by default and can 
>> only be enabled at compile time.
>> * H.264 video from MP4 and fMP4 (HLS) is now decoded using Media Foundation 
>> instead of DirectShow. H.264 video in TS-based HLS streams continues to use 
>> DirectShow. This change avoids several DirectShow issues encountered with 
>> the new MP4 demuxer and reduces implementation complexity.
>> * Updated `MFWrapper` to properly support H.264 decoding. Unlike H.265, 
>> H.264 requires using the display aperture for the display resolution, does 
>> not signal frame availability, requires handling format changes, and must 
>> fully drain output before accepting new input samples.
>> * Modified the cache implementation to support pull mode for the HLS 
>> progress buffer.
>> * Added pull mode support to the HLS progress buffer.
>> * Changed `progressbuffer` to use a static source pad instead of a dynamic 
>> one, simplifying pipeline construction. The need for a dynamic source pad is 
>> unclear.
>> * Performed minor cleanup by removing dead and obsolete code.
>> * The progress buffer is now forced when `JavaSource` does not support pull 
>> mode (for example, with `jar` and `jrt` protocols). This provides a simple 
>> workaround until native pull mode support is implemented for these 
>> protocols. In particular, `jar` does not provide true random access at the 
>> Java layer anyway.
>> 
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the 
>> [OpenJDK Interim AI Policy](https://op...
>
> Alexander Matveev has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8305842: Replace qtdemux with MP4 demux based on Media Foundation [v5]

8305842: Replace qtdemux with MP4 demux based on Media Foundation [v5]
- Changed on how HLS select media file index when variant playlist is switched. 
It was based on file name, but it is not reliable, since file names are not 
guarantee to match. Instead index is adjusted based on sequence number which 
should not drift more then +/- 1 when switch is done. Sequence number is like 
index of first segment file in live streams.
- Fixed issue when variant playlist was not detected as live even it was live. 
Playlist with variant playlists was detected correctly as live.
- Fixed reload time. Thread sleep is expecting milliseconds and we provided 
(seconds / 2) as milliseconds without conversion. As are result we where 
requesting playlist way too often.
- Redone mechanism on how we waiting for live segments to be added. Old 
approach had a bug with semaphore and if we added two segments in one run it 
will cause code to assume that we have segments when we did not. As a result 
EOS was signaled for live streams. This issue does not reproduce often, but 
might happen.
- Old playlist data will be cleared when we switching bitrate, otherwise we 
will attempt to play old segments which are gone long time.
- Fixed removing old segments not to remove init header for fMP4.
- Added additional tracing to mfdemux and mfwrapper.
- mfdemux will not push caps event if caps did not change. When event is pushed 
decoder will flush and cause video glitch.
- mfdemux will adjust segment event to first PTS. Needed for live streams, 
since their PTS does not start with 0.
- Increase queue buffers for HLS Live on Windows with mfdemux since we reload 
source reader for each segment to eliminate stream break ups.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/2206#issuecomment-5064861426

Reply via email to