MultimediaWiki - User contributions [en]

Sorenson Video 3

2010-10-03T18:24:25Z

Josh: /* Packetization */

* FOURCCs: SVQ3
* Company: [[Sorenson Media]]
* Samples: [http://samples.mplayerhq.hu/V-codecs/SVQ3/ http://samples.mplayerhq.hu/V-codecs/SVQ3/]

Video codec apparently based on an early H.264 draft.

== Decoding Process ==
This codec extensively uses [[Golomb]] coding.

=== Slice Header ===
'''TODO'''

=== Macroblock layer ===
Each macroblock starts with [[Golomb]] code signalling MB type:
* 0 - skip block
* 1-7 - inter 16x16 blocks, type specifies prediction direction
* 8 and 33 - intra 4x4 block (type 33 means that there are no coefficients for this block)
* 9-32 - intra 16x16 blocks, type is used to set prediction direction and coded block pattern
In any case coefficients are stored in 4x4 (sub)blocks.

Dezigzag pattern (from [[H.264]]):

o-->o-->o o
| /|
o o o / o
| / | |/ |
o o o o
/
o-->o-->o-->o

=== Coefficient decoding ===
Each coefficient is stored as [[Golomb]] codeword, last bit is coefficient sign, code = 0 means end of nonzero coefficients.

Codes for block type 3:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! code !! run !! value
|-
| 0-2
| 0
| '''code'''
|-
| 3
| 1
| 1
|-
| 4-...
| '''code''' & 0x3
| (('''code''' + 9) >> 2) - '''run'''
|}

Codes for intra block types:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! code !! run !! value
|-
| 0 || 0 || 0
|-
| 1 || 0 || 1
|-
| 2 || 1 || 1
|-
| 3 || 0 || 2
|-
| 4 || 2 || 1
|-
| 5 || 0 || 3
|-
| 6 || 0 || 4
|-
| 7 || 0 || 5
|-
| 8 || 3 || 1
|-
| 9 || 4 || 1
|-
| 10 || 1 || 2
|-
| 11 || 1 || 3
|-
| 12 || 0 || 6
|-
| 13 || 0 || 7
|-
| 14 || 0 || 8
|-
| 15 || 0 || 9
|-
| 16-...
| '''code''' & 0x7
| ('''code''' >> 3) - intra_run['''run''']
|}

Codes for inter block types:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! code !! run !! value
|-
| 0 || 0 || 0
|-
| 1 || 0 || 1
|-
| 2 || 1 || 1
|-
| 3 || 2 || 1
|-
| 4 || 0 || 2
|-
| 5 || 3 || 1
|-
| 6 || 4 || 1
|-
| 7 || 5 || 1
|-
| 8 || 0 || 3
|-
| 9 || 1 || 2
|-
| 10 || 2 || 2
|-
| 11 || 6 || 1
|-
| 12 || 7 || 1
|-
| 13 || 8 || 1
|-
| 14 || 9 || 1
|-
| 15 || 0 || 4
|-
| 16-... (inter)
| '''code''' & 0xF
| ('''code''' >> 4) - inter_run['''run''']
|}

Run correction values:
intra_run = { 8, 2, 0, 0, 0, -1, -1, -1, [minus ones] };
inter_run = { 4, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, [zeroes] };

=== Macroblock transform and dequantization ===

Transform coefficients:

13 17 1 7
13 7 -1 -17
13 -7 -1 17
13 -17 1 -7

Dequantization is performed by multiplying every coefficient by the same value determined by quantizer.
In case if inter blocks first coefficient may be quantized slightly differently:

For some intra blocks ('''TODO''': condition):
dc = 169 * 1538 * block[0]
For chroma blocks (?):
dc = (svq3_dequant_coeff[Q] * (block[0] >> 3)) >> 1;

Quantizer table (from svq3.c)

static const uint32_t svq3_dequant_coeff[32] = {
3881, 4351, 4890, 5481, 6154, 6914, 7761, 8718,
9781, 10987, 12339, 13828, 15523, 17435, 19561, 21873,
24552, 27656, 30847, 34870, 38807, 43747, 49103, 54683,
61694, 68745, 77615, 89113,100253,109366,126635,141533
};

Dequantization formula (dc=0 if not defined otherwise):
out = (coeff * svq3_dequant_coeff[Q] + dc + 0x80000) >> 20;

== Packetization ==
The first byte of a SVQ3 RTP packet indicates the packet type(s). This is after the standard RTP headers.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! 1st byte value !! packet type
|-
| 0x40 || config
|-
| 0x20 || start
|-
| 0x10 || end
|}

Note that a packet may have more than one type. Config packets are in practice transmitted individually since they do not contain additional video data beyond extradata.

The second byte of a SVQ3 RTP packet is ignored. This is likely reserved for future use.

All subsequent bytes are payload data.

SVQ3 does not make use of SDP FMTP attributes to carry codec-specific extradata; rather, this is carried within the RTP itself in config packets. Also, SVQ3 decoders expect extradata to be prefixed with the marker bytes "SEQH", followed by another 4 bytes indicating the length of the extradata. Neither are provided by the payload, and must be inserted by the depacketizer prior to decoding. The rest of the payload data is standard SVQ3 extradata. (todo: explain 'standard svq3 extradata'?)

Start packets come with a new RTP timestamp, and config packets may be periodically re-transmitted before a keyframe.

End packets simply indicate that the payload data constitutes the remainder of a SVQ3 frame.

[[Category:Video Codecs]]

Snow

2010-09-11T23:09:55Z

Josh: Update link to technical description

* FourCC: SNOW
* Website: http://ffmpeg.org/
* Samples: [http://samples.mplayerhq.hu/V-codecs/SNOW/ http://samples.mplayerhq.hu/V-codecs/SNOW/]
* incomplete Technical Description: http://git.ffmpeg.org/?p=ffmpeg;a=blob_plain;f=doc/snow.txt

Snow is a lossy and lossless video codec, (originated in the [[FFmpeg]] project). Snow features wavelet transform, overlapping block-based motion-compensation, and entropy coding that is not based on Huffman coding. It shares with [[Dirac]] the choice of wavelets but it is quite simpler and with less optional features. At the present the ffmpeg implementation of Snow is partially optimized for x86, AMD64 and PPC and is only suited for high-end systems.

Snow has not reached version 1.0 and thus is in an experimental state as of August 2008. There are some [[FFmpeg_Summer_Of_Code_2008#Snow_Job|tasks left]] for a final 1.0 version.

[[Category:Video Codecs]]
[[Category:Wavelet Video Codecs]]

Improve RTSP/RTP layer

2010-07-08T08:48:10Z

Josh:

Roadmap/checklist for Josh Allmann's Summer of Code Project:

* Primary goal: improve the receiver compatibility
** Add support for more widespread formats ([list will follow check gst live555 and feng])
*** X-Qt/quicktime depacketizer (see [http://www.gnome.org/~rbultje/ffmpeg-patchset/ X-QT patch])
*** SVQ3 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073511.html] and QDM2 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073826.html] depacketizers
****SVQ3 patch committed, QDM2 in progress
*** VP8 (see https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/550f946b0e22ead2# )
** support Quicktime http tunnel mode
*** Initial implementation done and committed, not supported in the RTSP muxer yet, missing handling of the x-server-ip-address header
** untangle the AAC and mpeg4 format specific code from rtsp.c, make them proper dynamic payload handlers
*** Committed
** factorize out common code for parsing SDP (fmtp) lines, that is duplicated in parse_h264_sdp_line, amr_parse_sdp_line and xiph_parse_sdp_line
***Committed
** add RTP packetizers for codecs that we already have depacketizers for (Theora, Vorbis, SVQ3, QDM2, any other? - VP8, in parallel with the depacketizer for that)
** Real RTSP-HTTP, with port knocking
** support RTCP/Bye as end-of-file (see [[Small_FFmpeg_Tasks#Make_the_rtp_demuxer_support_rtcp_BYE_packets|small task]])
* Secondary goal: improve application integration
** Provide an API to expose the rtcp layer (and the equivalent in RDT dialect)
** Try to support subtitle streams (either as rtcp-xr or application/text stream)
** Make VideoLanClient, MPlayer or Xine use FFmpeg RTSP
*** Patch submitted to VLC, awaiting review
** Implement protocol variations (e.g. DCCP or improve SCTP)
** Untangle MPEG2-TS/RTP from rtpdec into a dynamic payload handler. Write a packetizer first, unless we find such a server to test against.
** Reduce ffrtsp startup time
** Small Xiph RTP optimization: avoid the extra memcpy to packet; instead, hook av_init_packet up to url_close_dyn_buf

''Mentor: Luca Barbato, Martin Storsjö, Ronald S. Bultje''

Sorenson Video 3

2010-07-01T09:29:20Z

Josh: /* Packetization */

* FOURCCs: SVQ3
* Company: [[Sorenson Media]]
* Samples: [http://samples.mplayerhq.hu/V-codecs/SVQ3/ http://samples.mplayerhq.hu/V-codecs/SVQ3/]

Video codec apparently based on an early H.264 draft.

== Decoding Process ==
This codec extensively uses [[Golomb]] coding.

=== Slice Header ===
'''TODO'''

=== Macroblock layer ===
Each macroblock starts with [[Golomb]] code signalling MB type:
* 0 - skip block
* 1-7 - inter 16x16 blocks, type specifies prediction direction
* 8 and 33 - intra 4x4 block (type 33 means that there are no coefficients for this block)
* 9-32 - intra 16x16 blocks, type is used to set prediction direction and coded block pattern
In any case coefficients are stored in 4x4 (sub)blocks.

Dezigzag pattern (from [[H.264]]):

o-->o-->o o
| /|
o o o / o
| / | |/ |
o o o o
/
o-->o-->o-->o

=== Coefficient decoding ===
Each coefficient is stored as [[Golomb]] codeword, last bit is coefficient sign, code = 0 means end of nonzero coefficients.

Codes for block type 3:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! code !! run !! value
|-
| 0-2
| 0
| '''code'''
|-
| 3
| 1
| 1
|-
| 4-...
| '''code''' & 0x3
| (('''code''' + 9) >> 2) - '''run'''
|}

Codes for intra block types:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! code !! run !! value
|-
| 0 || 0 || 0
|-
| 1 || 0 || 1
|-
| 2 || 1 || 1
|-
| 3 || 0 || 2
|-
| 4 || 2 || 1
|-
| 5 || 0 || 3
|-
| 6 || 0 || 4
|-
| 7 || 0 || 5
|-
| 8 || 3 || 1
|-
| 9 || 4 || 1
|-
| 10 || 1 || 2
|-
| 11 || 1 || 3
|-
| 12 || 0 || 6
|-
| 13 || 0 || 7
|-
| 14 || 0 || 8
|-
| 15 || 0 || 9
|-
| 16-...
| '''code''' & 0x7
| ('''code''' >> 3) - intra_run['''run''']
|}

Codes for inter block types:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! code !! run !! value
|-
| 0 || 0 || 0
|-
| 1 || 0 || 1
|-
| 2 || 1 || 1
|-
| 3 || 2 || 1
|-
| 4 || 0 || 2
|-
| 5 || 3 || 1
|-
| 6 || 4 || 1
|-
| 7 || 5 || 1
|-
| 8 || 0 || 3
|-
| 9 || 1 || 2
|-
| 10 || 2 || 2
|-
| 11 || 6 || 1
|-
| 12 || 7 || 1
|-
| 13 || 8 || 1
|-
| 14 || 9 || 1
|-
| 15 || 0 || 4
|-
| 16-... (inter)
| '''code''' & 0xF
| ('''code''' >> 4) - inter_run['''run''']
|}

Run correction values:
intra_run = { 8, 2, 0, 0, 0, -1, -1, -1, [minus ones] };
inter_run = { 4, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, [zeroes] };

=== Macroblock transform and dequantization ===

Transform coefficients:

13 17 1 7
13 7 -1 -17
13 -7 -1 17
13 -17 1 -7

Dequantization is performed by multiplying every coefficient by the same value determined by quantizer.
In case if inter blocks first coefficient may be quantized slightly differently:

For some intra blocks ('''TODO''': condition):
dc = 169 * 1538 * block[0]
For chroma blocks (?):
dc = (svq3_dequant_coeff[Q] * (block[0] >> 3)) >> 1;

Quantizer table (from svq3.c)

static const uint32_t svq3_dequant_coeff[32] = {
3881, 4351, 4890, 5481, 6154, 6914, 7761, 8718,
9781, 10987, 12339, 13828, 15523, 17435, 19561, 21873,
24552, 27656, 30847, 34870, 38807, 43747, 49103, 54683,
61694, 68745, 77615, 89113,100253,109366,126635,141533
};

Dequantization formula (dc=0 if not defined otherwise):
out = (coeff * svq3_dequant_coeff[Q] + dc + 0x80000) >> 20;

== Packetization ==
The first byte of a SVQ3 RTP packet indicates the packet type(s). This is after the standard RTP headers.

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! 1st byte value !! packet type
|-
| 0x40 || config
|-
| 0x20 || start
|-
| 0x10 || end
|}

Note that a packet may have more than one type. Config packets are in practice transmitted individually since they do not contain additional video data beyond extradata.

The second byte of a SVQ3 RTP packet is ignored. This is likely reserved for future use.

All subsequent bytes are payload data.

SVQ3 does not make use of SDP FMTP attributes to carry codec-specific extradata; rather, this is carried within the RTP itself in config packets. Also, SVQ3 decoders expect extradata to be prefixed with the marker bytes "SEQH", followed by another 4 bytes indicating the length of the extradata. Neither are provided by the payload, and must be inserted by the depacketizer prior to decoding. The rest of the payload data is standard SVQ3 extradata. (todo: explain 'standard svq3 extradata'?)

Start packets come with a new RTP timestamp, and the RTP marker bit indicates whether the payload data is a keyframe. Config packets may be periodically re-transmitted before a keyframe.

End packets simply indicate that the payload data constitutes the remainder of a SVQ3 frame.

[[Category:Video Codecs]]

Sorenson Video 3

2010-07-01T07:53:26Z

Josh:

* FOURCCs: SVQ3
* Company: [[Sorenson Media]]
* Samples: [http://samples.mplayerhq.hu/V-codecs/SVQ3/ http://samples.mplayerhq.hu/V-codecs/SVQ3/]

Video codec apparently based on an early H.264 draft.

== Decoding Process ==
This codec extensively uses [[Golomb]] coding.

=== Slice Header ===
'''TODO'''

=== Macroblock layer ===
Each macroblock starts with [[Golomb]] code signalling MB type:
* 0 - skip block
* 1-7 - inter 16x16 blocks, type specifies prediction direction
* 8 and 33 - intra 4x4 block (type 33 means that there are no coefficients for this block)
* 9-32 - intra 16x16 blocks, type is used to set prediction direction and coded block pattern
In any case coefficients are stored in 4x4 (sub)blocks.

Dezigzag pattern (from [[H.264]]):

o-->o-->o o
| /|
o o o / o
| / | |/ |
o o o o
/
o-->o-->o-->o

=== Coefficient decoding ===
Each coefficient is stored as [[Golomb]] codeword, last bit is coefficient sign, code = 0 means end of nonzero coefficients.

Codes for block type 3:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! code !! run !! value
|-
| 0-2
| 0
| '''code'''
|-
| 3
| 1
| 1
|-
| 4-...
| '''code''' & 0x3
| (('''code''' + 9) >> 2) - '''run'''
|}

Codes for intra block types:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! code !! run !! value
|-
| 0 || 0 || 0
|-
| 1 || 0 || 1
|-
| 2 || 1 || 1
|-
| 3 || 0 || 2
|-
| 4 || 2 || 1
|-
| 5 || 0 || 3
|-
| 6 || 0 || 4
|-
| 7 || 0 || 5
|-
| 8 || 3 || 1
|-
| 9 || 4 || 1
|-
| 10 || 1 || 2
|-
| 11 || 1 || 3
|-
| 12 || 0 || 6
|-
| 13 || 0 || 7
|-
| 14 || 0 || 8
|-
| 15 || 0 || 9
|-
| 16-...
| '''code''' & 0x7
| ('''code''' >> 3) - intra_run['''run''']
|}

Codes for inter block types:
{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! code !! run !! value
|-
| 0 || 0 || 0
|-
| 1 || 0 || 1
|-
| 2 || 1 || 1
|-
| 3 || 2 || 1
|-
| 4 || 0 || 2
|-
| 5 || 3 || 1
|-
| 6 || 4 || 1
|-
| 7 || 5 || 1
|-
| 8 || 0 || 3
|-
| 9 || 1 || 2
|-
| 10 || 2 || 2
|-
| 11 || 6 || 1
|-
| 12 || 7 || 1
|-
| 13 || 8 || 1
|-
| 14 || 9 || 1
|-
| 15 || 0 || 4
|-
| 16-... (inter)
| '''code''' & 0xF
| ('''code''' >> 4) - inter_run['''run''']
|}

Run correction values:
intra_run = { 8, 2, 0, 0, 0, -1, -1, -1, [minus ones] };
inter_run = { 4, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, [zeroes] };

=== Macroblock transform and dequantization ===

Transform coefficients:

13 17 1 7
13 7 -1 -17
13 -7 -1 17
13 -17 1 -7

Dequantization is performed by multiplying every coefficient by the same value determined by quantizer.
In case if inter blocks first coefficient may be quantized slightly differently:

For some intra blocks ('''TODO''': condition):
dc = 169 * 1538 * block[0]
For chroma blocks (?):
dc = (svq3_dequant_coeff[Q] * (block[0] >> 3)) >> 1;

Quantizer table (from svq3.c)

static const uint32_t svq3_dequant_coeff[32] = {
3881, 4351, 4890, 5481, 6154, 6914, 7761, 8718,
9781, 10987, 12339, 13828, 15523, 17435, 19561, 21873,
24552, 27656, 30847, 34870, 38807, 43747, 49103, 54683,
61694, 68745, 77615, 89113,100253,109366,126635,141533
};

Dequantization formula (dc=0 if not defined otherwise):
out = (coeff * svq3_dequant_coeff[Q] + dc + 0x80000) >> 20;

== Packetization ==
The first byte of a SVQ3 RTP packet indicates the packet type(s).

{| border="1" cellpadding="5" style="border-collapse: collapse; border-style: dashed; border-color: #2f6fab;"
|- bgcolor="#f0f0f0" |
! 1st byte value !! packet type
|-
| 0x40 || config
|-
| 0x20 || start
|-
| 0x10 || end
|}

Note that a packet may have more than one type. Config packets are in practice transmitted individually since they do not contain additional video data beyond extradata.

The second byte of a SVQ3 RTP packet is ignored. This is likely reserved for future use.

All subsequent bytes are payload data.

SVQ3 does not make use of SDP FMTP attributes to carry codec-specific extradata; rather, this is carried within the RTP itself in config packets. Also, SVQ3 decoders expect extradata to be prefixed with the marker bytes "SEQH", followed by another 4 bytes indicating the length of the extradata. Neither are provided by the payload, and must be inserted by the depacketizer prior to decoding. The rest of the payload data is standard SVQ3 extradata. (todo: explain 'standard svq3 extradata'?)

Start packets come with a new RTP timestamp, and the RTP marker bit indicates whether the payload data is a keyframe. Config packets may be periodically re-transmitted before a keyframe.

End packets simply indicate that the payload data constitutes the remainder of a SVQ3 frame.

[[Category:Video Codecs]]

Improve RTSP/RTP layer

2010-06-30T08:04:48Z

Josh:

Roadmap/checklist for Josh Allmann's Summer of Code Project:

* Primary goal: improve the receiver compatibility
** Add support for more widespread formats ([list will follow check gst live555 and feng])
*** X-Qt/quicktime depacketizer (see [http://www.gnome.org/~rbultje/ffmpeg-patchset/ X-QT patch])
*** SVQ3 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073511.html] and QDM2 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073826.html] depacketizers
****SVQ3 patch submitted, QDM2 in progress
*** VP8 (see https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/550f946b0e22ead2# )
** support Quicktime http tunnel mode
*** Initial implementation done and committed, not supported in the RTSP muxer yet, missing handling of the x-server-ip-address header
** untangle the AAC and mpeg4 format specific code from rtsp.c, make them proper dynamic payload handlers
*** Committed
** factorize out common code for parsing SDP (fmtp) lines, that is duplicated in parse_h264_sdp_line, amr_parse_sdp_line and xiph_parse_sdp_line
***Committed
** add RTP packetizers for codecs that we already have depacketizers for (Theora, Vorbis, any other? - VP8, in parallel with the depacketizer for that)
** Real RTSP-HTTP, with port knocking
** support RTCP/Bye as end-of-file (see [[Small_FFmpeg_Tasks#Make_the_rtp_demuxer_support_rtcp_BYE_packets|small task]])
* Secondary goal: improve application integration
** Provide an API to expose the rtcp layer (and the equivalent in RDT dialect)
** Try to support subtitle streams (either as rtcp-xr or application/text stream)
** Make VideoLanClient, MPlayer or Xine use FFmpeg RTSP
*** Patch submitted to VLC, awaiting review
** Implement protocol variations (e.g. DCCP or improve SCTP)
** Untangle MPEG2-TS/RTP from rtpdec into a dynamic payload handler. Write a packetizer first, unless we find such a server to test against.
** Reduce ffrtsp startup time
** Small Xiph RTP optimization: avoid the extra memcpy to packet; instead, hook av_init_packet up to url_close_dyn_buf

''Mentor: Luca Barbato, Martin Storsjö, Ronald S. Bultje''

Improve RTSP/RTP layer

2010-06-29T16:55:50Z

Josh:

Roadmap/checklist for Josh Allmann's Summer of Code Project:

* Primary goal: improve the receiver compatibility
** Add support for more widespread formats ([list will follow check gst live555 and feng])
*** X-Qt/quicktime depacketizer (see [http://www.gnome.org/~rbultje/ffmpeg-patchset/ X-QT patch])
*** SVQ3 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073511.html] and QDM2 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073826.html] depacketizers
*** VP8 (see https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/550f946b0e22ead2# )
** support Quicktime http tunnel mode
*** Initial implementation done and committed, not supported in the RTSP muxer yet, missing handling of the x-server-ip-address header
** untangle the AAC and mpeg4 format specific code from rtsp.c, make them proper dynamic payload handlers
*** Committed
** factorize out common code for parsing SDP (fmtp) lines, that is duplicated in parse_h264_sdp_line, amr_parse_sdp_line and xiph_parse_sdp_line
***Committed
** add RTP packetizers for codecs that we already have depacketizers for (Theora, Vorbis, any other? - VP8, in parallel with the depacketizer for that)
** Real RTSP-HTTP, with port knocking
** support RTCP/Bye as end-of-file (see [[Small_FFmpeg_Tasks#Make_the_rtp_demuxer_support_rtcp_BYE_packets|small task]])
* Secondary goal: improve application integration
** Provide an API to expose the rtcp layer (and the equivalent in RDT dialect)
** Try to support subtitle streams (either as rtcp-xr or application/text stream)
** Make VideoLanClient, MPlayer or Xine use FFmpeg RTSP
*** Patch submitted to VLC, awaiting review
** Implement protocol variations (e.g. DCCP or improve SCTP)
** Untangle MPEG2-TS/RTP from rtpdec into a dynamic payload handler. Write a packetizer first, unless we find such a server to test against.
** Reduce ffrtsp startup time
** Small Xiph RTP optimization: avoid the extra memcpy to packet; instead, hook av_init_packet up to url_close_dyn_buf

''Mentor: Luca Barbato, Martin Storsjö, Ronald S. Bultje''

Improve RTSP/RTP layer

2010-06-29T16:42:20Z

Josh:

Roadmap/checklist for Josh Allmann's Summer of Code Project:

* Primary goal: improve the receiver compatibility
** Add support for more widespread formats ([list will follow check gst live555 and feng])
*** X-Qt/quicktime depacketizer (see [http://www.gnome.org/~rbultje/ffmpeg-patchset/ X-QT patch])
*** SVQ3 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073511.html] and QDM2 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073826.html] depacketizers
*** VP8 (see https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/550f946b0e22ead2# )
** support Quicktime http tunnel mode
*** Initial implementation done and committed, not supported in the RTSP muxer yet, missing handling of the x-server-ip-address header
** untangle the AAC and mpeg4 format specific code from rtsp.c, make them proper dynamic payload handlers
*** Committed
** factorize out common code for parsing SDP (fmtp) lines, that is duplicated in parse_h264_sdp_line, amr_parse_sdp_line and xiph_parse_sdp_line
***Committed
** add RTP packetizers for codecs that we already have depacketizers for (Theora, Vorbis, any other? - VP8, in parallel with the depacketizer for that)
** Real RTSP-HTTP, with port knocking
** support RTCP/Bye as end-of-file (see [[Small_FFmpeg_Tasks#Make_the_rtp_demuxer_support_rtcp_BYE_packets|small task]])
* Secondary goal: improve application integration
** Provide an API to expose the rtcp layer (and the equivalent in RDT dialect)
** Try to support subtitle streams (either as rtcp-xr or application/text stream)
** Make VideoLanClient, MPlayer or Xine use FFmpeg RTSP
*** Patch submitted to VLC, awaiting review
** Implement protocol variations (e.g. DCCP or improve SCTP)
** Untangle MPEG2-TS/RTP from rtpdec into a dynamic payload handler. Write a packetizer first, unless we find such a server to test against.
** Small Xiph RTP optimization: avoid the extra memcpy to packet; instead, hook av_init_packet up to url_close_dyn_buf

''Mentor: Luca Barbato, Martin Storsjö, Ronald S. Bultje''

Improve RTSP/RTP layer

2010-06-29T16:42:02Z

Josh:

Roadmap/checklist for Josh Allmann's Summer of Code Project:

* Primary goal: improve the receiver compatibility
** Add support for more widespread formats ([list will follow check gst live555 and feng])
*** X-Qt/quicktime depacketizer (see [http://www.gnome.org/~rbultje/ffmpeg-patchset/ X-QT patch])
*** SVQ3 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073511.html] and QDM2 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073826.html] depacketizers
*** VP8 (see https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/550f946b0e22ead2# )
** support Quicktime http tunnel mode
*** Initial implementation done and committed, not supported in the RTSP muxer yet, missing handling of the x-server-ip-address header
** untangle the AAC and mpeg4 format specific code from rtsp.c, make them proper dynamic payload handlers
*** Committed
** factorize out common code for parsing SDP (fmtp) lines, that is duplicated in parse_h264_sdp_line, amr_parse_sdp_line and xiph_parse_sdp_line
***Committed
** add RTP packetizers for codecs that we already have depacketizers for (Theora, Vorbis, any other? - VP8, in parallel with the depacketizer for that)
** Real RTSP-HTTP, with port knocking
** support RTCP/Bye as end-of-file (see [[Small_FFmpeg_Tasks#Make_the_rtp_demuxer_support_rtcp_BYE_packets|small task]])
* Secondary goal: improve application integration
** Provide an API to expose the rtcp layer (and the equivalent in RDT dialect)
** Try to support subtitle streams (either as rtcp-xr or application/text stream)
** Make VideoLanClient, MPlayer or Xine use FFmpeg RTSP
*** Patch submitted to VLC, awaiting review
** Implement protocol variations (e.g. DCCP or improve SCTP)
** Untangle MPEG2-TS/RTP from rtpdec into a dynamic payload handler. Write a packetizer first, unless we find such a server to test against.
** Small Theora RTP optimization: avoid the extra memcpy to packet; instead, hook av_init_packet up to url_close_dyn_buf

''Mentor: Luca Barbato, Martin Storsjö, Ronald S. Bultje''

Improve RTSP/RTP layer

2010-06-29T16:41:35Z

Josh:

Roadmap/checklist for Josh Allmann's Summer of Code Project:

* Primary goal: improve the receiver compatibility
** Add support for more widespread formats ([list will follow check gst live555 and feng])
*** X-Qt/quicktime depacketizer (see [http://www.gnome.org/~rbultje/ffmpeg-patchset/ X-QT patch])
*** SVQ3 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073511.html] and QDM2 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073826.html] depacketizers
*** VP8 (see https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/550f946b0e22ead2# )
** support Quicktime http tunnel mode
*** Initial implementation done and committed, not supported in the RTSP muxer yet, missing handling of the x-server-ip-address header
** untangle the AAC and mpeg4 format specific code from rtsp.c, make them proper dynamic payload handlers
*** Committed
** factorize out common code for parsing SDP (fmtp) lines, that is duplicated in parse_h264_sdp_line, amr_parse_sdp_line and xiph_parse_sdp_line
***Committed
** add RTP packetizers for codecs that we already have depacketizers for (Theora, Vorbis, any other? - VP8, in parallel with the depacketizer for that)
** Real RTSP-HTTP, with port knocking
** support RTCP/Bye as end-of-file (see [[Small_FFmpeg_Tasks#Make_the_rtp_demuxer_support_rtcp_BYE_packets|small task]])
* Secondary goal: improve application integration
** Provide an API to expose the rtcp layer (and the equivalent in RDT dialect)
** Try to support subtitle streams (either as rtcp-xr or application/text stream)
** Make VideoLanClient, MPlayer or Xine use FFmpeg RTSP
*** Patch submitted to VLC, awaiting review
** Implement protocol variations (e.g. DCCP or improve SCTP)
** Untangle MPEG2-TS/RTP from rtpdec into a dynamic payload handler. Write a packetizer first, unless we find such a server to test against.
*** Small Theora RTP optimization: avoid the extra memcpy to packet; instead, hook av_init_packet up to url_close_dyn_buf

''Mentor: Luca Barbato, Martin Storsjö, Ronald S. Bultje''

Improve RTSP/RTP layer

2010-06-26T05:26:19Z

Josh:

Roadmap/checklist for Josh Allmann's Summer of Code Project:

* Primary goal: improve the receiver compatibility
** Add support for more widespread formats ([list will follow check gst live555 and feng])
*** X-Qt/quicktime depacketizer (see [http://www.gnome.org/~rbultje/ffmpeg-patchset/ X-QT patch])
*** SVQ3 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073511.html] and QDM2 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073826.html] depacketizers
*** VP8 (see https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/550f946b0e22ead2# )
** support Quicktime http tunnel mode
*** Initial implementation done and committed, not supported in the RTSP muxer yet, missing handling of the x-server-ip-address header
** untangle the AAC and mpeg4 format specific code from rtsp.c, make them proper dynamic payload handlers
*** Committed
** factorize out common code for parsing SDP (fmtp) lines, that is duplicated in parse_h264_sdp_line, amr_parse_sdp_line and xiph_parse_sdp_line
***Patches submitted for H.264 and MPEG-4/AAC, Xiph and AMR left
** add RTP packetizers for codecs that we already have depacketizers for (Theora, Vorbis, any other?)
** support RTCP/Bye as end-of-file (see [[Small_FFmpeg_Tasks#Make_the_rtp_demuxer_support_rtcp_BYE_packets|small task]])
* Secondary goal: improve application integration
** Provide an API to expose the rtcp layer (and the equivalent in RDT dialect)
** Try to support subtitle streams (either as rtcp-xr or application/text stream)
** Make VideoLanClient, MPlayer or Xine use FFmpeg RTSP
*** Patch submitted to VLC, awaiting review
** Implement protocol variations (e.g. DCCP or improve SCTP)
** Untangle MPEG2-TS/RTP from rtpdec into a dynamic payload handler. Write a packetizer first, unless we find such a server to test against.

''Mentor: Luca Barbato, Martin Storsjö, Ronald S. Bultje''

Improve RTSP/RTP layer

2010-06-25T22:37:22Z

Josh:

Roadmap/checklist for Josh Allmann's Summer of Code Project:

* Primary goal: improve the receiver compatibility
** Add support for more widespread formats ([list will follow check gst live555 and feng])
*** X-Qt/quicktime depacketizer (see [http://www.gnome.org/~rbultje/ffmpeg-patchset/ X-QT patch])
*** SVQ3 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073511.html] and QDM2 [http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073826.html] depacketizers
*** VP8 (see https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/550f946b0e22ead2# )
** support Quicktime http tunnel mode
*** Initial implementation done and committed, not supported in the RTSP muxer yet, missing handling of the x-server-ip-address header
** untangle the AAC and mpeg4 format specific code from rtsp.c, make them proper dynamic payload handlers
*** Committed
** factorize out common code for parsing SDP (fmtp) lines, that is duplicated in parse_h264_sdp_line, amr_parse_sdp_line and xiph_parse_sdp_line
***Patches submitted for H.264 and MPEG-4/AAC, Xiph and AMR left
** add RTP packetizers for codecs that we already have depacketizers for (Theora, Vorbis, any other?)
** support RTCP/Bye as end-of-file (see [[Small_FFmpeg_Tasks#Make_the_rtp_demuxer_support_rtcp_BYE_packets|small task]])
* Secondary goal: improve application integration
** Provide an API to expose the rtcp layer (and the equivalent in RDT dialect)
** Try to support subtitle streams (either as rtcp-xr or application/text stream)
** Make VideoLanClient, MPlayer or Xine use FFmpeg RTSP
*** Patch submitted to VLC, awaiting review
** Implement protocol variations (e.g. DCCP or improve SCTP)
** Untangle MPEG2-TS/RTP from rtpdec into a dynamic payload handler

''Mentor: Luca Barbato, Martin Storsjö, Ronald S. Bultje''

Improve RTSP/RTP layer

2010-06-20T19:53:56Z

Josh: