Some streams are not loading #1611
Comments
|
Hm we could give it a try. However what i found out is when you try to pull out the url to the DASH MPD file, and feed it to VLC you will see that VLC player indeed uses a 480p resolution. ... I'll check this once more. |
|
What's stranger is the web browser player only goes up to 240p for the sample video. Also, I think dash manifest is only available for older videos, so we probably can't reliably use it for parsing stream urls. Perhaps instead of parsing the manifest ourselves, maybe we can later implement a quality selector for live/dash/hls streams in the player and use dash instead of fmp4 for those videos providing manifests. You can experiment with it by removing this check. |
It's a vertical video and I think YouTube returns the Itag's id based on format and the height, while in their UI, it takes the smallest side instead and round it to the nearest common resolution abbreviation. The issue is that YouTube returns a segmented stream: <Representation id="135" codecs="avc1.4d400b" width="270" height="480" startWithSAP="1"
maxPlayoutRate="1" bandwidth="1155000" frameRate="30">
<BaseURL>[...]googlevideo.com[...]/key/dg_yt0/</BaseURL>
<SegmentList>
<Initialization sourceURL="sq/0"/>
<SegmentURL media="sq/1/dur/5.000"/>
[...]
<SegmentURL media="sq/12/dur/5.000"/>
<SegmentURL media="sq/13/dur/2.700"/>
</SegmentList>
</Representation>While a player would parse it correctly, the extractor is blindly taking the However, if the segment list uses another delivery format (that uses <Representation id="134" codecs="avc1.4d400d" width="202" height="360" startWithSAP="1"
maxPlayoutRate="1" bandwidth="324904" frameRate="30">
<BaseURL>[...]googlevideo.com[...]/key/dg_yt0/</BaseURL>
<SegmentList>
<Initialization sourceURL="range/0-708"/>
<SegmentURL media="range/897-183954"/>
[...]
<SegmentURL media="range/1761656-1913747"/>
<SegmentURL media="range/1913748-2022062"/>
</SegmentList>
</Representation>The data source from the ExoPlayer receives a 404, but it just keeps retrying because of this. I'm not really familiar with the implementation anymore, so I don't really know why is set to the maximum. But even though the retry is set to that value, it seems strange that a 404 is not assumed as a fatal error, maybe there's more implementation details to it? |
|
Hm so we need to change the way the back end is handling DASH files. |
Oh I see, nice find.
I'm not sure what's causing the 404 on the sample video, the 480p stream fails on browser yet still plays on the web browser (with audio only), and it seems Exoplayer is actually able to sniff out the format of the stream and determine the source is mp4. ExoPlayer does throw a fatal error in case if it can't figure out the type of extractor needed to play the stream.
Why? |
Answer from @mauriciocolli
It does not make sense to return the BaseUrl if it can not be played without looking into the DASH MPD. I think it would make more sense if we didn't return a url here, but something that points to the corresponding element in the MPD file. |
|
According to this blog entry you can either put the whole video into |
|
The question now is, should we list such streams, or should we ignore them? |
|
I might be misunderstanding where we are going here, but isn't the problem that for most newer videos there is no dash manifest url available? If a video does have a manifest, we can just modify the front end and use ExoPlayer to play the manifest directly instead of dealing it ourselves, as mentioned before. Why is parsing and cherry-picking the manifest preferable to just playing it here? Is there anything we can do for videos without manifest available? |
Yes it seems that videos with a manifest are rather rare.
The idea would be to get full working streams out of it as a fallback. However the question I rose belonged to streams which where segmented, by means there is not one URL pointing to the stream, but many pointing to separate parts of it. I've decided to ignore such streams, so they will not be shown in the selection. However @karyogamy just like you said, since ExoPlayer can handle such streams it could still play them, by directly parsing the MPD file. |
For some streams some resolution is never loading.
Take this one here for example:
https://www.youtube.com/watch?v=00Q4SUnVQK4
If you select 480p you will see the Loading cycle cycle forever.
This is the coresponding logcat output:
@karyogamy || @mauriciocolli could you please take a look at it. I will provide you with more information as I try to debug this.
The text was updated successfully, but these errors were encountered: