Issue #253 mp3 audio seek fix #320

Merged

akinwale merged 6 commits from issue253 into master

2017-07-11 22:46:36 +02:00

akinwale commented

2017-07-02 12:17:05 +02:00

(Migrated from github.com)

Implemented a workaround to load the entire media file using xhr if an audio media element is detected after the metadata is loaded.

I published a test MP3 file to lbry://beyed.

Implemented a workaround to load the entire media file using xhr if an audio media element is detected after the metadata is loaded. I published a test MP3 file to lbry://beyed.

6ea86b96 commented

2017-07-02 19:14:00 +02:00

(Migrated from github.com)

What is that actual cause of this issue? It's only a subset of audio files that are not seekable afaik. Seems a bit unfortunate if we have to download the entire file for all audio files to fix the bad ones.

akinwale commented

2017-07-02 20:17:45 +02:00

(Migrated from github.com)

According to the issue at https://github.com/lbryio/lbry-app/issues/253, it appears that the player cannot seek through the file until it has finished playing at least once, which indicates that the length is not determined when the media file is first loaded. I can try to limit this to just files with the have the content type, "audio/mpeg3" or "audio/mpeg". Although it's not perfect, it limits the full load to just MP3 audio files.

kauffj commented

2017-07-04 20:21:25 +02:00

(Migrated from github.com)

I'd like confirmation that the render-media plugin has this issue for all MP3s before merging this. @akinwale could you try confirming this issue exists with the plugin directly?

I'd like confirmation that the [render-media](https://github.com/feross/render-media) plugin has this issue for all MP3s before merging this. @akinwale could you try confirming this issue exists with the plugin directly?

6ea86b96 commented

2017-07-05 08:47:27 +02:00

(Migrated from github.com)

@kauffj @akinwale perhaps we could check if a file is seekable or not and delay playback until it is so we catch any unseekable file types.

We already know when the metadata has been loaded in the current implementation (using the metadataloaded event https://developer.mozilla.org/en/docs/Web/Guide/Events/Media_events). It's possible to check if a file is seekable too https://www.w3schools.com/tags/av_prop_seekable.asp.

@kauffj @akinwale perhaps we could check if a file is seekable or not and delay playback until it is so we catch any unseekable file types. We already know when the metadata has been loaded in the current implementation (using the `metadataloaded` event https://developer.mozilla.org/en/docs/Web/Guide/Events/Media_events). It's possible to check if a file is seekable too https://www.w3schools.com/tags/av_prop_seekable.asp.

akinwale commented

2017-07-06 07:44:28 +02:00

(Migrated from github.com)

@kauffj From further testing, I tried adding the audio element to the media container directly using downloadPath for the src attribute, and the audio was seekable, so it looks like the problem could be with the render-media plugin, perhaps with the way the file stream is being created. Considering this is the case, I think we can handle the audio/mpeg content type differently by appending the HTML5 audio element directly, while every other type content type will be handled by render-media. What do you recommend?

@kauffj From further testing, I tried adding the audio element to the media container directly using `downloadPath` for the `src` attribute, and the audio was seekable, so it looks like the problem could be with the render-media plugin, perhaps with the way the file stream is being created. Considering this is the case, I think we can handle the `audio/mpeg` content type differently by appending the HTML5 audio element directly, while every other type content type will be handled by render-media. What do you recommend?

akinwale commented

2017-07-06 07:48:44 +02:00

(Migrated from github.com)

@6ea86b96 I tried to use this but it doesn't work. The seekable time range end returns a value (which is less than the audio duration), but I am still unable to seek when I try to drag the control.

kauffj commented

2017-07-06 16:45:01 +02:00

(Migrated from github.com)

@akinwale Bypassing render-media and using the audio element directly sounds like a reasonable solution to me.

akinwale commented

2017-07-06 19:41:39 +02:00

(Migrated from github.com)

@kauffj Pushed a new commit.

Added the contentType property to the VideoPlayer component.
Added a renderAudio method which is used instead of render-media if the contentType is audio/mpeg3 or audio/mpeg.
Merged with master to resolve conflicts.

@kauffj Pushed a new commit. * Added the `contentType` property to the `VideoPlayer` component. * Added a `renderAudio` method which is used instead of render-media if the `contentType` is `audio/mpeg3` or `audio/mpeg`. * Merged with master to resolve conflicts.