[FFmpeg-devel] [PATCH] RTP H.264 invalid scaling dimension

Gordon Irlam gordonipub2
Mon Nov 2 23:14:40 CET 2009


On Mon, Nov 2, 2009 at 12:19 AM, Luca Abeni <lucabe72 at email.it> wrote:
> The patch looks correct to me, thanks for investigating this issue
> (I think this explains some bugs that have been reported in the past,
> too). If noone objects in 2 or 3 days, I'll commit it.
>
> However, I am a little bit surprised by this code... Can you please try
> to comment out the
> ? ? ? ?codec->width = atoi(buf1);
> ? ? ? ?codec->height = atoi(p + 1); // skip the -
> ? ? ? ?codec->pix_fmt = PIX_FMT_YUV420P;
> lines inside the "if (av_strstart(p, "framesize:", &p)) {" block,
> and see what happens?

I no longer have the Darwin Streaming Server I had been playing with,
however I am still able to test things out using the following public
RTP H.264 feed (which includes a "framesize" entry):

rtsp://video3.americafree.tv/AFTVCartoonsH264250.sdp

The complete command line I am using is:

./ffmpeg -i rtsp://video3.americafree.tv/AFTVCartoonsH264250.sdp -f
avi -acodec libmp3lame -ar 44100 -ab 32k -s 320x240 -vcodec libx264 -b
100k -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8
-subq 5 -trellis 1 -refs 1 -coder 0 -me_range 16 -keyint_min 25
-sc_threshold 40 -i_qfactor 0.71 -rc_eq 'blurCplx^(1-qComp)' -qcomp
0.6 -qmin 10 -qmax 51 -qdiff 4 -level 30 -aspect 320:240 -g 30 -async
2 -y /tmp/test.avi

Running this gives a variety of different error situations, the two
most common being:

It sometimes exits straight away (I don't think I saw this problem
previously using DSS and the reference sample_h264_300kbit.mp4 feed):
----
[libx264 @ 0x8e91e00]error, non monotone timestamps 1 >= 1
av_interleaved_write_frame(): Error while opening file
----

And it sometimes runs with PPS warnings:
----
[h264 @ 0xab3b040]number of reference frames exceeds max (probably
corrupt input), discarding one
    Last message repeated 13 times
[h264 @ 0xab3b040]non-existing PPS referenced
    Last message repeated 97 times
[h264 @ 0xab3b040]non-existing SPS 0 referenced in buffering period
[h264 @ 0xab3b040]non-existing PPS referenced
    Last message repeated 149 times
[h264 @ 0xab3b040]non-existing SPS 0 referenced in buffering period
[h264 @ 0xab3b040]non-existing PPS referenced
    Last message repeated 149 times
[h264 @ 0xab3b040]non-existing SPS 0 referenced in buffering period
[h264 @ 0xab3b040]non-existing PPS referenced
    Last message repeated 149 times
[h264 @ 0xab3b040]non-existing SPS 0 referenced in buffering period
[h264 @ 0xab3b040]non-existing PPS referenced
[...]
----

And to answer your question, yes I get the same results whether the
above 3 lines are commented out or not.

>> , although it gets numerous "non-existing PPS referenced"
>> errors, which I haven't yet been able to track down.
>
> Do you see these warnings only when you start playing the stream,
> or are they continuously repeated? Does your SDP contain an
> "sprop-parameters-set" entry?

Yes, these warnings occur repeatedly.  The SDP does contain an
sprop-parameter-sets.  According to openRTSP:

Opened URL "rtsp://video3.americafree.tv/AFTVCartoonsH264250.sdp",
returning a SDP description:
v=0
o=QTSS_Play_List 3061428413 3343886855 IN IP4 63.105.122.38
s=AFTVCartoonsH264250
c=IN IP4 0.0.0.0
b=AS:256
t=0 0
a=x-broadcastcontrol:RTSP
a=maxprate:36.000000
a=isma-compliance:2,2.0,2
a=control:*
m=video 0 RTP/AVP 96
b=AS:223
b=TIAS:215
a=3GPP-Adaptation-Support:1
a=maxprate:36
a=rtpmap:96 H264/90000
a=control:trackID=1
a=cliprect:0,0,240,320
a=framesize:96 320-240
a=fmtp:96 packetization-mode=1;profile-level-id=4D400D;sprop-parameter-sets=J01ADakYKD5gDUGAQa23oNgoXvfAQA==,KN4JiA==
a=mpeg4-esid:201
m=audio 0 RTP/AVP 97
b=AS:37
b=TIAS:34
a=3GPP-Adaptation-Support:1
a=maxprate:15
a=rtpmap:97 mpeg4-generic/16000/2
a=control:trackID=2
a=fmtp:97 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1410
a=mpeg4-esid:101

> Well, I cannot comment about the state of all the code (I believe the
> whole RTP demuxer has issues), but in my experience it generally works.
> This particular bug does not affect all the RTP H.264 streams, but only
> the ones containing a "framesize:" entry (which, as far as I know, is
> not mandatory). I used libavformat to receive some H.264 streams over
> RTP in the past, and it worked.
> (but keep in mind that there are issues if the RTP packets arrive in
> the wrong order, etc...)

OK.  Thanks for the info.

gordon



More information about the ffmpeg-devel mailing list