Hi,
Stas Oskin wrote:
> Hi.
>
>> >
>> > 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...
>
> Just tried with the loop parameter - both in and out band work normally.
So, this particular problem (the mismatch between SDP file and stream)
is solved? Good.
[...]
>> 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.
>
> I simply took the example in ffmpeg.c (function print_sdp() ), and
> copied it to my code. This half-done SDP is what it producing.
Since the code is working well in ffmpeg.c and is producing a broken SDP in
your application, I suspect there is some difference somewhere ;-)
If you can publish a short program that compiles and can be used to reproduce
this issue, I'll have a look at it.
>> > so I'm using the SDP pre-made by command line. Could it be the reason?
>> I suspect it might be.
>
> Both the command line generated file, and the avf_create_sdp results
> beginning in same way. Any reason for them to be different (if the
> parameters are the same)?
I don't know... There might be something different in the "sprop-parameters-set"
attribute.
>> > 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).
>
> Is the in-band SPS/PPS sent on every frame, or only every several frames?
Every several frames. I suspect they are sent at every reference picture, but
I do not really know the H.264 syntax.
>> 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);
>
> By this formula you mean (just to understand the approach):
>
> 1) Store the time of the first frame
More precisely, store "the system time (gettimeofday()) when you send
the first frame"
> 2) Calculate the time of the next frame via first frame time + result
> of av_rescale_q
Yes
> 3) Sleep until the next frame time arrives and then send the next frame?
Yes.
(Note that this is the simplest possible algorithm. A stream sent like this
is not very tolerant to network jitter, and can have high variations in the
output instantaneous bitrate... But it should work :)
Luca
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
