Foscam MJPEG feeds are broken

Michael Niedermayer has explained that it is not obviously achievable to have any MJPEG stream RTPized.
---------- Forwarded message ----------
From: Michael Niedermayer <michael@niedermayer.cc>
Date: Tue, Jan 26, 2016 at 5:06 PM
Subject: Re: [FFmpeg-devel] Bug #3823 (yuvj422p jpeg rtp enc) request for help
To: Andrey Utkin <andrey.utkin@corp.bluecherry.net>

On Tue, Jan 26, 2016 at 01:34:08PM +0200, Andrey Utkin wrote:
> On Tue, Jan 26, 2016 at 1:06 PM, Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> > iam not sure what usecase you have in mind
> > the synthetic command produes a form of 422 mjpeg which appears to be
> > incompatible with rtp. To get that working the mjpeg encoder needs to
> > be changed.
>
> In MPEG RTP RFC, I see no statement that 422 is not supported.

422 is supported, but not every 422 jpeg

> 422 is not supported well by ffmpeg's rtp muxer, it's true and it's the point.
> It was claimed to be completely unsupported until recent changes (by
> Carl Eugen Hoyos AFAIR), which claim to support 422.
> But it still works badly in practice (seems some wrong assumptions in code).
>
> > Can you elaborate on what usecase you have and how o reproduce its
> > failure ?
>
> 1. We have a stream source: an HTTP or HTTPS URL which returns MJPEG
> stream with Content-Encoding: chunked. Often MJPEG pixel format is
> yuv422p (I don't remember if I've ever seen yuv444p, but let's ignore
> this). This is what a lot of IP cameras expose as the only option. And
> this is what the mentioned synthetic example resembles.

the stream generated by the synthetic example is not compatible with
rfc2435

The issue here is that our jpeg encoder shares alot of code with
mpeg* and thus the encoding we use in jpeg is close to what mpeg
uses (jpeg is flexible and allows quite some variation)
rtp seems very strict on this though and does not allow the variant
our shared code produces

iam no rtp expert, i might miss a later RFC or some trick of course
but what i see, theres just no syntax element to store the variation
on the "macroblock structuring" we use

> 2. We pull this stream; it plays fine as is, but we need to restream
> it through RTSP, thus we RTP-mux it.
> 3. What happens:
> 3.1. The stream plays back with picture artifacts (wrong colors AFAIR)
> - this was the case until recent changes.
> 3.2. RTP-mux deliberately fails - this is what happens with latest
> ffmpeg from git.
>
> --
> Bluecherry developer.
>

--
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
bluecherrydvr / bluecherry-apps-issues

Foscam MJPEG feeds are broken #112
