Video Player "waits for metadata" on correctly structured mp4s

ghost commented

2017-11-17 16:25:26 +01:00

(Migrated from github.com)

UPDATE
If you PLAY a video and it ends up "Waiting for Metadata," if you leave to another page and then hit the back button to return to the Video Page, the video is able to play.

The Issue

Waiting for metadata and refusing playblack. Similar bug: "Requesting stream" until download finishes instead of streaming ASAP.

Steps to reproduce

Go to lbry://unbubbled1-1
Hit play
See "Waiting for Metadata" permanently
Go to lbry://getbitcoincashoutofelectrumin60seconds
Hit play
See "Requesting Stream" ... until playback begins as Download Complete notification happens.

Expected behaviour

Tell us what should happen
Video plays relatively quickly.

Actual behaviour

Tell us what happens instead
No playback because of metadata stoppage/non-reading or slow playback start until downloads complete.

System Configuration

Mac OS Sierra

LBRY Daemon version:
LBRY App version:
LBRY Installation ID:
Operating system:

Anything Else

Screenshots

**UPDATE** If you PLAY a video and it ends up "Waiting for Metadata," if you *leave* to another page and then hit the back button to return to the Video Page, the video is able to play. ## The Issue Waiting for metadata and refusing playblack. Similar bug: "Requesting stream" until download finishes instead of streaming ASAP. ### Steps to reproduce 1. Go to lbry://unbubbled1-1 2. Hit play 3. See "Waiting for Metadata" permanently 1. Go to lbry://getbitcoincashoutofelectrumin60seconds 2. Hit play 3. See "Requesting Stream" ... until playback begins as Download Complete notification happens. ### Expected behaviour Tell us what should happen Video plays relatively quickly. ### Actual behaviour Tell us what happens instead No playback because of metadata stoppage/non-reading or slow playback start until downloads complete. ## System Configuration Mac OS Sierra   - LBRY Daemon version: - LBRY App version: - LBRY Installation ID: - Operating system: ## Anything Else  ## Screenshots

ghost commented

2017-11-17 16:26:48 +01:00

(Migrated from github.com)

I believe we need a new video player, and I might go so far as to say we should use closed-source off the shelf / request a closed source and open-source our own modification of it, if other open-source players are similarly bad.

This player does not allow us to see what metadata isn't being retrieved, to my knowledge. So we couldn't give encoding guidelines if we wanted.

UPDATE: I've revised my opinion that it is specifically page design choices and not necessarily the video player's fault for Waiting for Metadata sticking.

I believe we need a new video player, and I might go so far as to say we should use closed-source off the shelf / request a closed source and open-source our own modification of it, if other open-source players are similarly bad. This player does not allow us to see *what* metadata isn't being retrieved, to my knowledge. So we couldn't give encoding guidelines if we wanted. UPDATE: I've revised my opinion that it is specifically page design choices and not necessarily the video player's fault for Waiting for Metadata sticking.

kauffj commented

2017-11-17 21:15:05 +01:00

(Migrated from github.com)

@tzarebczan is this the same or different than https://github.com/lbryio/lbry-app/issues/635#issuecomment-333911622 ?

tzarebczan commented

2017-11-17 23:47:34 +01:00

(Migrated from github.com)

@kauffj believe its different - if you leave the claim page and re-enter, it does start streaming. Also, I uploaded it to instant.io and it streams there (the other videos did not): https://instant.io/#30d175dec43e4a89306100d032ab4ecc9af4c057

Also, doubled checked the video in #635 and it does not stream after exiting the claim page and coming back.

@kauffj believe its different - if you leave the claim page and re-enter, it does start streaming. Also, I uploaded it to instant.io and it streams there (the other videos did not): https://instant.io/#30d175dec43e4a89306100d032ab4ecc9af4c057 Also, doubled checked the video in #635 and it does not stream after exiting the claim page and coming back.

👍 1

tzarebczan commented

2017-12-15 16:46:12 +01:00

(Migrated from github.com)

This has been happening to me quite often - if I do a refresh of the app (or leave/come back to the claim), the video starts streaming (while its still downloading)

kauffj commented

2017-12-15 22:23:19 +01:00

(Migrated from github.com)

If these are playing on reload that it definitely sounds like a bug, and one that should likely be relatively high priority (@liamcardenas).

tzarebczan commented

2018-01-30 15:15:20 +01:00

(Migrated from github.com)

@alexliebowitz - here are some related video player issues which might be worth looking at if you start debugging the code:

https://github.com/lbryio/lbry-app/issues/937
https://github.com/lbryio/lbry-app/issues/635 (most likely an issue in the player)
https://github.com/lbryio/lbry-app/issues/418

You can also use instant.io to test the web player on another platform. I'm gonna open up another issue where non-web optimized MP4s play there correctly but in our app, the file must finish downloading before it plays.

Edit: Issue opened: https://github.com/lbryio/lbry-app/issues/980

@alexliebowitz - here are some related video player issues which might be worth looking at if you start debugging the code: https://github.com/lbryio/lbry-app/issues/937 https://github.com/lbryio/lbry-app/issues/635 (most likely an issue in the player) https://github.com/lbryio/lbry-app/issues/418 You can also use instant.io to test the web player on another platform. I'm gonna open up another issue where non-web optimized MP4s play there correctly but in our app, the file must finish downloading before it plays. Edit: Issue opened: https://github.com/lbryio/lbry-app/issues/980

IGassmann commented

2018-02-27 17:51:23 +01:00

(Migrated from github.com)

The issue hasn't been actually resolved.

neb-b commented

2018-07-09 18:31:55 +02:00

(Migrated from github.com)

Planning on working on this

tzarebczan commented

2018-07-23 15:20:38 +02:00

(Migrated from github.com)

@skhameneh to take a stab at this.

https://github.com/jhiesey/videostream

https://github.com/feross/render-media/issues/31 /https://github.com/lbryio/lbry-desktop/issues/635 (always happening on this file)

@skhameneh to take a stab at this. https://github.com/jhiesey/videostream https://github.com/feross/render-media/issues/31 /https://github.com/lbryio/lbry-desktop/issues/635 (always happening on this file)

tzarebczan commented

2018-08-06 17:43:40 +02:00

(Migrated from github.com)

I've been running into this issue less and less. My current hypothesis is that the daemon may sometimes write blob 2 of a file before blob 1 (which has metadata), so the event for loaded metadata is never fired. This makes sense that the file streams if you leave the file and come back.

skhameneh commented

2018-08-07 22:34:00 +02:00

(Migrated from github.com)

Notes:

The media player begins reading from disk with no awareness of the completion of blobs. See e8aa67bf7e/src/renderer/component/fileViewer/internal/player.jsx (L165)
videostream v2 as used in render-media does not support fragmented MP4's (variable bitrate optimized MP4's)
The current implementation of the daemon does not guarantee that the blobs are written in sequential order; detecting which ranges of data in the written file are available is difficult and not reliable. See https://github.com/lbryio/lbry/issues/1342
A number of links to files that play in Chrome are actually unsupported VP8 encoded within MP4 containers. The video codec must be in the ISO/IEC 14496-12 spec, see https://en.wikipedia.org/wiki/ISO_base_media_file_format

Notes: 1. The media player begins reading from disk with no awareness of the completion of blobs. See https://github.com/lbryio/lbry-desktop/blob/e8aa67bf7eefeb778617403a89d593081cb62b2d/src/renderer/component/fileViewer/internal/player.jsx#L165 2. `videostream` v2 as used in `render-media` does not support fragmented MP4's (variable bitrate optimized MP4's) 3. The current implementation of the daemon does not guarantee that the blobs are written in sequential order; detecting which ranges of data in the written file are available is difficult and not reliable. See https://github.com/lbryio/lbry/issues/1342 4. A number of links to files that play in Chrome are actually unsupported VP8 encoded within MP4 containers. The video codec must be in the `ISO/IEC 14496-12` spec, see https://en.wikipedia.org/wiki/ISO_base_media_file_format

neb-b commented

2019-08-13 19:53:46 +02:00

(Migrated from github.com)

Fixed with new player

Video Player "waits for metadata" on correctly structured mp4s #754

The Issue

Steps to reproduce

Expected behaviour

Actual behaviour

System Configuration

Anything Else

Screenshots