Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Print video rotation #1400
@Piasy but the extension is still parsed where it was before, not when going through the video... this makes the method signature in the header useless. It should be in the
Rather than ask for another change, I'll try to prepare a small branch that looks for the CVO using the Janus-based code, and integrate it in webm and mp4 processors, so that you can test it and check if it works for your case. I'll keep you posted.
@lminiero I didn't understand you want to move the
My code parse all RTP extensions, there is a while clause.
I have such mjr files, I'll attach it here.
It contains 3 mjr recorded from native Android WebRTC client, native iOS WebRTC client, and browser Android client, which has 270, 90, 0 clockwise rotation.
@Piasy it's ok to parse there, but it should be available to the individual processors. For instance, this is what a
In the main code, I just count how many times the video rotated: in this case, there was just a single rotation (270), so even if the extension was there more than once, I summarize and say "The video is rotated" to clarify it's not a 0 degrees video. I take note of this rotation, and print it again in the h264 portion of the code.
As an example of other extensions, I also added support for the audio level extension, which I integrated in the audio processors. In both cases, there's not much we can do with the values we extract, but they're useful to print anyway.
I'll cleanup the code and publish it as a PR shortly, so that you can check if it works fine for your use case.