Closed LePips closed 10 months ago
The device builder doesn't necessarily work for the native player implemented as an experimental feature here: https://github.com/jellyfin/Swiftfin/pull/320
Fixing to accommodate the native player isn't necessary for implementation, but something to think about.
I guess I should preface some of this discussion by saying I am unfamiliar with VLCKit, and I'm having trouble finding supported codecs for it.
It appears there is a distinction being made between the Apple TV 4k 1st gen and 2nd gen (A10X vs. A12), but the tech specs list the same codec support as does Apple's HLS guide: https://developer.apple.com/documentation/http_live_streaming/http_live_streaming_hls_authoring_specification_for_apple_devices/hls_authoring_specification_for_apple_devices_appendixes
Specifically, line 88 of /Shared/Objects/DeviceProfileBuilder.swift adds "truehd,dts,dca" I'm not an expert, but I didn't think Apple TV supported these formats - I know it supports Atmos, but my understanding was that it is not truehd and rather eac3 with added channel info. (https://developer.apple.com/documentation/http_live_streaming/http_live_streaming_hls_authoring_specification_for_apple_devices) Now, it is possible that VLCKit/TVVLCKit supports some of these formats, but if so, I would assume it would be the same between the 4k 1st gen and 2nd gen as well. (I know at one point they, or at least the VLC app, did not support TrueHD on Apple devices. https://code.videolan.org/videolan/vlc/-/issues/25040)
(Also: line 89 has h264 and hevc listed twice)
According to the HLS authoring specs Apple seems to prefer fMP4. I don't know much about it, but I did see a toggle on the web user profile to prefer it - should it be used instead of .ts in these profiles? Again, I'm not sure what support is like for VLCKit, but it seems like that is preferable for (experimental) native player, and might be more future-proof in any implementation.
Also, I just saw this post on the Jellyfin subreddit, and I thought it might be interesting to investigate: https://www.reddit.com/r/jellyfin/comments/w6hp7u/transcode_lossless_bluray_audio_to_flacalacwav_to/ I'm not sure if this is related to the profile builder, but since it seems like people could modify it using the transcoding targets in the profiles in Plex, I am thinking it might be. Basically if unsupported natively, set transcode target of Dolby TrueHD/TrueHD "core" of Dolby Atmos (if supported by ffmpeg; I don't think DTS-HD MA is unfortunately so better just to pass the DTS core untouched) to ALAC or FLAC to preserve lossless up to 7.1 at 48kHz. (As for bit depth, at one point Apple TV/tvOS was limited to 16 bits, but maybe that is now 24 bits. I am not sure...) I guess since I mentioned it above, I will point out that I'm not sure fMP4 would support FLAC since FLAC support in MP4 is non-standard. However ALAC might work. This would also mean "maxAudioChannels" would be higher than 6 (to 8?) maybe if we are targetting Apple TV's limitation which is 7.1. Since transcode profiles in current device profile builder have many audio codecs - how is one chosen over the other? Is it server-side?
As an aside, it might be nice to have the codecs listed in a uniform order throughout.
Please forgive the dumb question as I am truly out of my depth - does the profile builder need to be static? In other words, would a strategy of having it query the device itself (maybe on first run and after OS or certain app updates) using calls like AVURLAsset.audiovisualTypes() or AVURLAsset.audiovisualMIMETypes() and then extracting the appropriate strings to feed into profiles work? This would maybe obviate the need for keeping mappings of devices to processors to capabilities. Would VLCKit have a similar method to find supported media types? Even if it must (or should) be static, might these methods help keep the Profile Builder up-to-date in a scripted fashion - for example, running these methods on simulators and then logging output and sifting through programatically to extract the desired information before feeding it into the profile builder pre-compilation?
I honestly don't know. I didn't initially create this file and I haven't ever had time to look at this stuff really. We could probably use the AVURLAsset
functions, especially since it has isPlayableExtendedMIMEType(_:)
as well but we would make do with the other two listing the types. VLCKit is a wrapper of libvlc, so its supported codecs is here but can't be grabbed at runtime.
I'm all for a dynamic resolution for supported types per device. Moving away from static would be absolutely amazing but of course would need some testing to verify that it's working for a few types of devices.
I'll consider closed by #519
Need to somehow automate the device profile builder when it comes device/cpu pairing. Making this hardcoded on our end means we have to be on top of all of it, causing problems for people if devices are missed.
The package below has all of the current device identifiers and updates regularly, but doesn't provide CPU data. I'll keep looking for something that can provide that information.
https://github.com/SeparateRecords/apple_device_identifiers
Device codec support also needs to be fixed so that streams that can be direct playing aren't transcoded.