Opening huge (<4GB) MKV files fails #641
Labels
Comments
|
Hi. We just added format detection to automatically determine/check the container type. It appears your sample isn't being detected as MKV (or anything else, for that matter). You can debug by:
|
ojw28
added a commit
that referenced
this issue
Jul 22, 2015
|
It's plausible that the change referenced above may have fixed this issue for you, although this is just a guess! Let us know if it's resolved. If it's not, please debug as above and/or provide the front of the file so that we can do so ourselves (the first couple of MBs of the file should be sufficient). |
|
Sent a sample file to your olly.exoplayer@gmail.com address in step 1. Will try to find time for a bit more in-depth debugging. |
|
The sample file you that you sent doesn't appear to fail in the way mentioned at the top of this issue. At least for me, sniffing appears to complete successfully (with or without the recent change ref'd above). Is the sample the exact head of the file for which you encountered the issue? |
|
Yes, definitely. I used dd to get the head of the file. I did some debugging on opening the huge file.. it seems the input length will always stay "0" in |
|
So you're accessing the file through a content:// URI? Presumably the same video will work fine if you access it through a file:// URI, in that case and if that's the problem, since FileDataSource does use File.length? I'm not sure you can use File.length in the content:// URI case. If you look at how available() is implemented for FileInputStream, it should work correctly. Although in this case the file is greater than 2^31 bytes long, and so is larger than what available() can return, which is probably why you see 0. The correct thing to do would probably be to convert 0 to C.LENGTH_UNBOUNDED. |
|
No. I'm passing a |
|
I'm confused. If you're using file:///, why are you using ContentDataSource (as opposed to FileDataSource)? If you use DefaultUriDataSource, which automatically chooses the correct one to use, it should be selecting FileDataSource for file:/// URIs. |
|
Ok true.. and there is the problem. Switching to Thanks for your help. |
|
Well, you should just use DefaultUriDataSource. It auto-selects the correct implementation to delegate to. The specific problem you were hitting is that ContentDataSource (and AssetDataSource), return incorrect length when accessing content larger than 2^31. We should fix that for ContentDataSource. For AssetDataSource it's unnecessary, because anyone shipping an apk larger than 2^31 bytes is crazy (I doubt this is even possible). |
|
By the way, have you made any modifications to get the video playing for this file, or are you seeing audio only playback (this relates loosely to #631). |
|
Right I'm seeing Audio only, however a) I'm I can only test on a engineer build Android device in this hour b) this used to work before. Will check again tomorrow early morning and let you know. |
ojw28
added a commit
that referenced
this issue
Jul 23, 2015
ojw28
added a commit
that referenced
this issue
Jul 23, 2015
|
This should work (with video) on the latest dev. |
|
I'm seeing errors like this now: And when trying again, this error pops up: (a little different trace). That almost looks like an issue with the MTK OMX implementation, except that the standard MediaPlayer works. Also ExoPlayer seems to work well for some of the Matroska test files as before (test2.mkv/test5.mkv play). Per discussion I changed the init of the |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Given I open a file with these specs (via
ffmpeg -i):The file size is 3946839747 bytes.
Then ExoPlayer (85e0bca) will crash like this:
This used to be ok at ExoPlayer 1.4.0 - at least it would start before crashing with something else.
Initialisation code:
@ojw28 do you require a sample clip?
The text was updated successfully, but these errors were encountered: