# GMF-Core Overview

[中文]

GMF-Core is the core framework of ESP-GMF, defining the element, payload, port, data bus, task, and lifecycle state machine. Multimedia algorithms such as decoders, encoders, resamplers, and mixers are integrated into the framework as elements.

This document covers the overall architecture and main objects. For details, see the dedicated chapters: GMF Pipeline and Task Scheduling covers pipeline and task collaboration and scheduling; GMF Elements covers the element lifecycle, capabilities, and methods; Data Flow covers the data flow of payload, port, and IO; Data Bus covers the data bus implementation and flow control; GMF FourCC and System Utilities can be consulted as needed.

Upper-layer applications can use GMF-Core indirectly through encapsulation components such as `esp_audio_simple_player` and `esp_capture`. Direct GMF-Core programming is only required when developing custom elements.

## Component Layers

GMF-Core divides the multimedia processing pipeline into four layers, each addressing a separate concern.

Layer | Module | Responsibilities
--- | --- | ---
Registry Layer | Pool | Centrally registers element and IO templates. At application startup, all available elements are registered once; when building a pipeline, instances are copied by name.
Orchestration Layer | Pipeline, Task | A pipeline connects multiple elements in sequence; a task drives the elements on the pipeline according to defined rules.
Processing Layer | Element | Each element implements three phases: `open` for one-time initialization, `process` for processing a block of data, and `close` for cleanup. Derives into audio, video, and picture subclasses.
Data Layer | Payload, Port, Data Bus | Data flows between elements as payloads. Ports provide read/write interfaces for elements. The data bus handles queuing, buffering, and synchronization below the ports.

            flowchart TB
        subgraph registry ["Registry Layer"]
            Pool["Pool"]
        end

        subgraph orchestrate ["Orchestration Layer"]
            Pipeline["Pipeline"]
            Task["Task"]
            Pipeline -->|"Bind"| Task
        end

        subgraph process ["Processing Layer"]
            ElemA["Element A"] -->|"Payload"| ElemB["Element B"]
        end

        subgraph data ["Data Layer"]
            direction LR
            Port["Port"] --> DataBus["Data Bus"] --> Payload["Payload"]
        end

        Pool -->|"Instantiate"| Pipeline
        Pipeline -->|"Link"| ElemA
        Task -->|"Drive"| ElemA
        ElemA -->|"Read/Write"| Port

This layered design allows each part to be extended independently. Adding a new audio algorithm requires only implementing the element interface; building a new playback pipeline only requires selecting elements from the pool and composing them; adjusting data buffering strategy only requires replacing the corresponding data bus. The three types of work are decoupled and can be developed and adjusted independently.

## Basic Object Model

All objects in the framework that can be registered, copied, or destroyed inherit from a common base class `esp_gmf_obj_t`. The base class handles no business logic; it only defines how objects are created (`new_obj` function pointer), how they are destroyed (`del_obj` function pointer), and provides a string tag `tag` and a configuration data pointer `cfg`.

There are three direct derived classes: `esp_gmf_io_t` represents an IO object (such as a file IO or I2S IO), `esp_gmf_task_t` represents a task, and `esp_gmf_element_t` represents an element. Elements are further derived into audio, video, and picture subclasses, each carrying the corresponding format information.

            classDiagram
        direction TB

        class esp_gmf_obj_t
        class esp_gmf_io_t
        class esp_gmf_task_t
        class esp_gmf_element_t
        class esp_gmf_audio_element_t
        class esp_gmf_video_element_t
        class esp_gmf_pic_element_t

        esp_gmf_obj_t <|-- esp_gmf_io_t
        esp_gmf_obj_t <|-- esp_gmf_task_t
        esp_gmf_obj_t <|-- esp_gmf_element_t
        esp_gmf_element_t <|-- esp_gmf_audio_element_t
        esp_gmf_element_t <|-- esp_gmf_video_element_t
        esp_gmf_element_t <|-- esp_gmf_pic_element_t

The unified inheritance allows the pool to maintain a single `esp_gmf_obj_t` * linked list that stores templates of any type. When needed, `esp_gmf_obj_dupl()` copies a fresh instance from a template. The “register template first, instantiate on demand” pattern in the framework relies on this unified object interface.

## Main Objects

### Pipeline

A pipeline is the task orchestrator. It connects several elements in sequence and exposes control interfaces such as `run`, `stop`, `pause`, `resume`, `reset`, and `seek` as a whole. From the application’s perspective, operating on a single pipeline object is enough to start, pause, or stop the entire processing flow.

A pipeline also handles three types of internal coordination: opening and closing the head and tail IOs (file, I2S, etc.), forwarding format information reported by elements to downstream elements, and coordinating cleanup for all elements when an error or end-of-stream occurs. The pipeline itself does not execute element code; actual execution is done by the bound task. For construction and control details, see GMF Pipeline and Task Scheduling.

### Task

A task is the executor of the processing flow, essentially a runtime unit encapsulated by the framework. A task maintains a job list and calls each element’s `open`, `process`, and `close` in the defined order. Each pipeline binds one task at runtime in a one-to-one relationship.

The pipeline and task are divided into two objects with different responsibilities. The pipeline describes the “connection topology,” while the task describes the “runtime resources” (stack size, priority, CPU core). The same pipeline can be bound to tasks with different configurations, and the same task template can be reused repeatedly. For the scheduling model, see GMF Pipeline and Task Scheduling.

### Element

An element is the concrete work executor; each element corresponds to one specific task (such as MP3 decoding, resampling, or mixing). Each element implements three fixed-phase callback functions: `open` for one-time initialization, `process` for processing a block of data, and `close` for releasing resources. The task first calls open, then repeatedly calls process during operation according to the job configuration (commonly `ESP_GMF_JOB_TIMES_INFINITE`), until the element returns done, an error occurs, or a stop request is received, and finally calls close.

Based on the type of data processed, elements derive into three subclasses: audio (`esp_gmf_audio_element_t`), video (`esp_gmf_video_element_t`), and picture (`esp_gmf_pic_element_t`), each carrying format information such as sample rate/channels, resolution/frame rate, or width/height. For lifecycle details, interface implementation, and custom element templates, see GMF Elements.

### Payload

A payload is the unified container for data flowing between elements. Whether it is a decoded PCM frame, a compressed H.264 segment, or an HTTP chunk, it is all carried as `esp_gmf_payload_t` inside the framework. This structure contains a data buffer pointer, total buffer length, valid data length, end-of-stream flag, timestamp, and other fields.

A unified payload allows the framework to perform data transfer, buffering, and thread synchronization without depending on specific media types, avoiding each element from defining its own data structures. For payload fields, lifecycle, and ownership rules, see Data Flow.

### Port

A port is the data read/write interface exposed by an element. Each element has one input port and one output port, connected to upstream and downstream respectively. A port does not store data itself; it only provides the interface to “acquire a payload to read or write.” The actual data resides in the underlying data bus.

Ports use an acquire-release access protocol: when an element needs to read data, it first acquires a payload, then releases it when done; when writing data, it first acquires an empty payload, fills it, then releases it to submit to downstream. This pattern defines data ownership boundaries, allowing elements to safely read and write payloads between calls without worrying about thread synchronization. For the detailed protocol, see Data Flow.

### Data Bus

A data bus is the actual data queue beneath a port, responsible for buffer allocation, cross-thread synchronization, and queuing payloads between producers and consumers. GMF-Core provides four implementations, targeting different copy strategies, blocking semantics, and data granularity. A port binds to one of them at creation time; the framework encapsulates the underlying differences, and element code uses only the unified port interface.

For the trade-offs, selection guide, and flow control interfaces of the four implementations, see Data Bus.

### Pool

The pool is a template library for elements and IOs. At application startup, all supported elements (MP3 decoder, resampler, file IO, I2S IO, etc.) are registered to the pool at once; when building a pipeline, the application only provides a list of names, and the pool copies instances from templates and chains them in order.

Separating “registered templates” from “used instances” allows the same set of elements to be composed into many different pipelines. The system can have dozens of pipeline combinations simultaneously; using the pool requires registering a template only once, rather than writing a separate build process for each combination. In addition to looking up by name, the pool can automatically select a matching IO by scoring URLs (for example, `http://` matches the HTTP IO and `file://` matches the file IO), making it easy for upper-layer applications to switch data sources as needed. For usage, see GMF Pipeline and Task Scheduling.

## Lifecycle States

The pipeline and task share a common lifecycle state enumeration `esp_gmf_event_state_t`. Applications register event callbacks to be notified of every state transition.

State | Value | Meaning
--- | --- | ---
`ESP_GMF_EVENT_STATE_NONE` | 0 | Object just created, not yet initialized
`ESP_GMF_EVENT_STATE_INITIALIZED` | 1 | Init complete, ready to start
`ESP_GMF_EVENT_STATE_OPENING` | 2 | Element open phase in progress
`ESP_GMF_EVENT_STATE_RUNNING` | 3 | Cyclic process phase being scheduled
`ESP_GMF_EVENT_STATE_PAUSED` | 4 | Paused, context preserved
`ESP_GMF_EVENT_STATE_STOPPED` | 5 | User-initiated stop, close in progress
`ESP_GMF_EVENT_STATE_FINISHED` | 6 | Data ended naturally (triggered by `is_done` in payload)
`ESP_GMF_EVENT_STATE_ERROR` | 7 | A job returned failure, cleanup in progress

            stateDiagram-v2
        direction TB

        [*] --> NONE
        NONE --> INITIALIZED : init
        INITIALIZED --> OPENING : run
        OPENING --> RUNNING : opens done
        OPENING --> ERROR : open fail
        RUNNING --> PAUSED : pause
        PAUSED --> RUNNING : resume
        RUNNING --> STOPPED : stop
        RUNNING --> FINISHED : is_done
        RUNNING --> ERROR : proc fail
        STOPPED --> INITIALIZED : reset
        FINISHED --> INITIALIZED : reset
        ERROR --> INITIALIZED : reset

The three terminal states `STOPPED`, `FINISHED`, and `ERROR` can all return to `INITIALIZED` via `reset`, meaning the same pipeline can be run and stopped repeatedly without being rebuilt.

There is no independent “abort state” in the enumeration. When an element’s `process` returns `ESP_GMF_JOB_ERR_ABORT`, the task by default follows the `STOPPED` path to complete cleanup. If the application registers a strategy function via `esp_gmf_task_set_strategy_func`, it can redirect abort to the `RESET` path, allowing the pipeline to automatically return to `INITIALIZED`. For the detailed behavior of the abort flow, see GMF Pipeline and Task Scheduling.

## Event Types

Events are carried by `esp_gmf_event_pkt_t` and are divided into three categories:

- State Change Events (CHANGE_STATE): Reported by the task to inform the application of the current lifecycle phase of the pipeline. User code can use this event to update the UI or trigger the next operation.

- Format Info Events (REPORT_INFO): Reported by an element to inform the framework of the format it has parsed (for example, an MP3 decoder reports sample rate and channel count after reading the file header). When the pipeline receives this event, it writes the format information into downstream dependent elements and registers the open/process jobs for those elements.

- Load Job Events (LOADING_JOB): Emitted when an element needs to re-register a job. When the pipeline receives this, it updates the task’s job list. User code does not handle this event directly.

Events form a bidirectional flow within the pipeline: the task reports state changes to the pipeline, and the pipeline forwards them to user callbacks; elements report format information to the pipeline, and the pipeline writes it into downstream dependent elements and registers the corresponding jobs.

## Typical Application Topologies

The following topologies demonstrate the composition capabilities of pipelines. Simple scenarios require only one pipeline; complex scenarios use multiple cascaded pipelines to share the workload.

### Single-Channel Decode and Playback

A file IO serves as the pipeline’s IN, an I2S IO serves as OUT, with a decoder and resampler chained in between, all driven by one task. This structure is suitable for local music playback applications.

            flowchart LR
        File(("File")) --> Dec["Decoder"]
        Dec --> Rs["Resample"]
        Rs --> I2S(("I2S"))

### Callback-Driven without IO

IN/OUT are not connected to IO objects; instead, user code registers callbacks via `esp_gmf_port_set_cb` to provide or receive data. This is suitable for pipelines connected to Bluetooth audio, HTTP streams, or custom protocol stacks, where the external layer only needs to handle data input and output within the callbacks.

            flowchart LR
        InCb(("Input<br/>Callback")) --> Dec["Decoder"]
        Dec --> Rs["Resample"]
        Rs --> OutCb(("Output<br/>Callback"))

### Bridging Two Pipelines with a Ringbuffer

When the processing rates of upstream and downstream differ significantly, divide the flow into two independent pipelines with a ringbuffer as the intermediate buffer. Each segment has its own task, which can be configured with different stack sizes and priorities: the first segment uses a larger stack for MP3 decoding, while the second uses a smaller stack for output scheduling.

            flowchart LR
        subgraph p1 ["Pipeline 1"]
            File(("File"))
            Dec["MP3<br/>Decoder"]
        end
        subgraph p2 ["Pipeline 2"]
            Rs["Resampler"]
            Out(("Output"))
        end
        File --> Dec
        Dec -->|"ringbuffer"| Rs
        Rs --> Out

### Multi-Input Mixing

Two upstream pipelines decode different audio sources and feed them into a mixing pipeline that combines and outputs the result. A typical application is overlaying navigation voice on background music: the main pipeline continuously plays music, and when navigation is triggered, a prompt audio pipeline is started; both PCM streams are sent to a mixer and written to I2S. Stopping the prompt audio only requires stopping the corresponding pipeline, leaving the main playback unaffected.

            flowchart LR
        subgraph p1 ["Background Music"]
            F1(("File"))
            D1["MP3"]
        end
        subgraph p2 ["Prompt Audio"]
            H1(("HTTP"))
            D2["MP3"]
        end
        subgraph pm ["Mix Output"]
            Mix["Mixer"]
            Out(("I2S"))
        end
        F1 --> D1
        D1 --> Mix
        H1 --> D2
        D2 --> Mix
        Mix --> Out

### One-to-Many Split

A copier element copies one input stream into multiple outputs. For example, while playing music, the same audio is sent to an AEC algorithm as the echo reference signal: the music played by the speaker is picked up by the microphone, and AEC needs the original music as a reference to cancel the echo from the microphone signal.

            flowchart LR
        subgraph p1 ["Decode"]
            F(("File"))
            Dec["Decoder"]
            Cp{"Copier"}
        end
        subgraph p2 ["Playback"]
            R1["Resample"]
            I2S(("I2S"))
        end
        subgraph p3 ["AEC Reference"]
            R2["Resample"]
            Rec(("Recorder"))
        end
        F --> Dec
        Dec --> Cp
        Cp --> R1
        R1 --> I2S
        Cp --> R2
        R2 --> Rec

## Component Directory

    gmf_core/
    ├── include/          Public header files
    ├── src/              Base types and framework implementation
    ├── data_bus/         Four data bus implementations
    ├── oal/              OS abstraction layer
    ├── helpers/          URI parsing and FourCC validation utilities
    ├── docs/             Doxygen configuration
    └── test_apps/        Unit tests and integration test cases

GMF-Core is built on top of ESP-IDF and depends on event groups, atomic operations, `esp_common`, `log`, and other system capabilities. It has no dependencies on any audio or video algorithm library: all decoders, encoders, and filters are provided as elements by upper-layer components (such as `gmf_audio` and `gmf_video`).

## API Reference

Base types and object hierarchy covered in this document:

- `esp_gmf_obj.h`: Object base class

- `esp_gmf_event.h`: State enumeration and event packets

- `esp_gmf_err.h`: Error code definitions

- `esp_gmf_info_file.h`: File information structure

FourCC macro definitions are detailed in GMF FourCC and are not repeated here.

### Header File

- gmf_core/include/esp_gmf_obj.h

### Functions

esp_gmf_err_t esp_gmf_obj_dupl(esp_gmf_obj_handle_t old_obj, esp_gmf_obj_handle_t *new_obj)

  Duplicate a GMF object.

  Parameters:

    - old_obj – [in] Handle of the old object to duplicate

    - new_obj – [out] Pointer to store the handle of the new duplicated object

  Returns:

    - ESP_GMF_ERR_OK On success (new_obj contains the duplicated object handle)

    - ESP_GMF_ERR_INVALID_ARG If old_obj is invalid or new_obj is NULL

    - ESP_GMF_ERR_MEMORY_LACK Insufficient memory for operation

esp_gmf_err_t esp_gmf_obj_new(esp_gmf_obj_handle_t old_obj, void *cfg, esp_gmf_obj_handle_t *new_obj)

  Create a new GMF object based on an existing object with additional configuration.

  Parameters:

    - old_obj – [in] Handle of the existing object to use as a base

    - cfg – [in] Pointer to the additional configuration for the new object

    - new_obj – [out] Pointer to store the handle of the newly created object

  Returns:

    - ESP_GMF_ERR_OK On success

    - ESP_GMF_ERR_INVALID_ARG Invalid argument provided

    - ESP_GMF_ERR_MEMORY_LACK Insufficient memory for operation

esp_gmf_err_t esp_gmf_obj_delete(esp_gmf_obj_handle_t obj)

  Delete a GMF object.

  Parameters:

    obj – [in] Handle of the object to delete

  Returns:

    - ESP_GMF_ERR_OK On success

    - ESP_GMF_ERR_INVALID_ARG Invalid argument provided

esp_gmf_err_t esp_gmf_obj_set_config(esp_gmf_obj_handle_t obj, void *cfg, int cfg_size)

  Set configuration for a GMF object.

  Parameters:

    - obj – [in] Handle of the object to set the configuration for

    - cfg – [in] Pointer to the configuration data

    - cfg_size – [in] Size of the configuration data

  Returns:

    - ESP_GMF_ERR_OK On success

    - ESP_GMF_ERR_INVALID_ARG Invalid argument provided

    - ESP_GMF_ERR_MEMORY_LACK Insufficient memory for operation

esp_gmf_err_t esp_gmf_obj_set_tag(esp_gmf_obj_handle_t obj, const char *tag)

  Set a tag for a GMF object.

  Parameters:

    - obj – [in] Handle of the object to set the tag for

    - tag – [in] Pointer to the tag string

  Returns:

    - ESP_GMF_ERR_OK On success

    - ESP_GMF_ERR_INVALID_ARG Invalid argument provided

    - ESP_GMF_ERR_MEMORY_LACK Insufficient memory for operation

esp_gmf_err_t esp_gmf_obj_get_tag(esp_gmf_obj_handle_t obj, char **tag)

  Get the tag associated with a GMF object.

  Parameters:

    - obj – [in] Handle of the object to get the tag from

    - tag – [out] Pointer to store the tag string

  Returns:

    - ESP_GMF_ERR_OK On success

    - ESP_GMF_ERR_INVALID_ARG Invalid argument provided

### Structures

struct esp_gmf_obj_

  GMF object structure.

          This structure represents a generic GMF object with basic functionalities,
          such as creating a new object, deleting an object, and storing object-related
          information.

  Public Members

  struct esp_gmf_obj_ *prev

    Pointer to the previous GMF object in the list

  struct esp_gmf_obj_ *next

    Pointer to the next GMF object in the list

  esp_gmf_err_t (*new_obj)(void *cfg, esp_gmf_obj_handle_t *new_obj)

    Function pointer to create a new object

  esp_gmf_err_t (*del_obj)(esp_gmf_obj_handle_t obj)

    Function pointer to delete an object

  const char *tag

    Pointer to a tag or identifier associated with the object

  void *cfg

    Pointer to the configuration data for the object

### Macros

ESP_GMF_TAG_MAX_LEN

OBJ_GET_TAG(x)

OBJ_GET_CFG(x)

### Type Definitions

typedef void *esp_gmf_obj_handle_t

typedef struct esp_gmf_obj_ esp_gmf_obj_t

  GMF object structure.

          This structure represents a generic GMF object with basic functionalities,
          such as creating a new object, deleting an object, and storing object-related
          information.

### Header File

- gmf_core/include/esp_gmf_event.h

### Functions

const char *esp_gmf_event_get_state_str(esp_gmf_event_state_t st)

  Get the string representation of a GMF event state.

  Parameters:

    st – [in] GMF event state

  Returns:

    - NULL Out of range

    - Others Const String representation of the state

### Structures

struct esp_gmf_event_pkt_t

  Packet containing information about a GMF event.

  Public Members

  void *from

    Pointer to the object sending the event

  esp_gmf_event_type_t type

    Type of the event

  int sub

    Additional data or subtype

  void *payload

    Pointer to the payload data

  int payload_size

    Size of the payload data

struct _esp_gmf_event_item_

  Structure representing an item in the event queue.

  Public Members

  struct _esp_gmf_event_item_ *next

    Pointer to the next event item

  esp_gmf_event_cb cb

    Callback function for the event

  void *ctx

    Context pointer

### Type Definitions

typedef esp_gmf_err_t (*esp_gmf_event_cb)(esp_gmf_event_pkt_t *pkt, void *ctx)

  Callback function for handling GMF events.

  Param pkt:

    [in] Pointer to the packet containing information about the event

  Param ctx:

    [in] Context pointer

  Return:

    - esp_gmf_err_t error code Indicating success or failure

typedef struct _esp_gmf_event_item_ esp_gmf_event_item_t

  Structure representing an item in the event queue.

### Enumerations

enum esp_gmf_event_type_t

  Type of events in GMF.

  Values:

  enumerator ESP_GMF_EVT_TYPE_LOADING_JOB

    Loading job event

  enumerator ESP_GMF_EVT_TYPE_CHANGE_STATE

    State change event

  enumerator ESP_GMF_EVT_TYPE_REPORT_INFO

    Information reporting event

enum esp_gmf_event_state_t

  States of GMF events.

  Values:

  enumerator ESP_GMF_EVENT_STATE_NONE

    No specific state

  enumerator ESP_GMF_EVENT_STATE_INITIALIZED

    Initialized state

  enumerator ESP_GMF_EVENT_STATE_OPENING

    Opening state

  enumerator ESP_GMF_EVENT_STATE_RUNNING

    Running state

  enumerator ESP_GMF_EVENT_STATE_PAUSED

    Paused state

  enumerator ESP_GMF_EVENT_STATE_STOPPED

    Stopped state

  enumerator ESP_GMF_EVENT_STATE_FINISHED

    Finished state

  enumerator ESP_GMF_EVENT_STATE_ERROR

    Error state

### Header File

- gmf_core/include/esp_gmf_err.h

### Macros

ESP_GMF_ERR_BASE

ESP_GMF_ERR_CORE_BASE

ESP_GMF_CHECK(TAG, a, action, msg)

ESP_GMF_RET_ON_FAIL(TAG, a, action, msg)

ESP_GMF_RET_ON_NOT_OK(TAG, a, action, msg)

ESP_GMF_RET_ON_ERROR(log_tag, a, action, format, ...)

ESP_GMF_MEM_VERIFY(TAG, a, action, name, size)

ESP_GMF_MEM_CHECK(TAG, a, action)

ESP_GMF_NULL_CHECK(TAG, a, action)

### Enumerations

enum esp_gmf_err_io_t

  Error codes for GMF IO operations.

  Values:

  enumerator ESP_GMF_IO_OK

    Operation successful

  enumerator ESP_GMF_IO_FAIL

    Operation failed

  enumerator ESP_GMF_IO_ABORT

    Operation aborted

  enumerator ESP_GMF_IO_TIMEOUT

    Operation timed out

enum esp_gmf_err_t

  Values:

  enumerator ESP_GMF_ERR_OK
  enumerator ESP_GMF_ERR_FAIL
  enumerator ESP_GMF_ERR_ABORT
  enumerator ESP_GMF_ERR_TIMEOUT
  enumerator ESP_GMF_ERR_UNKNOWN
  enumerator ESP_GMF_ERR_ALREADY_EXISTS
  enumerator ESP_GMF_ERR_MEMORY_LACK
  enumerator ESP_GMF_ERR_INVALID_URI
  enumerator ESP_GMF_ERR_INVALID_PATH
  enumerator ESP_GMF_ERR_INVALID_ARG
  enumerator ESP_GMF_ERR_INVALID_STATE
  enumerator ESP_GMF_ERR_OUT_OF_RANGE
  enumerator ESP_GMF_ERR_NOT_READY
  enumerator ESP_GMF_ERR_NOT_SUPPORT
  enumerator ESP_GMF_ERR_NOT_FOUND
  enumerator ESP_GMF_ERR_NOT_ENOUGH
  enumerator ESP_GMF_ERR_NO_DATA

### Header File

- gmf_core/include/esp_gmf_info_file.h

### Functions

static inline esp_gmf_err_t esp_gmf_info_file_init(esp_gmf_info_file_t *handle)

  Initialize the file information by given handle.

  Parameters:

    handle – [in] Pointer to the file information handle to initialize

  Returns:

    - ESP_GMF_ERR_OK Success

    - ESP_GMF_ERR_INVALID_ARG Invalid configuration provided

static inline esp_gmf_err_t esp_gmf_info_file_deinit(esp_gmf_info_file_t *handle)

  Deinitialize the file information by given handle.

  Parameters:

    handle – [in] Pointer to the file information handle to deinitialize

  Returns:

    - ESP_GMF_ERR_OK Success

    - ESP_GMF_ERR_INVALID_ARG Invalid configuration provided

static inline esp_gmf_err_t esp_gmf_info_file_update_pos(esp_gmf_info_file_t *handle, uint64_t byte_pos)

  Update the file position of the specific handle.

  Parameters:

    - handle – [in] Pointer to the file information handle

    - byte_pos – [in] Byte position to update by

  Returns:

    - ESP_GMF_ERR_OK Success

    - ESP_GMF_ERR_INVALID_ARG Invalid configuration provided

static inline esp_gmf_err_t esp_gmf_info_file_set_pos(esp_gmf_info_file_t *handle, uint64_t byte_pos)

  Set the file position of the specific handle.

  Parameters:

    - handle – [in] Pointer to the file information handle

    - byte_pos – [in] Byte position to set

  Returns:

    - ESP_GMF_ERR_OK Success

    - ESP_GMF_ERR_INVALID_ARG Invalid configuration provided

static inline esp_gmf_err_t esp_gmf_info_file_get_pos(esp_gmf_info_file_t *handle, uint64_t *byte_pos)

  Get the position of the specific handle.

  Parameters:

    - handle – [in] Pointer to the file information handle

    - byte_pos – [out] Pointer to store the byte position

  Returns:

    - ESP_GMF_ERR_OK Success

    - ESP_GMF_ERR_INVALID_ARG Invalid configuration provided

static inline esp_gmf_err_t esp_gmf_info_file_set_size(esp_gmf_info_file_t *handle, uint64_t total_size)

  Set the total size of the specific handle.

  Parameters:

    - handle – [in] Pointer to the file information handle

    - total_size – [in] Total size to set

  Returns:

    - ESP_GMF_ERR_OK Success

    - ESP_GMF_ERR_INVALID_ARG Invalid configuration provided

static inline esp_gmf_err_t esp_gmf_info_file_get_size(esp_gmf_info_file_t *handle, uint64_t *total_size)

  Get the total size of the specific handle.

  Parameters:

    - handle – [in] Pointer to the file information handle

    - total_size – [out] Pointer to store the total size

  Returns:

    - ESP_GMF_ERR_OK Success

    - ESP_GMF_ERR_INVALID_ARG Invalid configuration provided

static inline esp_gmf_err_t esp_gmf_info_file_set_uri(esp_gmf_info_file_t *handle, const char *uri)

  Set the URI of the specific handle.

  Parameters:

    - handle – [in] Pointer to the file information handle

    - uri – [in] URI to set

  Returns:

    - ESP_GMF_ERR_OK Success

    - ESP_GMF_ERR_MEMORY_LACK Memory allocation failed

    - ESP_GMF_ERR_INVALID_ARG Invalid configuration provided

static inline esp_gmf_err_t esp_gmf_info_file_get_uri(esp_gmf_info_file_t *handle, char **uri)

  Get the URI of the specific handle.

  Parameters:

    - handle – [in] Pointer to the file information handle

    - uri – [out] Pointer to store the URI

  Returns:

    - ESP_GMF_ERR_OK Success

    - ESP_GMF_ERR_INVALID_ARG Invalid configuration provided

Was this page helpful?

- Thank you! We received your feedback.
- If you have any comments, fill in Espressif Documentation Feedback Form.

- We value your feedback.
- Let us know how we can improve this page by filling in Espressif Documentation Feedback Form.