FFmpeg sends your audio and video to YouTube, but it does not set the public title or description of the live event. Those details belong to the YouTube broadcast, so an automated change needs to update that broadcast through YouTube’s API rather than rely on FFmpeg output metadata.
The practical route is to identify the right broadcast, authorize the YouTube channel, and call liveBroadcasts.update with its title and description. Take care with the request body: YouTube warns that existing properties omitted from an update may be deleted, so read the current reference and preserve fields that must remain.
Separate the feed from the event details
A YouTube Live setup has two related resources. The liveStream represents the feed being delivered to YouTube; the liveBroadcast represents the event and its corresponding video. A broadcast is associated with a stream, but the two resources have different jobs. The public event title and description are properties of the broadcast, not the media feed.
FFmpeg’s part is transport. It encodes or packages the audio and video and sends them to YouTube’s ingestion endpoint using the appropriate stream name or key. YouTube’s encoder setup guidance explains that the endpoint and stream name may need to be entered separately, or combined, depending on the encoder. Keep those connection details private: a stream key is a credential, not a title and not a safe value to share in a public example or screenshot.
The -metadata option in FFmpeg is a different kind of setting. FFmpeg documents it as a way to set an output metadata key/value pair; its example applies a title to an FLV output. That can be useful for metadata associated with a media file or container. It is not the documented operation for changing the YouTube event’s public title. Adding -metadata title="Morning Bhajans" to an FFmpeg command does not substitute for updating the broadcast resource.
This distinction helps diagnose confusing results. If FFmpeg connects and viewers see the picture and sound, the media path can be working even while the public title remains unchanged. Conversely, changing the broadcast description will not correct a connection problem caused by a wrong stream name or key. For a separate connection failure, the checks in this guide to an invalid stream key with FFmpeg address the transport side.
Choose the metadata you mean to change
The broadcast fields relevant to viewers are liveBroadcast.snippet.title and liveBroadcast.snippet.description. YouTube documents these as broadcast properties and notes that the corresponding video resource can also be used for those details. For this workflow, the Live Streaming API’s broadcast update method is a direct way to target the event associated with the active feed.
There is also a title and description on the separate liveStream resource. Those describe the stream resource, not the public broadcast that people open on YouTube. The Live Streaming API resource reference states that stream title and description are not visible to YouTube users. A value placed in the wrong resource can therefore look successfully saved to an API caller while not changing the public event details you wanted to edit.
| Location | What it describes | Public title or description? | Description limit in the cited API reference |
|---|---|---|---|
liveBroadcast.snippet.title and snippet.description |
The live event and its associated video | Yes | 5,000 characters |
liveStream.snippet.title and snippet.description |
The media feed resource | No | 10,000 characters |
FFmpeg output -metadata |
A metadata pair on the output | Not the broadcast update | No YouTube broadcast limit applies |
Google for Developers lists the 5,000-character maximum for a broadcast description in the liveBroadcasts.update reference. The 10,000-character value belongs to the separate stream resource, not the viewer-facing broadcast description. Do not transfer a limit from one resource to the other simply because both use a field named description.
Identify the broadcast to update
The API update targets a broadcast ID. That ID identifies the event/video whose metadata you mean to edit; it is not interchangeable with the stream key, stream name, or ingestion URL. The stream details route FFmpeg’s feed, while the broadcast ID locates the event record that viewers see.
When your application creates or lists broadcasts through the API, retain the ID returned for the intended event and associate it with the stream you are using. If you are adapting an existing workflow, check the current broadcast list or the event information available through YouTube’s current tools, then confirm the ID before sending an update. This article does not assume a particular YouTube Studio screen sequence, because interface details can change; use current YouTube guidance if you are locating an ID manually.
Before editing, establish which event is actually scheduled or live. A channel may have a test broadcast, an upcoming event, and a recurring workflow’s next event. Updating a valid but wrong ID can yield a successful response while leaving the public event you intended unchanged. A useful operational record can include the broadcast ID, the planned public title, a short description draft, and the stream resource associated with it. Keep stream credentials out of that record unless it is stored with appropriate access controls.
If you are new to looping prerecorded material rather than a live camera or microphone, first understand the broadcast workflow in this guide to streaming prerecorded video on YouTube Live. The important distinction remains the same: a playback file or feed is not the broadcast’s public metadata.
Authorise the channel for API changes
The update method requires OAuth authorization. The authorization should represent the YouTube channel that owns or manages the target broadcast and should request only the scope needed for the workflow. The method reference lists YouTube scopes including https://www.googleapis.com/auth/youtube and https://www.googleapis.com/auth/youtube.force-ssl; check the current authorization details in the method reference before implementing, because available permissions and requirements may evolve.
Do not treat possession of a stream key as authorization to edit event details. A stream key lets an encoder deliver media to an ingestion route; OAuth grants an application permission to make API changes for an account. They are separate credentials with separate risks. Avoid placing either value in a public script repository, shared screenshot, or log that can be read by people who should not have access.
YouTube can reject a request if the authorized account lacks the necessary live-streaming permission or if live streaming is not enabled for the account. An authorization failure is not necessarily evidence that the JSON fields are wrong. Check the account and channel permissions, then consult the current official eligibility and API error guidance rather than repeatedly changing the payload.
For a one-off title adjustment, using YouTube’s current channel tools may be simpler than building an API client. The API is most useful when you already have an authenticated application or need a repeatable process—for example, preparing titles for a series of scheduled devotional programmes. In either case, the title and description must be changed on YouTube’s broadcast or corresponding video, not inferred from FFmpeg’s output tags.
Send the update with liveBroadcasts.update
The documented method is a PUT request to https://www.googleapis.com/youtube/v3/liveBroadcasts. It requires a part query parameter and OAuth authorization. The request targets the resource by its id, and the updateable snippet properties include title and description. Consult the current update method documentation for the precise set of required body fields and request behaviour before running code in production.
At a high level, the intended change is to the selected broadcast’s snippet. A schematic example is:
{
"id": "BROADCAST_ID",
"snippet": {
"title": "Morning Bhajans | Live",
"description": "A continuous selection of devotional songs. Schedule and channel details are on the channel page."
}
}
This is illustrative, not a complete payload specification. The current API method reference lists additional required request-body fields, including scheduled start time and monitor-stream settings. Do not paste this abbreviated example into a client and assume that it fulfils every requirement. Retrieve the existing resource, follow the latest method documentation, and form a request body that meets its required fields while retaining the values you intend to keep.
The part parameter also matters: it specifies which resource parts the request updates or returns. It is not a substitute for reading the method’s current requirements. If your client library builds the request, inspect what it actually sends; if you make the HTTP request yourself, check the encoded URL, authorization, body, and response. Avoid printing access tokens or stream keys while debugging.
A sensible test is to make the change on a non-critical scheduled broadcast before relying on the same code for an overnight or recurring channel. Use a title and description that are easy to distinguish, then read the resource back and check the public event. This tests both that the account can update the right broadcast and that your payload preserves its other settings.
Preserve existing fields deliberately
The dangerous assumption is that a partial PUT will behave like a narrow patch in every respect. YouTube’s update reference warns that existing values for properties omitted from the request may be deleted. Therefore, do not assume omitted fields are guaranteed to remain unchanged. A successful HTTP response does not itself prove that every unrelated setting was preserved.
Before sending the update, retrieve the current broadcast and compare its fields with the request requirements in the live documentation. Include the existing values for fields that must remain, along with the new title and description. The API reference identifies required body fields such as id, snippet.scheduledStartTime, and monitor-stream settings under contentDetails; confirm their current names and conditions against the reference rather than copying a payload from an old tutorial.
This is also why an API body should not be assembled from only the two fields you want to change without checking the method’s behaviour. If a field is not present, the API may clear its old value. At the same time, do not blindly copy every returned field into an update: follow the documentation on which parts and properties are accepted, and avoid sending unrelated read-only values. The task is to preserve the relevant writable state while changing the requested snippet properties.
A small change log can reduce mistakes in a recurring workflow. Record the broadcast ID, when the update was attempted, which public fields were intended to change, and whether the response and read-back matched. Do not store tokens or keys in that log. If your channel depends on a continuous loop, keep the metadata update process separate from the media process so a failed title edit does not needlessly interrupt the feed.
For the underlying stream setup, a file’s resolution and encoding decisions affect the feed rather than the public title. If those are part of your planning, this discussion of 720p video files and bandwidth covers that separate operational question.
Verify what viewers can see
After the API returns, read the broadcast resource again using its ID and inspect snippet.title and snippet.description. Compare the returned values with the text you intended to publish. This catches a mistaken ID, a rejected or truncated value, an authentication problem, and cases where the request succeeded but did not produce the expected public fields.
Then check the event as a viewer would encounter it, using the channel’s current YouTube interface or the public event page where appropriate. Confirm that the event title and description are visible in the right place. The API resource read-back verifies stored fields; a viewer-facing check verifies that you targeted the intended event and that the details appear as expected. Do not share an unlisted or private event URL simply to demonstrate that the update worked.
For a recurring channel, think through when metadata changes. If every programme block uses the same broadcast, a single event title may not describe each item as the feed changes. If you create a new broadcast per programme, your automation needs to identify the new broadcast ID each time and update that resource, not reuse yesterday’s ID. The right choice depends on how the channel is organised, but an FFmpeg restart alone does not create or rename a YouTube event.
Keep descriptions factual and useful: say what is playing, when relevant, and where viewers can find more information. YouTube’s API reference sets the broadcast description maximum at 5,000 characters; a concise description is often easier to maintain than using the full allowance. If the update is refused, consult the official error information and correct the account, ID, or request rather than assuming the title text is the problem.
If you want the feed to continue when your own computer is off, StreamNeo can remove the need to keep FFmpeg running locally by turning an uploaded video into a YouTube live stream; the title and description still belong to the YouTube broadcast and should be checked there.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does -metadata title="..." change the public YouTube Live title?
No. FFmpeg’s -metadata sets an output metadata pair, while the public event title is stored on YouTube’s broadcast or corresponding video resource. To automate a change, update the correct YouTube resource and verify the result.
Is the stream key the same as the broadcast ID?
No. The stream key or stream name is used to deliver media to YouTube’s ingestion endpoint. The broadcast ID identifies the event whose public details you want to change; keep the two values distinct and protect the key.
Why might a title update fail even when the JSON looks right?
The authorized account may not have the needed live permission, live streaming may not be enabled, or the request may target the wrong broadcast ID. The update body may also omit fields that the current method requires, so check the official method reference and API error response.
Can I send only the title and description in the update body?
Do not assume that is safe. YouTube warns that omitted properties with existing values may be deleted, and the method reference lists required body fields beyond those two snippet values. Read the current resource and current documentation, preserve fields that matter, and read the broadcast back after the update.