Hi there,
MSE is only supported on macOS and iPadOS, and not iOS (iPhone). So, if you are attempting to use MSE on an iPhone to play back the file, it will not succeed.
Interestingly, QuickTime X on macOS Big Sur is also unable to play back the streamATC.ts file, but can play back the streamFF.ts file no problem, so there's very likely a difference in the contents or header of the file itself that makes it incompatible with playback using AVFoundation.
I am unable to determine what exactly is going on with the file, but when AVFoundation attempts to open the file, it sees no playable tracks, nor can it determine a duration, let alone play back the media. The media likely is corrupt somehow.
If you're unable to determine the root cause, and can ensure that the file is indeed a valid and standards compliant media file, I would encourage you to file a bug report at feedbackassistant.apple.com, attaching the two files, and explaining the issue. Engineering can then try and take a look into why we are unable to open the file.
Thanks!
Post not yet marked as solved
Your summary is correct. The workaround I described (and also don't really recommend) does not work for contetn protected with FPS.
Post not yet marked as solved
The only way would be to add a window to the second UIScreen, which would then allow you to put the video player layer on that second screen and overlay visual elements on top.However, we'd not recommend this as it is likely to impact video quality, and also would prevent users from making use of their phone during video playback. Playback would stop as soon as the device goes to sleep or the app goes into the background.We would ask that you request this feature and capability as part of AirPlay video at bugreporter.apple.com
It would be expected that value woudn't be returned if the TV doesn't actually support it, but I haven't tested with that specific TV.Please file a bug report at bugreporter.apple.com with TV model details and the behavior you are seeing. Thanks!
Hi Antony,That API only includes the modes that both the Apple TV and the attached display can support. For example, if the external display does not support HDR10, then that wouldn't be included in the returned list.Thanks,Josh
This isn't an issue I've heard of before. Likely there's an issue at that transition point in the encoding or packaging.You could try inserting a discontinuity tag at that point and see if that makes a difference.If that doesn't help and you can't find anything obvious, please do file a bug at bugreporter.apple.com with a link to sample content and detailed repro steps.
Hey Eran,Unfortunately we don't have any such samples. But you could certainly request us to create some in the future at bugreporter.apple.comIt should work for MPEG-TS, though. And a discontinuity shouldn't be required. It should only necessitate the insertion of the KEY tag when the transition occurs.You could also file a bug with us at bugreporter.apple.com to investigate - please ensure you first install the core media logging profile on your device, available at the following URL, and then reboot your device before reproducing the issue:https://developer.apple.com/bug-reporting/profiles-and-logs/?name=coremediaIf you can include sample content in the bug report, that would be very helpful as well.Many thanks,Josh
Hi Eran,Having one track with two sample descriptions, one encrypted and one not, should work.You should still ensure that the EXT-X-KEY tag is at the correct place in the manifest, indicating the transition from unencrypted to encrypted content.Thanks,Josh
**EDIT - the #EXT-X-DISCONTINUITY tag is not required, so long as the timestamp sequence, GOP etc. are continuous.Hi Noam,achibana's answer is mostly correct, but the one change is the potential need to insert an #EXT-X-DISCONTINUITY tag ahead of the #EXT-X-KEY tag to indicate the significant change at that point, as follows:#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:1
#EXTINF:10,
01.ts
#EXT-X-DISCONTINUITY
#EXT-X-KEY:METHOD=SAMPLE-AES,KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1",URI="skd://1"
#EXTINF:10,
02.ts
#EXTINF:10,
03.tsAVPlayer will start playing without waiting for the response. Would recommend the inclusion of at least one target duration, if not more.Note that you can cause the key request to be completely asynchronous from playback using the AVContentKeySession approach, which would allow you to prefetch the keys separate from the actual playback session, which is the pattern that many developers are now taking in order to reduce complexity and dependencies at playback time.
Hi Noam,All that the discontinuity tag indicates is that there is a change present, and the presence of the tag should cause no disturbance at all.
Post not yet marked as solved
Hi Nam,You should see the typical UIApplication willResignActiveNotification when the app is placed into the background as a result of the sleep event.Thanks,Josh
Post not yet marked as solved
Hi there,In tvOS 11, we made some improvements on this front. However, there are some limitations that inhibit our ability to guarantee to always deliver this messaging, primarily due to the differences in how various TV sets behave in terms of HDMI and CEC signalling.When the screen-saver comes up, when the system goes to sleep, when the HDMI cable is pulled – those things we can know about with certainty. But whether or not the attached TV indicates to us the current state varies. If we can tell that the TV has been powered down, we will deliver the appropriate notifications... but if those signals aren't indicataed, there's not much we can do.Thanks!
Post not yet marked as solved
Hi Noam,I've updated my answer to be more clear in terms of the indexes - thank you for pointing that out.To be even clearer, you will receive a notification each time a new access log entry is appended to the array. The first notification means that one has been added and is currently being updated. Each subsequent notification means a new entry has been appended and is now being updated, while the prior entry is now in a freeze-dried state.The dropped frame count is an accumulator for each given bitrate tier, so those frames could have been dropped at any point during that tier. Note that a dropped frame is not considered as significant an event as when playback stalls, which triggers an AVPlayerItemPlaybackStalled notification.I hope that helps.Josh
Post not yet marked as solved
Hi Noam,The last entry in the array is the entry being currently updated. The second last entry in the array is the one that has just been "freeze dried" since it will no longer be updated.This freeze happens when a significant event, such as a transition between bitrates, occurs. The number of bytes transferred is an accumulator that runs until the next bitrate change. Thus, you can see for a given period of a given bitrate, how many bytes were transferred. The counter is reset for each bitrate transition.Through the full collection of entries, you are able to map out most details of a given playback session.You should receive one notification each time an event is marked as frozen.I hope that helps to clarify what you are seeing.Thanks,Josh
Post not yet marked as solved
Hi BSG,Because AVContentKeySession is designed to decouple the timing of license requests from the actual playback itself, many apps are performing the retrieval of license key URLs via a server API so that those key requests can be done long before even requesting the playlist.By out of band, I mean via a separte API call to the back end, as opposed to from the playlist itself.But you could parse them out of the playlist as well, if you prefer. Or, at playback time, you can use the delegate callbacks.
