Fix Live News Ticker Reading (OCR) in a Python/Streamlit Live Monitoring App

# Fix Live News Ticker Reading (OCR) in a Python/Streamlit Live Monitoring App — $60 ## What this project is We built an AI system that monitors live Pakistani news channels (via YouTube) and flags Hate Speech, Vulgarity, Irony/Sarcasm, and Violence in real time — both in what people are saying (speech) and in the news ticker/headline text scrolling at the bottom of the screen. The speech side works well. The ticker-reading side does not, and that is the specific part we need to fix. We're not asking anyone to build a new project — everything below already exists and mostly works. We need someone who can specifically look at the ticker-reading component, understand why it's unreliable, and fix it properly. ## What's already built and working A fine-tuned XLM-RoBERTa model (local, not an API) classifies each line of text into Safe / Hate Speech / Vulgarity / Irony-Sarcasm / Violence, with a confidence score. Whisper (OpenAI's speech-to-text) transcribes what's being said on air — this part is working reliably. Two different live-video pipelines exist: * An older one where FFmpeg captures screenshots of the video every ~1–2 seconds and audio chunks, saving them as files, which other parts of the code then read back. * A newer one we built using PyAV that reads the video and audio streams directly from YouTube into memory — no screenshot files at all. This has been confirmed to work for video/audio capture itself. OCR engines: PaddleOCR is currently being used as the primary ticker reader, with EasyOCR as a fallback if PaddleOCR fails to load. The application runs on Streamlit (Python web framework). GPU support (NVIDIA CUDA) is already wired in and working — an RTX 3070 Ti is available for this. Everything else — database, PDF reports, dashboard, user login, and multi-channel monitoring — is fully built and functional. ## The actual problem — please read this carefully The ticker (the scrolling headline text at the bottom of a news broadcast) is not being read correctly or reliably. ### Symptoms we're seeing: * The text shown in our dashboard often doesn't match what's actually on screen at that moment. * Sometimes the ticker text shown looks garbled or nonsensical (partial words, mixed-up phrases). * It doesn't feel like it's reading the ticker continuously the way a real scrolling ticker actually updates — it seems to stop, lag badly, or repeat. ## What we've already tried Please read this section carefully so you don't waste time suggesting approaches we've already tested. * Capturing a screenshot every 2 seconds → running OCR on it. This was the original approach. It was too slow, and by the time OCR finished, the real ticker had already scrolled past that text. * Increased the capture rate to 1 screenshot per second. This provided some improvement, but it was not a real fix. * Added a "skip OCR if the frame hasn't visually changed" check by comparing a hash of the image to avoid wasting time re-reading an unchanged frame. This helps when the broadcast is paused or static, but a continuously scrolling ticker changes pixel-by-pixel on almost every frame, so this doesn't meaningfully help with the real scrolling-ticker case. * Switched from screenshot files to a direct in-memory video pipeline built with PyAV to remove file-writing delays. We confirmed that this successfully pulls real video frames directly from the stream, but the ticker-reading logic on top of it still has the same fundamental accuracy problem. * Switched OCR engines from EasyOCR-only to PaddleOCR-first (EasyOCR as backup). This made some difference in text quality, but it did not solve the core issue. Our current understanding of why this is difficult is that news tickers scroll continuously, so any single screenshot only captures a partial, mid-scroll snapshot of the text. This makes it genuinely difficult for frame-by-frame OCR to read the ticker cleanly and continuously in the way a human eye can follow the scrolling text. We suspect the real fix needs a smarter approach than simply "grab a picture, run OCR on it," but we are open to your judgment on the right technique. ## What we need from you We need a working and reliable way to read the live scrolling news ticker from a video stream accurately and continuously, and then feed that text into our existing pipeline, which already handles classification once it receives clean text. You do not need to touch the classification model, database, UI, or anything else. This is specifically scoped to fixing the ticker capture and reading component. A sample dataset (recorded broadcast clips with visible tickers) will be provided so you can test and demonstrate your fix without needing live access to our exact setup. ## Tech stack * Python * Streamlit * PyAV * OpenCV * PaddleOCR * EasyOCR * PyTorch * CUDA/GPU * Whisper * Hugging Face Transformers * SQLite * FFmpeg * Streamlink / yt-dlp for pulling YouTube live streams ## How to apply Please don't send a generic proposal. In your proposal: * Confirm that you've actually read the entire post, including the "What we've already tried" section. * Explain, in plain terms, what you think is actually going wrong and what specific technique or approach you would use to fix it. * Tell us about your experience with similar work — live video/OCR pipelines, computer vision, or real-time text extraction from video. * A short Loom video walking through your proposed approach is strongly preferred. It is not required, but it will put you ahead of other applicants. * If you have an alternative approach that you believe could solve the same problem more effectively, please mention it. We are open to hearing your ideas and understanding how you would approach the problem differently. In your Loom video, please explain the proposed pipeline clearly — from live video/frame capture, ticker detection and processing, OCR, text reconstruction, and finally feeding the clean text into our existing classification pipeline. If your approach genuinely fixes the issue and you can demonstrate it working, we're happy to discuss paying more than the listed budget for the right person. However, please note that the listed $60 budget is specifically for solving this one ticker-reading issue, not for rebuilding the entire project. Thank you — looking forward to your proposals.