OK, guys and gals... I have been challenged (well, more or less) by a big-name industrial encoder vendor to make VLC see the stream from their MPEG-4 camera encoder. A conversation with their head of product of development recently about my progress elicited a "WHAT? VLC can not work with our XYZ encoder!" The upshot is that they have twisted the standard just enough to still call it "MPEG-4" but (supposedly) not make it work with anything other than their hand-picked proprietary products. No, they do not publish tech specs nor are they willing to talk details.
Here's the scoop on what I've been able to do so far:
1) Setting demux to a forced MPEG-4 video and accessing via multicast/UDP, I see a "smeared" stream, with the top 10% almost right. Leaving it to run will eventually crash VLC on OS X. I have seen this with other MPEG-4 encoders that will subsequently work fine with RTSP/SDP.
2) Port scans of later firmware revs of the encoder revealed port 554, and going to the base address via RTSP gets clean video after about 15 seconds of acquisition time, but with 5 seconds of latency. Then latency will accrete at a rate of about 5 seconds per 60 seconds until the stream is restarted. Eventually "late frame" errors will show in the error log, but nothing more than that.
I am a coder (albeit a bit rusty), so I'm just starting to poke at code. However, I have never tackled video. So I am needing pointers, encouragement, mystery solving and other possible kicks-in-the-butt to reverse-engineer the distorted stream and make it work.
The goal is zero latency and clean video, or at least as near to zero as we can get. The client is as exasperated as we are with this situation, and is about to throw nearly $250,000-worth of these encoders into the dumpster because of the little "gotcha" with the stream. They like the VLC solution, and I'd like to underscore it for them to solve something that the commercial server vendors have not been willing to.
What say ye? Any helpers here?