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

Error with MPD initialization chunk #1287

Closed
topolog opened this issue Feb 19, 2016 · 7 comments
Closed

Error with MPD initialization chunk #1287

topolog opened this issue Feb 19, 2016 · 7 comments
Labels

Comments

@topolog
Copy link

topolog commented Feb 19, 2016

I'm having an error in the demo app when I try to play a dash content. I have been able to run the example, with the Widevine Dash. The error I get is:

com.google.android.exoplayer.ExoPlaybackException: com.google.android.exoplayer.upstream.HttpDataSource$InvalidResponseCodeException: Response code: 416
at com.google.android.exoplayer.SampleSourceTrackRenderer.maybeThrowError(SampleSourceTrackRenderer.java:263)
at com.google.android.exoplayer.SampleSourceTrackRenderer.maybeThrowError(SampleSourceTrackRenderer.java:145)
at com.google.android.exoplayer.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:438)
at com.google.android.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:213)
at android.os.Handler.dispatchMessage(Handler.java:98)
at android.os.Looper.loop(Looper.java:145)
at android.os.HandlerThread.run(HandlerThread.java:61)
at com.google.android.exoplayer.util.PriorityHandlerThread.run(PriorityHandlerThread.java:40)

Doing some debug, I find out that is trying to get an invalid range from the following URL:
{base_url}/media/dash/SD/video/3/init.mp4,

The MPD file is similar to the examples, but it has an initialization url and a segment url:

<SegmentTemplate initialization="video/3/init.mp4" media="video/3/seg-$Number$.m4f" startNumber="0" timescale="24">

The problem is that instead of download the initialization chunk, and then download each chunk, it's trying to download everything from the initialization chunk using the "Range" header, with an invalid range (for example 600-98000 when the file size is less than that), giving a HTTP 416 error in the connection request.

Is there something I'm missing?

Thanks!.

MPD File:
sd.mpd.txt

@ojw28
Copy link
Contributor

ojw28 commented Feb 19, 2016

That's odd. Are you able to provide the link to the actual mpd, as opposed to just attaching it, so that we can reproduce the issue?

@topolog
Copy link
Author

topolog commented Feb 19, 2016

Well, I can't disclose the URL because it's from a private server provided by a client. But maybe I can upload it to another server... would it help?

I been trying to debug and changed some clases, but with no luck. I'm stuck with this error. Let me know if you need something else, apart from the URL. I would appreciate much your help.

Thanks!

@ojw28
Copy link
Contributor

ojw28 commented Feb 19, 2016

We'll need a working URL to debug the issue. Whether it's the original one or a copy doesn't matter, but the media needs to exist as well as the mpd. You can email a link to dev.exoplayer@gmail.com if you'd rather do that than post one here. Thanks!

@topolog
Copy link
Author

topolog commented Feb 19, 2016

I just send you an email with the URL. Subject: "Data for Issue #1287 ExoPlayer"

@ojw28
Copy link
Contributor

ojw28 commented Feb 19, 2016

The media here is pretty unusual. The player's doing what it's doing because the initialization chunk contains a sidx boxes (an index of the chunks that among other things specifies each chunk's offset and length). This is unusual. There's no value in the sidx boxes given the mpd is listing the chunks using a SegmentTimeline, and the range offsets don't apply. The player gets confused, tries to use the sidx index rather than the mpd, and playback fails. ExoPlayer should probably prefer to use the mpd in this case; I'll have a think about that. Although on your side, unless there's a good reason to keep them, you might want to consider removing the sidx boxes from your initialization segments, which should fix the issue for you.

As an additional point, it appears that this content is DRM protected beyond ~10s. I would expect the mpd to include ContentProtection elements to indicate this.

@topolog
Copy link
Author

topolog commented Feb 20, 2016

So I got it working. As you recommend, changed the code to ignore the sidx boxes:

In FragmentedMp4Extractor, changed (for now) the function onLeafAtomRead ilke this:

private void onLeafAtomRead(LeafAtom leaf, long inputPosition) throws ParserException {
    if (!containerAtoms.isEmpty()) {
      containerAtoms.peek().add(leaf);
    }
    /*
    else if (leaf.type == Atom.TYPE_sidx) {
      ChunkIndex segmentIndex = parseSidx(leaf.data, inputPosition);
      extractorOutput.seekMap(segmentIndex);
      haveOutputSeekMap = true;
    }
    */
  }

I'll notify the content provider about this to see if they can change it. Regarding the DRM protection, you are right, I had to change the demo app so it uses DrmSessionManager, that's another thing I have to discuss. To get it working I also added the Widevine proxy.

Anyway, thanks for the help and the rapid response. I'll keep an eye on the code if you decide to change the player so it uses the mpd data instead of the sidx boxes in the init chunk.

@ojw28 ojw28 added the bug label Feb 22, 2016
ojw28 added a commit that referenced this issue Feb 22, 2016
@ojw28
Copy link
Contributor

ojw28 commented Feb 22, 2016

The change above removes the need for you to comment out sidx box parsing in the extractor.

@ojw28 ojw28 closed this as completed Feb 22, 2016
ojw28 added a commit that referenced this issue Jun 15, 2016
@google google locked and limited conversation to collaborators Jun 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants