Audio Only Mode - Less Data Usage - Not about Download/Background Play

[desmonk]

Checklist

• I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
• I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• This issue contains only one feature request. I will open one issue for every feature I want to request.

Describe the feature you want

How about an option to play a video when needed in an audio only mode without downloading? This will help users to play many videos they want to play using least amount of data!

Also, a Background Play can be streamed only as audio as it's a background video already playing as an audio track.

Is your feature request related to a problem? Please describe it

This is kind of an issue if you look it that way. Right now, Background Play still uses a video as audio to function. Here though, only audio is streamed whether in background or not.

Additional context

I don't have any for now.

How will you/everyone benefit from this feature?

Saving data usage. One byte at a time!
Users will grately benefit if they can stream any video as just audio and save data. Same goes for a background video which only needs an audio stream.

[avently]

Right now, Background Play still uses a video as audio to function

It's false. Do you have any proofs?

[defini-tiv]

@desmonk I'm not sure about understanding you correctly, but as far as i know, there is this Option already.
If you tap on the headphones-symbol under a video or just select it in the context-menu it will just stream the audio.

[triallax]

@defini-tiv what you want is already the case. You can read that here: "Save mobile data volume (we only download the audio)."

[desmonk]

Thank you everyone for responses. What I meant is an audio only mode whether a user wants to play in background or foreground. Secondly, I raised the case cause I don't know what stream of audio from video is fetched.

Meaning, if we choose to play background play of 1080p video then does the audio stream too comes from resolution? If that's the case then having the ability to select an audio stream that a user prefers say 480p for example, will save data.

Another aspect is an audio only mode option can allow users to choose what audio quality streams they want just as we can select a resolution of a video.

Hope this answer can help you understand more clearly.

[avently]

@desmonk video is not fetched when you're listening in background or with screen off. Only separate audio stream that is the same for every resolution

[desmonk]

But what is the audio stream quality meaning bit rate? Does it fetch from same resolution as a video? Can we select the audio stream quality just as we can with a video?

[triallax]

@desmonk there is an issue to allow choosing audio bitrates: #1059

[desmonk]

Yes, I read that but this is a different case in nature. Right now, I don't know what is the default audio stream used by app. So that's why I opened the case. Later on as we evolve, addition of a custom audio stream too will benefit.

Can you tell us what's the default quality used by app?

[triallax]

NewPipe has no default "audio quality." The stream is provided by YouTube (I don't know about other services), and NewPipe doesn't decide the bitrate. See Tobi's comment below.

[desmonk]

So does it mean that audio is being derived from same resolution video a user has selected?

[triallax]

I'm not an expert on that, so we'll have to wait for someone more knowledgeable.

[desmonk]

I understand and hope this case can be reopened until a valid answer is received.

[triallax]

Well, since this is more of a question than a request, you should probably go and ask on the IRC room. See https://newpipe.net/press/contact/.

[desmonk]

All requests are questions born out of curiosity. I understood that you are too stubborn to admit your own mistake for closing a case without understanding.

Be more open and welcoming.

[triallax]

Sorry, I don't understand. You requested a feature, but the feature is already present, thus I closed this issue. I don't see where I made a mistake. When I say "request," I mean a very specific kind of request, a feature request.

[desmonk]

This is totally on how we see a matter. Yes, it is a feature request. That's all this is. Not a bug. And no the feature to customize an audio stream is not incorporated nor do we know what's the behind the scene playback mechanism.

[triallax]

And no the feature to customize an audio stream is not incorporated

Well, like I stated before, #1059 already exists, and we don't want two open issues for the same feature. In addition, nowhere in your original issue do you say anything about choosing the bitrate.

nor do we know what's the behind the scene playback mechanism.

That's not a feature request; that's a question. And again, that is nowhere to be found in your issue. However, if you want, for example, some explanation inside the app to clarify what's happening behind the scenes, you can open a separate issue for that. Anyway, somebody who knows more about this than me will be coming to answer your questions.

[desmonk]

I admit and agree that I could've been more cleared in issue. Also, the word bitrate is not my primary concern. Concern is the way to play the same way we can play a video as audio. By that I meant customization of audio stream.

I vaguely mentioned this in issue. But you could've waited a bit before closing the case without hearing more. This is not your fault either.

But we're users so we're pretty much not at that level of a developer. So as I said before, be open and welcoming when a user goes to this length to express something that they don't even completely understand how to say in full context.

Also, please don't discriminate between on the basis of a question or a feature request. All feature requests are questions nature and closing cases based on that is unjust.

Anyways, I'll open a new case with better explanation.

[TobiGr]

Short answer: this is a duplicate of #1059
Long answer: NewPipe selects the best audio stream available by default. When the device is on mobile data and the user has set NewPipe to lower the resolution, the stream with the smallest size is chosen.

If you want to read the code instsead of reading my works, have a look here:

NewPipe/app/src/main/java/org/schabi/newpipe/fragments/detail/VideoDetailFragment.java

Lines 1030 to 1049 in 2937606

	private void openBackgroundPlayer(final boolean append) {
	final AudioStream audioStream = currentInfo.getAudioStreams()
	.get(ListHelper.getDefaultAudioFormat(activity, currentInfo.getAudioStreams()));
	final boolean useExternalAudioPlayer = PreferenceManager
	.getDefaultSharedPreferences(activity)
	.getBoolean(activity.getString(R.string.use_external_audio_player_key), false);
	// If a user watched video inside fullscreen mode and than chose another player
	// return to non-fullscreen mode
	if (player != null && player.isFullscreen()) {
	player.toggleFullscreen();
	}
	if (!useExternalAudioPlayer) {
	openNormalBackgroundPlayer(append);
	} else {
	startOnExternalPlayer(activity, currentInfo, audioStream);
	}
	}

NewPipe/app/src/main/java/org/schabi/newpipe/util/ListHelper.java

Lines 94 to 106 in db9f20a

	public static int getDefaultAudioFormat(final Context context,
	final List<AudioStream> audioStreams) {
	final MediaFormat defaultFormat = getDefaultFormat(context,
	R.string.default_audio_format_key, R.string.default_audio_format_value);
	// If the user has chosen to limit resolution to conserve mobile data
	// usage then we should also limit our audio usage.
	if (isLimitingDataUsage(context)) {
	return getMostCompactAudioIndex(defaultFormat, audioStreams);
	} else {
	return getHighestQualityAudioIndex(defaultFormat, audioStreams);
	}
	}

[desmonk]

@TobiGr
Why can't we treat Wi-Fi as metered connection just like mobile data with limitation? Meaning, allow users to choose lower bit rate even when they use a wireless network. Many home networks have limited bandwidth.

[ghost]

@TobiGr
Why can't we treat Wi-Fi as metered connection just like mobile data with limitation?

Are there any updates on this?