C specification.
The fact that the quantization table is not zig-zag ordered lead to
confusion.
Guy
From: Alexandr Němec
To: LIVE555 Streaming Media - development & use
,
Date: 2013-12-01 18:42
Subject: Re: [Live-devel] RFC 2435 compliance
Sent by:live-devel-boun...@
uot;as
is" for a working implementation.
Best regards
Alex
__
Od:
Komu: "LIVE555 Streaming Media - development & use"
Datum: 29.11.2013 20:35
Předmět: Re: [Live-devel] RFC 2435 compliance
There is no issue with the RFC 2435
use
,
Date: 2013-11-25 07:06
Subject: Re: [Live-devel] RFC 2435 compliance
Sent by:live-devel-boun...@ns.live555.com
> This same question (I think) came up last January. Here is the answer
that I gave at that time:
Thanks for your quick reply. Sorry, I googled through th
> This same question (I think) came up last January. Here is the answer that I
> gave at that time:
Thanks for your quick reply. Sorry, I googled through the archives, but did not
find this one. The "zigzag" idea is the correct answer, as this order is
required for the JPEG DQT segment. So Li
This same question (I think) came up last January. Here is the answer that I
gave at that time:
http://lists.live555.com/pipermail/live-devel/2013-January/016400.html
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel m
Dear Ross,
we came across an interesting issue with JPEG video (transmitted via RTP) not
being decoded correctly. We tracked down this issue to the fact, that live555
seems to use different default JPEG quantizer tables (luma and chroma - see
JPEGVideoRTPSource.cpp line 271, latest source code
