For a fixed Hindi product name and price, add an OBS Text source; for a designed product card or timed sequence, use a Browser Source with a local HTML page. Neither font controls nor source choice guarantees that every Devanagari glyph will render correctly, so check the actual OBS preview on the computer that will run the broadcast.
Prepare and verify the Hindi copy before building the overlay. Then inspect the card at stream size, confirm the price and currency, and test the YouTube Live Control Room preview with moving video and audio before you start.
Prepare Hindi product names and prices
Write the information viewers need before opening OBS: the product name in Hindi, its price, the currency, and any offer that is genuinely in effect. For example, a card might show a short Hindi name, ₹499, and one brief line about a current offer. Do not make the offer longer than the product name, and do not rely on the spoken demonstration to correct a price that is difficult to read on screen.
Keep one approved copy of each value. A product catalogue, order sheet or text file can be the reference; the important point is to avoid one price in the overlay and another in the presenter’s notes. Check spelling, matras, conjuncts, punctuation and numerals with someone who can read the intended Hindi if that is not you. A technically neat card can still mislead if its text is wrong.
Decide whether the card will stay up for one item or change between products. A single product demonstration can use a fixed label, updated manually between segments. A longer showcase may call for several cards, but each should remain visible long enough to read at the intended viewing size. Try the wording on a phone-sized preview as well as your OBS canvas: text that is legible on the production monitor may be tiny in a mobile player.
Use the same writing convention throughout. If prices use Arabic numerals, keep that choice consistent; if you use Devanagari numerals, confirm that every digit displays. Keep the rupee symbol or other currency marker attached closely enough to the price that viewers do not mistake what the number means. Avoid decorative punctuation that could be confused with a decimal or separator.
If the overlay accompanies a playlist or prerecorded demo, plan its timing alongside the video rather than treating it as an afterthought. The guide to streaming a playlist to YouTube Live using OBS covers the broadcast setup; this article focuses on making the product information clear and dependable within that setup.
Choose Text or Browser Source
OBS has two useful routes for this job. A Text source is the simpler choice for a fixed name and price. A Browser Source is appropriate when you need a composed card, several fields with precise placement, or a sequence whose timing is controlled by a local web page. OBS documents both source types, including text input from a file and the ability to load a local file in a Browser Source (Text Sources, Browser Source).
| Choice | Use it when | Update and layout | Rotation |
|---|---|---|---|
| Text source | One fixed label or straightforward text | Enter text in the source properties or read it from a text file; styling stays within the source’s text controls | Do not assume the source itself rotates products |
| Browser Source with local HTML | A designed card or a multi-card presentation | Lay out the card in HTML and set the browser viewport to match the scene | The page can implement rotation; test its behaviour in OBS |
For a one-item demonstration, Text avoids writing a page and reduces the number of things to troubleshoot. If the product name changes often, a text file can separate the copy from the scene: edit and verify the file, then check that the displayed result is still correct. This route can be easier for an operator who does not need decorative layout.
Choose Browser Source when the card needs distinct areas for a name, price and offer, or when the presentation calls for timed changes. The rotation would be implemented in the HTML page, not supplied as an established Text-source playlist feature. That flexibility adds work: the page must load, fit the scene, show the right item for the right interval, and recover as expected after a refresh or scene change.
A playlist-focused channel may also need to coordinate overlays with its programme. See the guide to adding a now-playing title to a 24/7 stream for the related problem of keeping on-screen information aligned with changing content. Product cards need the same discipline, but prices require a separate accuracy check.
Add and style the product card
Create the scene in which the demo video will play, then add the overlay as a source and position it over an area that does not obscure the product. In OBS, use the Sources dock to add a Text source for a fixed label or a Browser Source for a page-based card. The OBS sources guide explains the general relationship between sources and scenes; keep the overlay and video arranged in the scene you will actually broadcast.
With Text, enter the approved Hindi copy or point the source at a text file. Set the type size and colour, then place the text against a relatively calm part of the image. Do not judge readability only by the font size shown in the properties: the final result depends on the output canvas, scaling and the player size. Use a contrasting backing panel if the footage changes between light and dark scenes.
For Browser Source, build a small card in a local HTML file and select that file in the source’s properties. Set its width and height to the intended card or scene dimensions, then design within that viewport rather than relying on content to resize itself. Leave room around the words; a border or background should not crowd matras or clip punctuation. Preview the card over the real footage, because a colour combination that works against a plain test background may disappear against a moving product shot.
Keep hierarchy simple. The product name should be easy to find, the price should be prominent without competing with it, and a secondary offer should be smaller. If there are multiple lines, make the line breaks intentional: Hindi syllabic marks must remain associated with their characters, and an awkward wrap can make a familiar word harder to recognise. Leave safe margins so that text is not pressed against the canvas edge.
Before moving on, switch through the scenes and sources that will be used during the demo. Confirm the card appears above the video rather than behind it, that it is not hidden by another graphic, and that the selected scene is the one you expect. Save the scene collection after confirming those basics.
Set up timed rotation in the HTML page if needed
If viewers need to see several items without an operator changing text, let the local HTML page handle the sequence. Prepare a card for each product with its verified name, price and any accurate offer. In the page, define the order and duration deliberately; this is an implementation you create, not a timed product-card control promised by OBS documentation.
Keep the page simple enough to inspect. Each card should use the same structure and visual hierarchy, so a price does not jump to a different corner between products. Avoid adding motion that competes with the video. A quiet transition or direct replacement is easier to follow than rapid effects, especially when someone is trying to read Hindi on a small screen.
Test the timing by watching a complete cycle in OBS. Check that the first item appears on page load, that the sequence advances in the intended order, and that it does not pause or reset unexpectedly when you switch scenes or refresh the Browser Source. Confirm the displayed item against the approved list, not just against memory. If a card is too brief to read, change the page timing rather than asking viewers to catch up.
Also plan what happens when the page is unavailable or an item is removed. A static, valid first card is safer than a blank overlay, and a short sequence is easier to maintain than a long list whose prices can go stale. If you update the HTML after testing, repeat the cycle check: a last-minute text edit can alter line breaks, overflow the viewport or introduce a missed price.
Check fonts and Devanagari glyphs on the OBS computer
Font selection is not proof of correct script rendering. The OBS documentation describes Text source font controls, but it does not provide a Devanagari-specific rendering guarantee. The computer running OBS must display the exact copy correctly in the actual scene preview; test the result rather than inferring it from a font name or from how it looks in another application.
Enter representative Hindi text, including the trickiest words in your product list. Inspect vowel marks, conjuncts, punctuation, numerals and the rupee symbol at the final output size. Look for missing boxes, separated marks, cramped combinations and unexpected substitutions. A short English placeholder will not reveal these issues, and a browser page and a Text source may behave differently on the same computer.
If a glyph is missing or malformed, try a Devanagari-capable font already installed on that system and inspect again. Do not assume that a font will work simply because it supports Hindi in a document editor. For a Browser Source, test the rendered HTML in OBS itself, not only in a separate browser window. If the card is being prepared on another computer, copy the page or scene and verify again on the broadcast computer, where the available fonts may differ.
Keep a record of the chosen font and the final text once the preview is sound. If the computer changes, OBS updates, or the text is edited, repeat the visual check. This does not establish a universal guarantee; it gives you evidence for the specific setup you intend to use.
This check matters especially in a regional-language product demonstration, where a malformed name can be more than a cosmetic fault. The guide to showing Hindi subtitles in OBS addresses a related script-rendering task. For product cards, apply the same principle: inspect the real output, and do not treat a documented font control as proof that every glyph is available.
Inspect the YouTube preview and test audio and video
An OBS preview confirms what the scene looks like locally; it does not replace checking the incoming stream in YouTube Live Control Room. Create or schedule the stream, connect the encoder, and inspect the Control Room preview before starting the public broadcast. YouTube’s encoder setup guidance describes the setup and preview workflow.
Watch the product card over moving footage, not only over a paused frame. Confirm that the Hindi remains legible as the background changes, the price is still correct, and the overlay has not shifted or clipped. Test the audio that viewers will hear as well: speech should be audible, and any background music should not mask the product explanation. YouTube recommends testing audio and motion similar to what the live event will contain in its streaming tips.
If you are using an encoder, check the stream health messages and the picture quality in the Control Room. YouTube’s live encoder settings guidance covers supported settings and recommends a two-second keyframe interval, with no interval above four seconds. Use the settings appropriate to your channel and upload connection rather than copying values without checking the current official guidance.
A product demo has two kinds of failure to catch: the broadcast may be technically moving, while the product information is wrong or unreadable. Have someone review the Control Room preview if possible, particularly if the operator cannot see both the stream and the catalogue at once. Ask them to read the name and price back from the preview, not from the source file.
For a prerecorded loop that must continue when your own computer is off, the operational question is different from a scene overlay. StreamNeo removes the need to leave the OBS computer running by taking an uploaded video and running it as a YouTube live stream, which is useful when an overnight loop should not depend on a home machine staying on. It remains your responsibility to prepare accurate product information and check the resulting presentation.
Correct layout before going live
Fix problems in the source or page, then run the preview again. For a Text source, adjust the text, font choice, size or position and inspect the full Hindi wording. For a Browser Source, correct the HTML layout or viewport dimensions and reload the page in OBS. A change that looks right in the source editor can still wrap differently when rendered on the output canvas.
Check the card at the resolution and scene composition you will send to YouTube. Keep the text inside the visible frame, away from areas where the player interface may cover important information, and clear of the product itself. Use a stable background behind the words if the footage is busy. Avoid shrinking text to make an overfull card fit; edit down secondary copy first.
Confirm that each displayed price matches the current product information immediately before going live. If an offer has ended, remove it rather than relying on a verbal correction. For a timed sequence, watch the whole run once more and confirm each item’s name and price appear together. If the layout, file or scene changes after the final check, check it again in the Control Room preview.
When the file and channel are ready, compare the operating options and begin with a checked setup.
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
Should I use Text or Browser Source for one Hindi price?
Use a Text source when the label is fixed and needs straightforward styling. Choose Browser Source if you need a designed card or a sequence controlled by your own HTML page. In either case, inspect the Hindi in OBS on the computer that will broadcast.
Can an OBS Text source rotate products automatically?
Do not assume so. The documented Text source is for displaying text, including text read from a file; it does not establish a timed product-card playlist. For timed rotation, implement the sequence in a local HTML page loaded as a Browser Source and test it in the scene.
Does choosing a Hindi font guarantee Devanagari will display correctly?
No. Font controls do not guarantee that every required glyph or combination will render correctly in your particular setup. Enter the actual Hindi copy and inspect marks, conjuncts, numerals and punctuation in the OBS preview.
Do I need to check the YouTube preview if OBS looks right?
Yes. OBS shows the local scene, while the Live Control Room lets you inspect the incoming broadcast. Check the card over moving video and test the audio before starting, then keep an eye on stream health during the event.