What I'm saying is you can't safely change that byte without sometimes needing to re-encode. That byte is being used to specify constraints, and in some cases it's over constraining the file such that a lower level of constraints may also be applicable (as above). However, my concern stems from the case where it's not over constrained, in which case you now have a level which is wrong and which would require a re-encode to have the media.
> In the worst case, if you change the level and it turns out that it was a real level 5.2 video, the decoder simply won't be able to play it, like it's already doing now.
It's not clear to me that the decoder will always gracefully reject the media as it does now. If you're manipulating the h264 stream being fed into the decoder such that it may contain incorrect metadata it seems like there could be more significant downsides such as crashing the process the decoder runs in.
I we had a way to verify that the level specified in the sps was over constrained it would make sense to mutate it. But blanket rewriting level information seems like it would cause it's own set of problems.
Bug 1479203 Comment 44 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
What I'm saying is you can't safely change that byte without sometimes needing to re-encode. That byte is being used to specify constraints, and in some cases it's over constraining the file such that a lower level of constraints may also be applicable (as above). However, my concern stems from the case where it's not over constrained, in which case you now have a level which is wrong and which would require a re-encode to have the media.
> In the worst case, if you change the level and it turns out that it was a real level 5.2 video, the decoder simply won't be able to play it, like it's already doing now.
It's not clear to me that the decoder will always gracefully reject the media as it does now. If you're manipulating the h264 stream being fed into the decoder such that it may contain incorrect metadata it seems like there could be more significant downsides such as crashing the process the decoder runs in.
If we had a way to verify that the level specified in the sps was over constrained it would make sense to mutate it. But blanket rewriting level information seems like it would cause it's own set of problems.
What I'm saying is you can't safely change that byte without sometimes needing to re-encode. That byte is being used to specify constraints, and in some cases it's over constraining the file such that a lower level of constraints may also be applicable (as above). However, my concern stems from the case where it's not over constrained, in which case you now have a level which is wrong and which would require a re-encode to have the media comply with the constraints.
> In the worst case, if you change the level and it turns out that it was a real level 5.2 video, the decoder simply won't be able to play it, like it's already doing now.
It's not clear to me that the decoder will always gracefully reject the media as it does now. If you're manipulating the h264 stream being fed into the decoder such that it may contain incorrect metadata it seems like there could be more significant downsides such as crashing the process the decoder runs in.
If we had a way to verify that the level specified in the sps was over constrained it would make sense to mutate it. But blanket rewriting level information seems like it would cause it's own set of problems.