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

Allow seamless switching between different audio tracks (e.g. in MKV) #2926

Closed
minhjirachi opened this issue Jun 9, 2017 · 8 comments
Closed
Assignees

Comments

@minhjirachi
Copy link

Hi

I have test the demo application with the local file with multiple audio in the MKV container. The problem I get stuck is the Exoplayer switching audio. It causes 2 or 3 seconds to change to another audio track. So is there anyway to fix this problem?

And with each video, I want it play the seconds track as default. So which class I need to customize for meet that requirement?

Thank you.

@minhjirachi
Copy link
Author

I have tested on the android box and playing the video via Wifi connection. When switching audio, it cause about 5 - 6 seconds. If I connect it via LAN connection, it cause about 2 - 3 seconds to switching audio.

If I seperate the original .mkv video file into 2 files: .mkv (video only) and .mka (audio only). Then the switching function happened is pretty fast. But it can not synchronized to the video.

@minhjirachi
Copy link
Author

I have tested on the previous version v1.5.16. Switching audio is very fast. But I don't know why on this version, switching audio so ***. Till now I really need a helping hand.

@ojw28
Copy link
Contributor

ojw28 commented Jun 12, 2017

There is a trade-off between memory consumption and switching speed. In V1 we buffered all tracks in memory and so could switch to them quickly (although the implementation is technically not quite right). In V2 we buffer only the tracks that are enabled, which saves memory but results in slower switching.

This was done intentionally, although we are revisiting this decision currently. It could be that we revert back to how we did things in V1, although in a technically correct way.

@ojw28 ojw28 added the question label Jun 12, 2017
@minhjirachi
Copy link
Author

Thank you for your answer.

In V1, switching audio function is pretty good (comparing with V2). But it does not have the FFMPEG Audio Decoder. LibVP9 is not work too. I have to modified some classes. Some functions on the V2 do not exist on the old onces. But in V2, both libs work like a charm. But switching audio is not really good as V1.

Memory of android devices were rised up day by day. So please bring it back on next version of Exoplayer.

Thank you.

@ojw28
Copy link
Contributor

ojw28 commented Jun 12, 2017

Memory of android devices were rised up day by day.

Citation needed (particularly for low end Android devices) ;).

@ojw28
Copy link
Contributor

ojw28 commented Jun 24, 2017

We're going to revert back to allowing seamless switching between multiple audio tracks. It's still incorrect to state that memory of Android devices is increasing much, however, particularly at the low end.

@ojw28 ojw28 self-assigned this Jun 24, 2017
@ojw28 ojw28 changed the title How to reduce the time while switching audio? Allow seamless switching between different audio tracks (e.g. in MKV) Jun 24, 2017
ojw28 added a commit that referenced this issue Jun 26, 2017
This change allows you to enable/disable tracks within which
all samples are key-frames without any re-buffering (e.g. audio,
text and metadata). This effectively reverts V2 back to the
behavior in V1, only this time we're doing it properly. []ly
disabling/enabling, or disabling/enabling whilst paused, no longer
cause samples to get "lost" between the source and renderers.

Note it also becomes really easy to support a few other things,
although support is not exposed in this change:

- Enable/disable video tracks without any re-buffering, by
  changing the toKeyframe argument passed to discardTo to true.
- Retain media in the buffer for some time after it's been played
  (e.g. to support a single back-5s-seek efficiently), by
  subtracting the desired back-buffer time from the value that's
  passed to discardTo.

Issue: #2956
Issue: #2926

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160128586
@ojw28
Copy link
Contributor

ojw28 commented Jun 26, 2017

This is fixed in dev-v2.

@ojw28 ojw28 closed this as completed Jun 26, 2017
@minhjirachi
Copy link
Author

Thank you so much. I have waited this good news for a long time.

@google google locked and limited conversation to collaborators Oct 25, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants