Closed xloem closed 3 years ago
Lots smoother, will pull & review this for sure!
Lots smoother, will pull & review this for sure!
Please let me know if it's at all hard to review and I'll look over it and recover what I was thinking, or maybe resubmit something more clear and organized.
Little confused by some of it, but from a quick look it appears a lot of logic was blocking frame processing? While it’s a little messy to merge as is, a few commits showing what’s being changed & why is super helpful. Thanks again for the efforts
I'll review it and maybe force-push something clearer. I think basically I removed the existing encoding code, and instead just had the CameraView library do the encoding itself. Likely it didn't support this yet when the code was first written.
Little confused by some of it, but from a quick look it appears a lot of logic was blocking frame processing? While it’s a little messy to merge as is, a few commits showing what’s being changed & why is super helpful. Thanks again for the efforts
There's pretty much just one change, which is removing jcodec and replacing it with use of CameraView's takeVideoSnapshot feature, which does basically the same thing as the removed code (using android's internal MediaCodec and MediaMuxer classes, which are much faster).
I've forced-pushed a clearer commit.
This should be pretty clear now if you look at the view in https://github.com/guardianproject/haven/pull/418/files . Let me know if there would be a better way to make it clearer, or any other work I could do to help this situation.
EDIT: one of the changes I removed prevents compilation. Fix forthcoming.
Okay. Thanks.
Re-pulled in #434 . I think the haven project is waiting on CameraX to be resolved before considering this. Maybe I'll have time to look at CameraX's state.
a quick for #413
the result of using the existing CameraView class to record video is actually simpler code.