Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loading Remote Video Enhancement Request #4021

Closed
kachi1227 opened this issue Dec 23, 2019 · 1 comment · Fixed by #4033
Closed

Loading Remote Video Enhancement Request #4021

kachi1227 opened this issue Dec 23, 2019 · 1 comment · Fixed by #4033

Comments

@kachi1227
Copy link

Glide Version: 4.9.0

Integration libraries: No

Device/Android Version: Google Pixel 3

Issue details / Repro steps / Use case background:
When loading a video thumbnail from a remote url, Glide does not work if the DiskCacheStrategy is set to RESOURCE or NONE. As you may already know, this is because Glide first saves the video data it receives from the url to the DiskCache and then passes this cached file to the VideoDecoder to obtain the frame. The problem with this approach is that if a DiskCacheStrategy like RESOURCE is used, then the video file never gets saved to the DiskCache and the VideoDecoder is never used to obtain the frame. Here are the logs:

2019-12-23 12:04:07.691 5180-5180/kachi.com.playground W/Glide: Load failed for http://example.com/video/vid157594410145.MOV with size [700x700]
    class com.bumptech.glide.load.engine.GlideException: Failed to load resource
      Cause (1 of 1): class com.bumptech.glide.load.engine.GlideException: Failed LoadPath{ContentLengthInputStream->Object->Drawable}, REMOTE
        Cause (1 of 3): class com.bumptech.glide.load.engine.GlideException: Failed DecodePath{ContentLengthInputStream->GifDrawable->Drawable}
        Cause (2 of 3): class com.bumptech.glide.load.engine.GlideException: Failed DecodePath{ContentLengthInputStream->Bitmap->Drawable}
        Cause (3 of 3): class com.bumptech.glide.load.engine.GlideException: Failed DecodePath{ContentLengthInputStream->BitmapDrawable->Drawable}

Currently, VideoDecoder is using the MediaMetadataRetriever to find the appropriate frame. A potential workaround for the problem I mentioned would be to first check the content-type of the urlConnection inside HttpUrlFetcher. If the content-type started with "video/", the HttpUrlFetcher would use a MediaMetadataRetriever to fetch a bitmap from the video (as opposed to deferring this step to the VideoDecoder) and convert the bitmap to an InputStream that would get sent to callback.onDataReady(); else, the HttpUrlFetcher would just behave as it currently does. With this approach, HttpUrlFetcher would always return an InputStream of an image, so it would work the same for images and videos, regardless of the DiskCacheStrategy that gets used.

@stale
Copy link

stale bot commented Dec 30, 2019

This issue has been automatically marked as stale because it has not had activity in the last seven days. It will be closed if no further activity occurs within the next seven days. Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants