mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-03-28 11:55:39 +00:00
Update header levels
This commit is contained in:
parent
cfb86b8c52
commit
8f452e156c
2 changed files with 23 additions and 23 deletions
|
@ -1,6 +1,6 @@
|
|||
# Android tutorial 4: A basic media player
|
||||
|
||||
### Goal
|
||||
## Goal
|
||||
|
||||
![screenshot]
|
||||
|
||||
|
@ -19,7 +19,7 @@ It also uses the knowledge gathered in the [](sdk-basic-tutorials.md) regarding:
|
|||
- How to use `playbin` to play any kind of media
|
||||
- How to handle network resilience problems
|
||||
|
||||
### Introduction
|
||||
## Introduction
|
||||
|
||||
From the previous tutorials, we already have almost all necessary pieces
|
||||
to build a media player. The most complex part is assembling a pipeline
|
||||
|
@ -41,7 +41,7 @@ the video sink is not forced to draw black borders around the clip.
|
|||
media content. You can still force the video surface to have a specific
|
||||
size if you really want to.
|
||||
|
||||
### A basic media player \[Java code\]
|
||||
## A basic media player \[Java code\]
|
||||
|
||||
**src/com/gst\_sdk\_tutorials/tutorial\_4/Tutorial4.java**
|
||||
|
||||
|
@ -298,7 +298,7 @@ public class Tutorial4 extends Activity implements SurfaceHolder.Callback, OnSee
|
|||
}
|
||||
```
|
||||
|
||||
#### Supporting arbitrary media URIs
|
||||
### Supporting arbitrary media URIs
|
||||
|
||||
The C code provides the `nativeSetUri()` method so we can indicate the
|
||||
URI of the media to play. Since `playbin` will be taking care of
|
||||
|
@ -319,7 +319,7 @@ private void setMediaUri() {
|
|||
We call `setMediaUri()` in the `onGStreamerInitialized()` callback, once
|
||||
the pipeline is ready to accept commands.
|
||||
|
||||
#### Reporting media size
|
||||
### Reporting media size
|
||||
|
||||
Every time the size of the media changes (which could happen mid-stream,
|
||||
for some kind of streams), or when it is first detected, C code calls
|
||||
|
@ -349,7 +349,7 @@ the UI must be called from the main thread, and we are now in a
|
|||
callback from some GStreamer internal thread. Hence, the usage of
|
||||
[runOnUiThread()](http://developer.android.com/reference/android/app/Activity.html#runOnUiThread\(java.lang.Runnable\)).
|
||||
|
||||
#### Refreshing the Seek Bar
|
||||
### Refreshing the Seek Bar
|
||||
|
||||
[](sdk-basic-tutorial-toolkit-integration.md)
|
||||
has already shown how to implement a [Seek
|
||||
|
@ -404,7 +404,7 @@ private void updateTimeWidget () {
|
|||
}
|
||||
```
|
||||
|
||||
#### Seeking with the Seek Bar
|
||||
### Seeking with the Seek Bar
|
||||
|
||||
To perform the second function of the [Seek
|
||||
Bar](http://developer.android.com/reference/android/widget/SeekBar.html) (allowing
|
||||
|
@ -479,7 +479,7 @@ desired playing state.
|
|||
This concludes the User interface part of this tutorial. Let’s review
|
||||
now the under-the-hood C code that allows this to work.
|
||||
|
||||
### A basic media player \[C code\]
|
||||
## A basic media player \[C code\]
|
||||
|
||||
**jni/tutorial-4.c**
|
||||
|
||||
|
@ -1054,7 +1054,7 @@ jint JNI_OnLoad(JavaVM *vm, void *reserved) {
|
|||
}
|
||||
```
|
||||
|
||||
#### Supporting arbitrary media URIs
|
||||
### Supporting arbitrary media URIs
|
||||
|
||||
Java code will call `gst_native_set_uri()` whenever it wants to change
|
||||
the playing URI (in this tutorial the URI never changes, but it could):
|
||||
|
@ -1100,7 +1100,7 @@ not. Live sources must not use buffering (otherwise latency is
|
|||
introduced which is inacceptable for them), so we keep track of this
|
||||
information in the `is_live` variable.
|
||||
|
||||
#### Reporting media size
|
||||
### Reporting media size
|
||||
|
||||
Some codecs allow the media size (width and height of the video) to
|
||||
change during playback. For simplicity, this tutorial assumes that they
|
||||
|
@ -1152,7 +1152,7 @@ The helper functions `gst_video_format_parse_caps()` and
|
|||
manageable integers, which we pass to Java through
|
||||
its `onMediaSizeChanged()` callback.
|
||||
|
||||
#### Refreshing the Seek Bar
|
||||
### Refreshing the Seek Bar
|
||||
|
||||
To keep the UI updated, a GLib timer is installed in the
|
||||
`app_function()` that fires 4 times per second (or every 250ms), right
|
||||
|
@ -1201,7 +1201,7 @@ Bear in mind that all time-related measures returned by GStreamer are in
|
|||
nanoseconds, whereas, for simplicity, we decided to make the UI code
|
||||
work in milliseconds.
|
||||
|
||||
#### Seeking with the Seek Bar
|
||||
### Seeking with the Seek Bar
|
||||
|
||||
The Java UI code already takes care of most of the complexity of seeking
|
||||
by dragging the thumb of the Seek Bar. From C code, we just need to
|
||||
|
@ -1215,7 +1215,7 @@ Bar can generate a very high number of seek requests in a short period
|
|||
of time, which is visually useless and will impair responsiveness. Let’s
|
||||
see how to overcome these problems.
|
||||
|
||||
##### Delayed seeks
|
||||
#### Delayed seeks
|
||||
|
||||
In
|
||||
`gst_native_set_position()`:
|
||||
|
@ -1255,7 +1255,7 @@ Once the pipeline moves from the READY to the PAUSED state, we check if
|
|||
there is a pending seek operation and execute it. The
|
||||
`desired_position` variable is reset inside `execute_seek()`.
|
||||
|
||||
##### Seek throttling
|
||||
#### Seek throttling
|
||||
|
||||
A seek is potentially a lengthy operation. The demuxer (the element
|
||||
typically in charge of seeking) needs to estimate the appropriate byte
|
||||
|
@ -1331,7 +1331,7 @@ The one-shot timer calls `delayed_seek_cb()`, which simply calls
|
|||
>
|
||||
> This is not a complete solution: the scheduled seek will still be executed, even though a more-recent seek has already been executed that should have cancelled it. However, it is a good tradeoff between functionality and simplicity.
|
||||
|
||||
#### Network resilience
|
||||
### Network resilience
|
||||
|
||||
[](sdk-basic-tutorial-streaming.md) has already
|
||||
shown how to adapt to the variable nature of the network bandwidth by
|
||||
|
@ -1373,7 +1373,7 @@ pipeline, which might be different to the current state, because
|
|||
buffering forces us to go to PAUSED. Once buffering is complete we set
|
||||
the pipeline to the `target_state`.
|
||||
|
||||
### A basic media player \[Android.mk\]
|
||||
## A basic media player \[Android.mk\]
|
||||
|
||||
The only line worth mentioning in the makefile
|
||||
is `GSTREAMER_PLUGINS`:
|
||||
|
@ -1388,7 +1388,7 @@ In which all plugins required for playback are loaded, because it is not
|
|||
known at build time what would be needed for an unspecified URI (again,
|
||||
in this tutorial the URI does not change, but it will in the next one).
|
||||
|
||||
### Conclusion
|
||||
## Conclusion
|
||||
|
||||
This tutorial has shown how to embed a `playbin` pipeline into an
|
||||
Android application. This, effectively, turns such application into a
|
||||
|
|
|
@ -104,11 +104,11 @@ and on an aggregate basis only.
|
|||
|
||||
## Frequently Asked Questions
|
||||
|
||||
##### What licenses are there?
|
||||
#### What licenses are there?
|
||||
|
||||
GStreamer binaries containst software under various licenses. See above.
|
||||
|
||||
##### How does this relate to the packaging system?
|
||||
#### How does this relate to the packaging system?
|
||||
|
||||
The packaging is only a more convenient way to install software and
|
||||
decide what's good for you. GStreamer is meant to be modular, making use
|
||||
|
@ -128,7 +128,7 @@ reference, but we cannot guarantee that our selection is 100% correct,
|
|||
so it is up to the user to verify the actual licensing conditions before
|
||||
distributing works that utilize GStreamer.
|
||||
|
||||
##### Can I / must I distribute GStreamer along with my application?
|
||||
#### Can I / must I distribute GStreamer along with my application?
|
||||
|
||||
You surely can. All software is Free/Open Source software, and can be
|
||||
distributed freely. You are not **required** to distribute it. Only,
|
||||
|
@ -142,7 +142,7 @@ entire source code, you might want to include it (or the directories
|
|||
containing the source code) with your application as a safe way to
|
||||
comply with this requirement of the license.
|
||||
|
||||
##### What happens when I modify the GStreamer's source code?
|
||||
#### What happens when I modify the GStreamer's source code?
|
||||
|
||||
You are invited to do so, as the licenses (unless you are dealing with
|
||||
proprietary bits, but in that case you will not find the corresponding
|
||||
|
@ -157,7 +157,7 @@ to fork the code, if at all possible. he Cerbero build system has a
|
|||
containing all of the complete corresponding machine readable source
|
||||
code that you are required to provide.
|
||||
|
||||
##### How does licensing relate to software patents? What about software patents in general?
|
||||
#### How does licensing relate to software patents? What about software patents in general?
|
||||
|
||||
This is a tricky question. We believe software patents should not exist,
|
||||
so that by distributing and using software on a general purpose machine
|
||||
|
@ -185,7 +185,7 @@ This is why GStreamer has taken a modular approach, so that you can use
|
|||
a Free plugins or a proprietary, patent royalty bearing, plugin for a
|
||||
given standard.
|
||||
|
||||
##### What about static vs. dynamic linking and copyleft?
|
||||
#### What about static vs. dynamic linking and copyleft?
|
||||
|
||||
We cannot provide one single answer to that question. Since copyright in
|
||||
software works as copyright in literature, static linking means
|
||||
|
|
Loading…
Reference in a new issue