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.