Re: [rtcweb] MTI motion JPEG

[Basil Mohamed Gohar <[e-mail]>]

For what it's worth, what you described sounds a lot like the "Smoke"
video codec, which, as far as I know, exists only on the OLPC project
via gstreamer.  At least, that's about the only reference I've ever
found for it.

On 12/02/2013 05:28 AM, Maik Merten wrote:
> Yes, I guess you're right, this is out of scope. It's just that its
> tempting to come up with ideas for improvements, given the low-hanging
> fruits in case of MJPEG are basically touching the ground.
> 
> Maik
> 
> Am 02.12.2013 10:50, schrieb Harald Alvestrand:
>> Designing new video codecs is something that I don't think we should do
>> in this WG at this time.
>>
>>
>> On 12/01/2013 12:46 AM, Maik Merten wrote:
>>> Am 30.11.2013 01:49, schrieb Ralph Giles:
>>>> I'd like propose motion JPEG as the manditory-to-implement video codec,
>>>> per RFC 2435 or similar.
>>>
>>> Is it feasible to extend the RFC with, e.g., a run-length coded list
>>> of skipped MCUs ("macroblocks")? Picture data for those would be
>>> copied over from the last frame. This may even work with unmodified
>>> JPEG decoders (either by filling in stub data for the skipped MCUs at
>>> the receiving end or by encoding skipped MCUs compact run of zeroed
>>> coefficents) and a postprocessing step.
>>>
>>> (If coding an explicit list of skipped MCUs is not practical, one can
>>> regard MCUs with all-zero coefficients as "skipped". An encoder will
>>> have to take this into account so no MCUs are skipped by accident,
>>> though.)
>>>
>>> This contradicts the minimal-effort argument to some degree, but at
>>> least this would enable efficient transmission of screencasts,
>>> increase coding efficiency for "talking head" content, and offer
>>> additional means for bitrate management (partial screen updates).
>>>
>>>
>>>
>>> Maik

-- 
Libre Video
http://librevideo.org