Stas Oskin wrote:
> Hi Luca.
>
>
>> This is the SDK you mentioned in your previous email, right?
>> Do not look at when the SDK sends the frames, but look at the frames'
>> timestamps.
>>
>> If I understand your description, the problem is that the SDK is
>> providing you with wrong timestamps. Can you check them?
>
> Actually, after you said that, I noticed that SDK does provide me with
> timestamps of it's own. Before that I just calculated them by myself
> based on system time.
Ugh... Don't do that ;-)
Seriously, you cannot use the system time for computing timestamps (the
resulting value will never be completely correct, will be affected by
network jitter, system load, and many other unpredictable factors...)
> I will check it out - just clarify one thing: in order to keep the
> frame similar as possible to the source, I need to re-stream them with
> the same period as in the frames coming from SDK?
What do you mean by "re-stream them with the same period"? Surely, you
have to fill AVPacket with the timestamps values coming from the SDK
(be careful with PTS/DTS differences...). And then you can try to
send out the frames as soon as the SDK provides them.
>> Or maybe the problem is that it is using a variable frame rate?
>> In this case, the problem might be in the client, that does not support
>> variable frame rate.
>
> Well, I use VLC for tests which should support variable frame rate.
> But FFMPEG is based on static frame rate, isn't so?
I do not know... I do not think there is any "fixed frame rate" assumption
in libavformat, but maybe there are similar assumptions in ffmpeg.c
[...]
> You right of course - mistake in copy/paste. But if I use SDK
> timestamps, I don't actually need this formula?
If your SDK provides you with correct timestamps, and generates the frames
at a reasonable rate, then you do not need to sleep. Just try, and see
what happens...
[...]
> Will check, as so far used my own calculated timestamps.
>> Many of the players I know do not support variable frame rate video
>> over RTP... You might need to duplicate/drop frames to obtain
>> a constant frame rate.
>
> I prefer to avoid this, as it would either introduce skips or
> micro-hangs. Are there any other methods to solve this?
I do not know... Just try to re-stream the frames without sleeping,
dropping, or duplicating, and let's see if it works.
Luca
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
