Quote:
Originally Posted by benwaggoner
Oh, if that was the only hard part! But what about the rare cases where the first NAL unit is larger than the following, which is allowed by the spec, but not by some SoC decoders? Or the many, many permutations of DRM encryption that can be fussy with some devices. Or Qualcomm DRM carveouts where you need to allocate on boot enough memory for the maximum resolution & max reference frames. Note that it's the worst case of both; supporting 320x180 with 6 reference frames and 3840x2160 with 3 reference frames requires 3840x2160x6 memory carveout.
|
I dont really follow how this can be an issue. Isnt the decoder validated for levels and profiles? If a decoder is specified to handle main10 main teir level 4, how could it not handle MaxDpbSize and vbv-limits within the spec? As long as the buffer is not higher then the maximum maxrate of that level/tier and that it can feed data in that rate shoudlnt it be all good? Or is this specifically an issue for some DRM solutions?
Quote:
|
And then there are all the heuristics that will treat a 15 Mbps peakrate as all fragments of that stream index being really 15 Mbps, so it won't go to that even when that top stream is at 3 Mbps and there's 12 Mbps of bandwidth.
|
Mind expanding on this? Why would it use the peakrate as decision for selection this way? Shouldn't the decision be made on buffer status and chunk sizes? Would that really be an issue with ABR with MPEG-DASH and HLS?