Subject: Re: [MMUSIC] [AVTCORE] Question

From: [email-masked] (Dale R. Worley)
Date: Mon, 05 Jan 2015 22:52:39 -0500

Julius Friedman <[email-masked]> writes:
> I would like to address your response:
>
> "In any case, why would we want to prevent seeking on a stored media
> object?  I can see why if the media is an un-stored media stream, but in
> that case, the software likely doesn't know the total length that the
> media will have."
>
> I will justify how "likely" this is as follows:
>
> 1) A Live 10 minute `media` which has been playing for 3 minutes, leaving
> me 7 minutes in play but unable to seek.
>    a) If the stream was stored or recorded this obviously wouldn't be an
> issue

But how would we know that the media is 10 minutes long if it was not
already stored?  If it was truly live, we'd only know that it was
*scheduled* to be 10 minutes long, not that it will actually *be* 10
minutes long.

> 2) I have a server which requires authorization to seek but not to play.

Why would we want to support that?

> 3) I am a client and I have started playing and 'PAUSE' is not supported
>
> 4) I am a server re-streaming from a server where "Range" is not supported

I'm no expert in RTSP, but my understanding is that these two situations
are only expected to happen when the media is truly live, that is, the
server does not know how long the media will be.

> "Perhaps referring to the mailing list discussion for this RFC would
> reveal the answer."
>
> Which mailing list is that? 'mmusic' they have also been addressed, several
> times. I never get a response from them.

I assume you mean "I have asked before on mmusic and received no
response."  Perhaps nobody else cares about the proposed capability?

I mean the mailing list discussion surrounding this document when it was
made an RFC.  (Better, look up the Internet-Draft name and refer to the
appropriate mailing list archive for the time when the I-D was being
discussed.)

Dale

---

From: Julius Friedman <[email-masked]>
Date: Tue, 6 Jan 2015 09:17:02 -0500

- In that case we don't know if tomorrow will come because it isn't
guaranteed today, lets be serious.

I have a server which is aggregating a stream which is stored, my server
doesn't store the stream.

Only authorized users can seek the stream on the server to move it in time.

The public has to watch from where it is to where it ends and know that
seeking is not supported remotely.

In such a case I know the end time and that seeking isn't supported but the
client doesn't.

This is a common task 'aggregating a stream' and SHOULD be handled, the
fact that Range infers seek-ability is for lack of a better word
`over-reaching`.

I will be adding something for this in my server and I know for a fact that
others would benefit.

That aside,

What about my questions regarding the 'source' and 'ssrc' parameters? Those
aren't proposals, those are genuine questions.

What about my questions regarding the Binary Interleaved Data? The wording
on Disabling 'Retransmission' and the 'Safe' characters '\$'  or '\#'..

As for my other 'issues' / errata for RFC2435 has anything been determined
on them?

What about the one for RFC3550, has anyone sat down to do the math on that
one yet?

I will include their questions here again and I would appreciate a single
complete and through reply.

Since the binary framing was apparently an after thought (based on
information from the drafts which show interleaved data in a 'DATA' RTSP
response) I think this was remnant from that in some way or at least that's
the best I can possibly imagine.

Why the framing octet would also be listed as a 'safe' character is beyond
me, there were several other characters / octets which definitely could
have been used e.g. 0xC3 -> 0xFF.

The fact that the document makes so many statements about ease of parsing
and then literally and figuratively destroy this concept with bad decisions
such as the framing character as well as the interesting syntax for the
markup.

I will past some of those here :

1.4 <https://tools.ietf.org/html/rfc2326#section-1.4> Protocol Properties

   RTSP has the following properties:

....

   Easy to parse:
          RTSP can be parsed by standard HTTP or MIME parsers.

...

4 <https://tools.ietf.org/html/rfc2326#section-4> RTSP Message

   RTSP is a text-based protocol and uses the ISO 10646 character set in
   UTF-8 encoding (RFC 2279 <https://tools.ietf.org/html/rfc2279>
[21]). Lines are terminated by CRLF, but
   receivers should be prepared to also interpret CR and LF by
   themselves as line terminators.

     Text-based protocols make it easier to add optional parameters in a
     self-describing manner. Since the number of parameters and the
     frequency of commands is low, processing efficiency is not a
     concern. Text-based protocols, if done carefully, also allow easy
     implementation of research prototypes in scripting languages such
     as Tcl, Visual Basic and Perl.

     The 10646 character set avoids tricky character set switching, but
     is invisible to the application as long as US-ASCII is being used.
     This is also the encoding used for RTCP. ISO 8859-1 translates
     directly into Unicode with a high-order octet of zero. ISO 8859-1
     characters with the most-significant bit set are represented as
     1100001x 10xxxxxx. (See RFC 2279
<https://tools.ietf.org/html/rfc2279> [21])

   RTSP messages can be carried over any lower-layer transport protocol
   that is 8-bit clean.

   Requests contain methods, the object the method is operating upon and
   parameters to further describe the method. Methods are idempotent,
   unless otherwise noted. Methods are also designed to require little
   or no state maintenance at the media server.

This literally becomes a nightmare when you have to reconstruct TCP
sequences.

This is only exacerbated by the fact the document allows packets up to the
maximum holding size in this mode AND specifies that packets with an
unknown context must be skipped...

Skipped how? Skipped as in past their header, past their data? Can that
text even be there?

We are talking about TCP and in such a case the data from a previous
segment was already received by the receiver and contains only some of the
data how would they skip data they have yet to receive?

I will explain why this is a security issue, Since there is no sequence
information in the binary header it must be trusted to contain valid length
values. Without inspecting the latter octets one can make no such
assumption about the type of binary data contained therein, especially if
there is no context assigned.

This if I can get a single TCP packet into a stream I can very easily
inject a lot of 'receive' space thus exponentially increasing my chances of
getting another packet into the stream.

I think that there should at the very least be a correlation between
'Block-Size' and the frame size such that frame sizes MUST NOT ever be
larger than that value if not already.

Furthermore I think that something needs to be done to specify how to deal
with nuisances such as 'more / less bytes available than indicated in
frame' especially when we also have 'Rtsp' messages which can be
interleaved at the same time in between frames (which can contain "$").

So to re-iterate my understanding of how things are in toto I have an
example I will outline below which is is a Rtsp Binary Interleaved sender
who tells a Rtsp Binary Interleaved client there is a frame of 48344 bytes
on channel 0.

The client received only 1328 bytes.

47016 bytes remain.

The client starts to receive again.

At this point there should only be the rest of the data in the frame (47016
bytes)

This data will come over several MSS sized segments, during which time the
socket may also be written to again (before the segment is transmitted to
the client).

{
    If the latter data happens to get to the receiver before the other
portions of the segment we have TCP 're-ordering' based on the sequence
number and may multiple ACK's for the early packets.

    If any data is missed we will have a re-transmission.

    The data being 'received' on the socket by the receiver coming from the
server comes from the data portion of the tcp packet which now contains
data from a previous segment.
}

The sender is now committed to sending the additional bytes as indicated
however if the sender stops sending this data or it's truncated it will
never make to the receiver. The stack will never be able to re-assemble the
packet and now framing sync is lost.

At this point ANY data consumed from the initial frame header and data
which was received must ALSO be dis-guarded but there is NO WAY for the
server to indicate this to the client... (This is why UDP is commonly used,
you get what you get and you don't what you don't)

There are a lot of articles outlining why TCP and RTP don't get along
mostly citing the overhead of re-transmissions so with Rtsp you think we
would have attempted to solve this not make it worse with bad encapsulation.

Something needs to be done about this because it's also a security concern,
e.g. if a client were to send a rtcp packet to the server which is very
larger and contains no data he could attempt to exhaust the resources of
that server (if they didn't monitor their rtcp bandwidth properly) or at
least force a higher amount of traffic.

So, information needs to be clear that there is no such thing as a packet
of less then 8 bytes under rtcp and 16 bytes under rtp. (Unless compression
is being used; ROHC or otherwise)

The null packet or any packet under 16 bytes would used for 'spacing' not a
'unknown' context, especially when I can have 255 channels, what unknown
context am I going to use then?

That is 4 octets for the `$` header, and the rest for the the packet header
which can then be inspected to be the same version, payloadtype and ssrc as
required by the client.

This prevents a client who may also send a "GET_PARAMETER" under
interleaved transport with weird headers and a body to attempt underflow
also which is something the current specification does nothing to protect
against.

"GET_PARAMATER rtsp://someuri/ RTSP/1.0\r\nCSeq:1\r\nDate:
xx:xx:xx\r\nContent-Length:24\r\n$UserAgent
$009\r\n$\0\0\aRTSP/1.$\0\0\r\n\r\nDatawith$IsNotAGoodIdea!\0\0"

This would allow applications to still take note of when a large frame was
seen but not be forced to act upon it and potentially lose data, and
depending on their implementation allow remote code execution.

I urge the committee to seriously look into these issues as they can have a
large impact in both interpretation of the standard and it's security
features.

https://isecpartners.github.io/fuzzing/vulnerabilities/2013/12/30/vlc-vulnerability.html

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 06 Jan 2015 14:22:17 -0500

I'll note that I've received this message directly

> As for my other 'issues' / errata for RFC2435 has anything been determined

Not yet, clearly.  What are you going to do to get them discussed?

> complete and through reply.

That is the least effective way to get your issues handled.

First, you are *demanding* something, and that always makes people less
interested in helping you.

Second, you want a "single complete and through reply", which means that
if someone doesn't feel like doing all the work to do that, they won't
bother to do any of the work.  That is, it minimizes the chance that
you'll get any response at all.

A better approach would be to select one problem, the one you think
other people are most likely to recognize as a problem, and ask about
it.  Also, add whatever discussion you can provide, to indicate that
you've done as much work on the problem as you can before asking others.

> aren't proposals, those are genuine questions.

Note that while RFC 2326 talks about a 'source' parameter, it doesn't
provide any BNF for it.  Suggest that it probably has the same BNF as
the 'destination' parameter.  Show that BNF.  Show all the examples of
source parameters that you know of (mention what devices generate them),
compare them to your suggested BNF.  Add your discussion of security
questions.

Once you've solicited as much feedback as you can get, organize all that
information into a well-written errata for the RFC.

Then go on to the next issue.

> As for my other 'issues' / errata for RFC2435 has anything been determined

http://www.rfc-editor.org/errata_search.php?rfc=2435&rec_status=15&presentation=table

All of your errata on RFC 2435 have status "reported", so it appears the
answer is "no".

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 06 Jan 2015 14:28:58 -0500

I've looked at this erratum
(http://www.rfc-editor.org/errata_search.php?eid=4097) and I don't think
I understand it.

It contains a section titled "Section 3.1.5 says" and a section titled
"It should say", but the bodies of the two sections are exactly the
same.  (I used a text editor to compare them.)  So what change is
described by the erratum?

There is a section titled "Notes" which says:

    Use a divisor of 256 to determine the height, where 8 / 256 = 32.

    Ensure FragmentOffset does not exceed 2^24, if it does then use 2^24
    - value)

The first line does not seem to describe the computation described in
the RFC text, and the equation in that line is incorrect.  (Was it
supposed to be 256 / 8 = 32?)

The second line seems to be entirely unrelated to the rest of the
erratum.  Perhaps it belongs in another erratum?  It also contains an
unmatched ")".

Dale

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 6 Jan 2015 19:38:33 +0000

Hi,

Dropping AVTcore, and focussing on RTSP only.

Work has been ongoing for many years towards an RFC 2326bis, and that
document has recently been approved and will obsolete RFC 2326 once the
downrefs are resolved and the RFC editor is done with it.  See attached.
I vaguely recall that I saw BNF for at least the ssrc parameter.  Suggest
that you study that document, it may address a lot of the RTSP issues you
seem to propose to solve by errata (inappropriately, IMO, but that¹s
another issue where you have received guidance on before, by folks more
competent than myself).

Stephan

On 1/6/15, 11:22, "Dale R. Worley" <[email-masked]> wrote:

>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic

Subject: [MMUSIC] Protocol Action: 'Real Time Streaming Protocol 2.0 (RTSP)' to Proposed Standard (draft-ietf-mmusic-rfc2326bis-40.txt)
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: mmusic chair <[email-masked]>, mmusic mailing list <[email-masked]>, RFC Editor <[email-masked]>
Date: Tue, 11 Feb 2014 07:58:08 -0800
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>

The IESG has approved the following document:
- 'Real Time Streaming Protocol 2.0 (RTSP)'
  (draft-ietf-mmusic-rfc2326bis-40.txt) as Proposed Standard

This document is the product of the Multiparty Multimedia Session Control
Working Group.

The IESG contact persons are Gonzalo Camarillo and Richard Barnes.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/

Technical Summary

The document defines RTSP version 2.0 which obsoletes RTSP version 1.0
defined in RFC 2326.

The Real Time Streaming Protocol, or RTSP, is an application-level protocol
for setup and control of the delivery of data with real-time properties.
RTSP provides an extensible framework to enable controlled, on-demand
delivery of real-time data, such as audio and video.  Sources of data can
include both live data feeds and stored clips.  This protocol is intended to
control multiple data delivery sessions, provide a means for choosing
delivery channels such as UDP, multicast UDP and TCP, and provide a means
for choosing delivery mechanisms based upon RTP (RFC 3550).

Working Group Summary

The document has been work in progress for an extended period of time
dating back to 2002. Earlier versions saw decent WG participation however
the later versions have primarily been driven by the document authors with
limited overall discussion in the group, especially towards the end of the
process. There are no known issues or major discussion points, and there has
been no indication of lack of consensus in the WG.

Document Quality

The document has been reviewed in detail several times after WGLC and in
preparation for the publication request and the authors have made several
updates as a result of those. The document is considered to be of high
quality at this point.

There is one known implementation of the specification, and many of the
extensions compared to RTSP 1.0 have been implemented separately as well.

A Media type review was done for "text/parameters". The review thread can
be found at: 
http://www.ietf.org/mail-archive/web/ietf-types/current/msg01656.html

Personnel
Document Shepherd: Flemming Andreasen
Responsible AD: Gonzalo Camarillo

RFC Editor's Note:

Section 2 of this document and its subsections provide "an informative
overview
of the different mechanisms in the RTSP 2.0 protocol, to give the reader a
high
level understanding".  As such, it's very important that it be clear and
well
written.  Some reviewers have found the English to be difficult.  Please
take
an especially critical pen to this section, making sure that the grammar
and
usage are correct, and that the language is clear.

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Julius Friedman <[email-masked]>
Date: Wed, 7 Jan 2015 13:27:30 -0500

@Dave & Stephan,

Well thanks for letting me know at least someone sees these messages.

I am not demanding anything, I had these inquiries for over 6 months and
when I received no response I filled the erratum. If there is a better way
so be it but respond and indicate such. I will retract erratum if I am
wrong or it is determined to not be applicable.

Right now basically when I use the advice I am given, the people that gave
it to me get offended, well how do you think I feel when it was told to me
the same things? e.g. "RTP has worked for 20 years" or "Mr. Casner is the
worlds leading expert" or "Collin Perkins didn't respond" Who cares? That
was not a scope of my issue and more spam then any of my inquires
contained. If they don't want to respond they don't have to, the issues are
still real.

I am open to writing a draft to correct things but there is nothing to
write about if people can't get over the fact that there are issues which I
attempted to openly addressed, weather or not people respond doesn't really
make a difference in the end I guess as I can't really DO anything to FORCE
you to address these issues, I can only file errata and if the errata is
accepted so be it. I have my own software to worry about and that's where
my focus will be, it will be unfortunate if I have to explain why I
explicitly chose not to be 'complaint' but its more so to just pretend like
it was 'intended' and hide behind the details.

That being said I do apologize if I stepped on any toes or hurt anyone's
`ego`, I don't intend to do that and I didn't bring the conversation in
those directions anyway. I just want to address the issues and move on.

Relating to my RFC2435 Errata.

YES, this is correct, I apologize for the backwards calculation.

The RFC only provided a way for certain sized images much lower then what
JPEG supports to be transferred, this erratum fixes this by specifying that
in some cases you may need to use a different fraction to obtain the height
(which might not be in a multiple of 16 anyway) additionally it allows one
to deal with the nuance that if the data is so large that the
FragmentOffset will probably overflow during this time and provides a way
to deal with that as well.

I just wanted to determine if there was any consensus around
my proposed change, do you recommend I add another erratum for the
`FragmentOffset` issue? And yes the 'Unmatched brace' is also my bad.

There are actually two others which can be seen here: (and possibly more
important)

http://www.rfc-editor.org/errata_search.php?rfc=2435&rec_status=15&presentation=records

They related to the types of JPEG which can be transferred under the RFC
and the tables used for quantization when quality is <=
50, specifically there are problems for black and white jpeg's and jpegs
with more then 2 quantization tables. My implementation handles all of this
but the code given in the RFC does not.  You can find my code @
http://net7mma.codeplex.com/SourceControl/latest#RtspServer/MediaTypes/RFC2435Media.cs
or the corrected code in the erratum.

Thank you for your input and I would appreciate taking the next steps on
those if possible so please let me know what to do next if anything.

I see that my 'RTSP' errata (4199) is `reported` and that it contains a
typo as I previously indicated, no one seems to have responded to that, I
can only imagine that it's known but no one really understand or knows what
to do about it and furthermore it seems that in the latest draft there have
been quite a few changes which remedy my questions in some regard but not
totally.

As for the updated RTSP Standard, I will say that the standard does seem
greatly improved as of the latest version @
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40

I will definitely be using some of the information present to deal with my
issues with 'Live' non-stored streams, such as the 'Media-Properties' and `
Seek-Style` header.

I do have a few questions related to the content however which hopefully
can be resolved before any further issue comes up.

13 <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-13>.
Method Definitions

   The method indicates what is to be performed on the resource
   identified by the Request-URI.  The method name is case-sensitive.
   New methods may be defined in the future.  Method names MUST NOT
   start with a $ character (decimal 36) and MUST be a token as defined
   by the ABNF [RFC5234 <http://tools.ietf.org/html/rfc5234>] in the
syntax chapter Section 20
<http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-20>.
The methods
   are summarized in Table 7.

...

Why does it make sense to work around the issue that '$' is both the
framing character and now officially a 'SAFE' character?

Rather than change the framing method to something which would be
better for TCP since it's only used there we simply make it worse by
removing the ambiguity of '\$' and now saying that '$' is safe.

So now we can also have '$' Methods like "METHOD_$" that's not a great
feature... I think that 36 needs to be removed from the header section
all together. It should simply not appear in the header section under
any cases.

CSeq and Date (etc) should use Hex rather than Decimal notation which
would remove most of the issues with it's occurrence. The body section
is not an issue as it's length and encoding is given.

14 <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-14>.
Embedded (Interleaved) Binary Data

Note that this mechanism does not support PDUs larger than 65535
      octets, which matches the maximum payload size of regular, non-
      jumbo IPv4 and IPv6 packets.  If the media delivery protocol
      intended to be used has larger PDUs than that, definition of a PDU
      fragmentation mechanism will be required to support embedded
      binary data.

...

TCP can technically be fragmented or overlapped without such large
packets so what does this statement provide?

The fact my network users larger packets would make no different as I
likely wouldn't be sending those packets outside my network.

How should one specify such as mechanism which is both compatible with
existing interleaving and this new mechanism? Without a better Binary
Interleaved Header it would be almost fruitless anyway since the TCP
protocol does not allow developers to take advantage of the
re-transmissions configuration per socket or disable receive
coalescing. (Although some Linux / Unix implementations do allow this
via TCP_USER_TIMEOUT on Windows these are per Machine or per Adapter
settings).

18.53 <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-18.53>.
Timestamp

   The Timestamp general-header describes when the agent sent the
   request.  The value of the timestamp is of significance only to the
   agent and may use any timescale.  The responding agent MUST echo the
   exact same value and MAY, if it has accurate information about this,
   add a floating point number indicating the number of seconds that has
   elapsed since it has received the request.  The timestamp can be used
   by the agent to compute the round-trip time to the responding agent

   so that it can adjust the timeout value for retransmissions when
   running over an unreliable protocol.  It also resolves retransmission
   ambiguities for unreliable transport of RTSP.

   Note that the present specification provides only for reliable
   transport of RTSP messages.  The Timestamp general-header is
   specified in case the protocol is extended in the future to use
   unreliable transport.

...

I already support Rtsp over UDP, I am not going to disable just
because there was a 'lack of interest', if I am interested or my
clients are we are going to use it.

I think the verbiage here is misleading 'in case the protocol is
extended in the future to use  unreliable transport.'  How can it be
that in the future when it was supported in previous versions?
Furthermore what happened to the nomenclature about disabling
re-tranmissions? Is that no longer required?

Also I don't need this header to compute "Round Trip Time" no does
anyone else NOR should it be used in place of the actual round trip
time as locally calculated, only the delay portion added by the server
is even remotely relevant.

Section 18.54 <http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40#section-18.54>.
Transport

...

ssrc: The ssrc parameter, if included in a SETUP response, indicates
         the RTP SSRC [RFC3550 <http://tools.ietf.org/html/rfc3550>]
value(s) that will be used by the media
         server for RTP packets within the stream.  It is expressed as
         an eight digit hexadecimal value.

         The ssrc parameter MUST NOT be specified in requests.  The
         functionality of specifying the ssrc parameter in a SETUP
         request is deprecated as it is incompatible with the
         specification of RTP in RFC 3550
<http://tools.ietf.org/html/rfc3550>[RFC3550
<http://tools.ietf.org/html/rfc3550>].  If the parameter is
         included in the Transport header of a SETUP request, the server
         SHOULD ignore it, and choose appropriate SSRCs for the stream.
         The server SHOULD set the ssrc parameter in the Transport
         header of the response.

Why is this not compatible? It would surely alleviate issues under TCP
where the first RTCP packet was received before the `PLAY` response.

Why should the client not be able to indicate it's 'ssrc' space to the
server to ensure a collision is not occurring?

Wouldn't it also be incompatible for the server to send the `ssrc` so
why is the semantic different for the client?

'RTCP-mux'

Can't a server just use a single client_port or use the same port twice?
e.g. "client_port=1234" OR "client_port=1234-1234"?

Can it at-least be stated that RTCP-mux would be equivalent to the above
syntax (since I do believe that's how it's achieved now anyhow)? If not
what is to be assumed if there is not a pair of ports? that Rtcp is
disabled?

Thank to those that are responding!

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 09 Jan 2015 22:24:59 -0500

> to deal with that as well.

Whew, you're going to have to slow down here.  I'm not tracking what you
say very well, but if I read it correctly, you're saying you want to
change the divisor in sections 3.1.5 and 3.1.6 from 8 to 256.  Is that
really correct?  And your justification seems to be that there are JPEGs
that are so large that their sizes can't be represented within an 8 bit
field with a multiplier of 8 (i.e., >2048).

If so, this isn't an erratum, but a technical change, and it would have
to go through the working group as an update to the RFC.  It would also
be incompatible with every implementation that now uses this feature.

In regard to "Fragment Offset", you seem to be allowing for JPEGs in
excess of 2^24 bytes, which seems to me to be unlikely within the
constraints of the existing height and width limitations.  In any case,
reducing Fragment Offset modulo 2^24 would make reassembly of large
frames ambiguous -- you'd really need a larger Fragment Offset field.

What you're really asking for here is an RTP payload format much like
RFC 2435 but different from it and incompatible with it.  That would be
a new piece of work, as well as requiring assignment of a new "encoding
name" so that control protocols could specify it.  (The "JPEG" encoding
name is assigned to RFC 2435 media by RFC 3551 section 5.2.)

Errata aren't for situations where "I think this protocol could have
been designed better", but where the *text* doesn't express what the
working group *meant*.

Dale

---

From: Julius Friedman <[email-masked]>
Date: Fri, 9 Jan 2015 22:49:42 -0500

What about another divisor and or some text which states that if there is a
modulo that the frame height may have to be computed alternately? The issue
is also for black and white images and situations where 1 or more than 2
quantization tables were used.. I included samples of those images in the
initial email to the IETF which were from the JPEG test suite the W3C used
and I can re-attach them if required, there is nothing "special" about them
other than the fact that:

1) they are not sized correctly after depacketization due to the size
constraint which makes ANY image which is not sized in multiples of 8
either larger or smaller which DOES effect decoding quality.
2) they do not display correctly due to a missing table or a absent table.

The fact that the header is fixed can probably be used to the advantage to
either use the MBZ in such a case or the DRI fields if it's not being used
BUT I think that is more complex and IT DOES make it incompatible, if the
FragmentOffset is used like I stated it WILL be compatible with existing
implementations and no change will be required. I know that larger field is
desirable but the 'trick' used does allow compatibility and correctly
sorting the offsets and obtaining their correct value during this 'roll
over' which is unlikely as you stated anyway and thus only given for such
cases as those....

The fact that the image is incorrect makes this errata, the fact that the
verbiage in the RFC also allows for  via (RFC2435)

4.1 <https://tools.ietf.org/html/rfc2435#section-4.1>.  The Type Field

Which makes this erratum because images which are advertised as supported
cannot be viewed or are distorted when the "reference" code is to be used
with such images and is NOT stated in the RFC....

Please advise.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Jan 2015 10:49:57 +0100

Hi,

I don't see any change to the actual text. The note part appears to be
suggestion for a non-backwards compatible change. As said before,
technical modifications to specifications are not done using the Errata
system. Instead one will have to write a new specification (Internet
Draft) that is taken through the WG and IESG approval.

As this is non-backwards compatible change, I think the most likely
outcome would be to use a new RTP payload identifier for this new format.

Please note that the correct WG for RTP Payload specification work is
the PAYLOAD WG.

My suggestion is that this errata is rejected.

Cheers

Magnus

On 2015-01-06 20:28, Dale R. Worley wrote:
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 29 Jan 2015 22:43:14 -0500

Julius Friedman <[email-masked]> writes:
> modulo that the frame height may have to be computed alternately?

I don't understand you here.  You seem to be proposing that another
divisor for representing JPEG size be used, 256 rather than 8.  But that
is an incompatible technical change.  In RFC 2435 there is not intended
to be any alternative way to represent the frame height and width.

> with such images and is NOT stated in the RFC....

As far as I can see, you mean to say that the RFC claims to be able to
be able to transmit JPEGs that it cannot.  Can you explain this in more
detail?  (My understanding is that the RFC provides an encoding method
for *some* JPEGs, that the image data is a stream of JPEGs, but not all
JPEGs can be used in RFC 2435 data streams.)

Dale

---

From: "Frederick, Ron" <[email-masked]>
Date: Fri, 30 Jan 2015 05:11:34 +0000

> to be any alternative way to represent the frame height and width.

I agree with this. I don’t see any way in which the divisor could be changed in a backward compatible manner. A different encoding would need to be proposed to do this, and that can't be done as an errata of RFC 2435.

> JPEGs can be used in RFC 2435 data streams.)

Mores specifically, the RFC only defines type values which allow you to encode YUV 4:2:2 and 4:2:0 JPEG images. It allows for the possibility of encoding images in other color spaces or with other sampling factors, but this would need to be done as an extension to RFC 2435 which defines these other items as new pre-defined type values, or by having an application use a dynamically defined type value in the range 128-255 (where both sender and receiver know how to interpret this dynamic value).
-- 
Ron Frederick
[email-masked]