Hi,
Stas Oskin wrote:
[...]
>> Uhm... This is strange. Does the ffmpeg command work correctly when you add
>> "-vglobal 1"?
>
> Yes, it works fine. By the way, it works without the flag too - is it
> because VLC ignores out-band if in-band is present?
No, it is because vlc supports both in-band and out-of-band global headers:
you can decide which method you want to use (by adding/removing "-vglobal 1")
and vlc will correctly parse the SDP and behave accordingly.
>> Are you using the same exact libx264 parameters in your application and
>> in the ffmpeg example?
>
> Yes, I believe so (using default params for everything, with the
> exception of +loop for better quality).
Maybe that's the difference which is creating the problem...
[...]
>> This might happen when the SPS and PPS described in the SDP do not match
>> the stream you are sending... Try to generate the SDP in your application
>> by calling avf_sdp_create(), just to be sure that there is no mismatch.
>
> Problem is, avf_sdp_create() generates only the first several lines of the
> SDP:
>
> v=0
> o=- 0 0 IN IPV4 127.0.0.1
> t=0 0
> s=B
> a=tool:libavformat 52.18.0
Then, we have a problem. I do not know if it is due to a bug in libavformat,
to some wrong parameter passed to avf_sdp_create() (can you double-check you
are passing the correct parameters?), or to some other issue... Maybe this
is not the cause of the other problems you are encountering, but it should
be investigated.
> so I'm using the SDP pre-made by command line. Could it be the reason?
I suspect it might be.
>> >> Any chance you are setting the CODEC_FLAG_GLOBAL_HEADER in the
>> AVCodecContext,
>
>> Well, output_example.c sets this flag if the output format is mp4, mov, or
>> 3gp, because those formats need the extradata field to be filled. When you
>> stream RTP you can choose if you want to set this flag or not (depending on
>> your need for in-band or out-of-band config info).
>
> Just to clarify - this flags fills extradata on disk formats (like
> mp4), and specifies out-band on streaming formats (RTP), correct?
Yes, more or less (this flag always fills the extradata in AVCodecContext,
which are needed by some formats. Whe extradata are set, the RTP muxer
sends global headers out-of-band, otherwise they are sent in-band).
>> > What are the benefits of using out-band, compared to in-band - does it
>> > means less bandwidth required?
>>
>> AFAIK, out-of-band global headers allow the player to start to play the
>> stream first (without needing to wait for SPS and PPS); in-band SPS and PPS
>> allow the encoder to dynamically change some stream properties.
>
> The SPS/PPS are sent immediately on the first frame, so there should
> be virtually no delay?
If the player is started after the beginning of the stream, it does not
receive the first packets, so it is not guaranteed to immediately receive
SPS and PPS (as a result, you can see some "waiting for SPS/PPS..."
messages after starting the player).
>> My only guess is that the global headers described in the SDP do not
>> completely match the stream (as said above); I have no other ideas...
>> Of course, remember that when streaming you have to output frames at
>> the correct rate (and not as fast as possible, like in output_example.c).
>
> This could be the reason to another issue that I have - where the
> player (VLC or QT) gradually increases it's own buffer, until the
> delay significantly grows. Restarting the player temporarily helps it,
> until the delay grows again.
Yes, this is surely the reason for such a behaviour.
> Can you please explain what you meant by correct rate - is it setting
> the fps structure (time/den) to correct FPS?
No; you just need to wait for the correct time before calling
av_write_frame(). So, you need to add something like a usleep() or
similar... The correct time for sending a frame can be computed
based on the DTS of the frame. An easy way to compute this time could
be:
<time when the first frame has been sent> + av_rescale_q(pkt.dts,
st->time_base, AV_TIME_BASE_Q);
Of course you can use more complex equations for performing
bandwidth smoothing or similar things...
Luca
_______________________________________________
libav-user mailing list
libav-user@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
