search

brarcher / video-transcoder

Android app for video and audio transcoder, based on FFmpeg
GNU General Public License v3.0
481 stars 57 forks source link

Compression pauses when (app is in background && Screen is locked) #138

Open symphonyrecords opened 5 years ago

symphonyrecords commented 5 years ago

I've tried wavelock , AlarmManager with no success. I don't know maybe I'm doing something wrong but still compression process will pause when app goes in background and screen locks. Any solutions!?

brarcher commented 5 years ago

Hm. I attempted to set it up so that the service which does the encoding runs in the foreground, so that it does get CPU when it needs. I though that would also hold a power lock so it could still encode when the screen is off. The background service would run even if the app was not visible. I'll have to see if I'm wrong about the power lock.

What version of Android are you running on?

symphonyrecords commented 5 years ago

Thank you for your respond. I saw this issue in Honor 8 Lite - API24(I checked developer settings for don't keep activity or destroy activity... , everything are set to their default). But in Samsung j5 Prime API24 it works as it's expected.

brarcher commented 5 years ago

Hm. The device I'm testing with is also Android 7, and it appeared to work there as well. What I do see is that the encoding progress is slower when the screen is off. It may be that the CPU is being throttled in my case when the screen is off.

Are you able to capture logs when this happens? That may help in figuring out what is happening.

licaon-kter commented 5 years ago

@symphonyrecords You did disable battery optimizations for the app?

You did add it to whatever "protected apps" whitelist you can use in Android Setting, right?

symphonyrecords commented 5 years ago

@brarcher , Yes, when app is in background the process gets slower, and in about 20 sec it will completely pause until I unlock the screen. Yes I figured this issue while I was capturing the log, also the log gets paused when this happens. I Already tried many things I'm trying to figure this out for about a week now.

symphonyrecords commented 5 years ago

@licaon-kter I checked allow app to ignore battery optimizations. didn't worked

symphonyrecords commented 5 years ago

@brarcher There is another note that might worth mentioning. In android studio when app is attached to adb through USB Cable everything works fine even in background and screen is locked, even compression don't gets slower. This issue only appears if I connect device to adb through Wifi.

brarcher commented 5 years ago

I tried an experiment yesterday, setting the app to encode the audio from a 4 hour video overnight while plugged in. 8 hours later it was ~90% complete. After another ~20 minutes it completed.

From this, on my device (LineageOS running Android 7.1.1) I see that when the screen is off and adb is disconnected the CPU is being throttled but not being completely stopped.

The service in the app which monitors ffmpeg is run as a foreground service. Looking up the docs on that Android does not limit the execution of such services. (If it was a background service it could stop execution after a time when the screen is off).

There is a new power lock hint that can be used in Android 7 that requests the device provide sustained performance: https://source.android.com/devices/tech/power/performance

I do not know if that could help the issue or not while encoding. It is worth looking into.

symphonyrecords commented 5 years ago

@brarcher Thank you. I appreciate it, I'll look into it.

symphonyrecords commented 5 years ago

@brarcher This is not related to this issue but I have this class that will get log from ffmpeg output and parse necessary metadata. So it will help you to remove ffprobe from your app and reduce app size . I've tested on a few media files and it's working fine so far.

brarcher commented 5 years ago

It is unfortunate that including ffprobe effectively doubles the size of the app (19MB for x86 and 17MB for ARM). Initially I used ffmpeg instead of ffprobe (see this commit). Ultimately I switched to ffprobe for a few reasons. First, ffmpeg would return non-zero when it gave status information, so it was not straight forward to determine when a media file was invalid. In contrast, ffprobe will return non-zero if the file is unsupported. Additionally, the output from ffmpeg did not seem that it would follow a fixed layout (maybe it is not intended to be machine readable) and could be changed across releases. However, ffprobe can output in json format, making it easier to navigate. Finally, if there are multiple audio, video, or subtitle streams navigating the json would be easier than having a state machine when parsing.

I hear you, though. If ffmpeg had an option to output media information in json format I'd probably remove ffprobe. I'm just hesitant to use it as is, as I do not want to fix the parsing code whenever I update ffmpeg. (: I guess I could also have separate versions of the app for x86 and ARM instead of combining it to reduce the size.

symphonyrecords commented 5 years ago

@brarcher fair enough