[FFmpeg-devel] MPEG Video support in RTP

Michael Niedermayer michaelni
Mon Aug 27 22:12:05 CEST 2007


Hi

On Fri, Aug 24, 2007 at 10:11:50AM +0200, Luca Abeni wrote:
> Hi,
>
> Luca Abeni wrote:
>> Hi Luca,
>> Luca Barbato wrote:
>> [...]
>>>> ops... Sorry, I've been too fast in sending the patch. I updated my 
>>>> local copy with the headers from rtp.{c,h}
>>>>
>>> If is still working as supposed please commit =)
>> Ok, thanks. I'll wait one day or two to give other people the possibility 
>> to comment, and then I'll commit.
>
> Ok, committed. Now, here are the interesting patches:
>
> - remove_header_extension.diff: the current code writes an empty payload 
> header extension if the video is MPEG2. However, this header is wrong 
> (filled with all 0s), and according to the standard "its inclusion in an 
> RTP packet is optional". Since removing this header we are still compliant 
> with RFC2250 (even in case of MPEG2 video), this patch is removing it.

id say looks ok unless our rtsp maintainer disagrees


>
> - fix_packetization.diff: this is the biggest patch. It ensures that a 
> video frame is correctly split on frame boundaries, according to RFC2250. 
> Note: the patch assumes that video sequence header, gop header, and picture 
> header if present are at the beginning of a frame (I think this is 
> guaranteed by the MPEG standard, right?), 

yes


> and that the first packet is big 
> enough to contain such headers.
> After applying this patch, the payload header is still wrong, but the frame 
> should be correctly packetized, and we have all the information needed to 
> fill the header. The patch is more complex than I would have liked, but 
> I've not been able to come out with something simpler than this... 
> Suggestions are welcome.
>

[...]

> - set_frame_type.diff: set the P field in the payload header. Note: in the 
> patch, I assume that the frame is well-formed (I consider writing a 
> non-well-formed frame similar to setting a wrong "size" field in AVPacket). 
> Is this reasonable? If not, I'll add a check when reading frame_type

yes you can assume that the stream is valid mpeg2 ...

[...]
>      while (size > 0) {
>          /* XXX: more correct headers */
>          h = 0;
>          q = s->buf;
> +        len = FFMIN(max_packet_size - (q - s->buf), size);
> +        if (len == size) {
> +            end_of_slice = 1;
> +        } else {
> +            const uint8_t *r, *r1;
> +            int start_code, done;
> +
> +            r1 = buf1;
> +            done = 0;
> +            while (!done) {
> +                start_code = -1;
> +                r = ff_find_start_code(r1, buf1 + size, &start_code);
> +                if((start_code & 0xFFFFFF00) == 0x100) {
> +                    /* New start code found */
> +                    if (r - buf1 - 4 < len) {
> +                        /* The current slice fits in the packet */
> +                        if (begin_of_slice == 0) {
> +                            /* no slice at the beginning of the packet... */
> +                            done = 1;
> +                            end_of_slice = 1;
> +                            len = r1 - buf1 - 4;
> +                        }
> +                        r1 = r;
> +                    } else {
> +                        done = 1;
> +                    }
> +                } else {
> +                    done = 1;
> +                }
> +            }
> +        }

if i understand this correctly it will never put more than 1 slice in a
packet, this is bad in case slices are small VERY bad
mpeg2 _requires_ 1 slice per MB row at minimum so a 352x288 mpeg 2 video
at 25fps would need 450 packets per second even if its just lets say
100kbit/sec thats 28 byte of the mpeg2 per packet on average ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070827/96d0e0ed/attachment.pgp>



More information about the ffmpeg-devel mailing list