Hi,
Stas Oskin wrote:
[...]
> My biggest problem here, is that I'm dealing with unreliable source,
> which does not send the frames with a constant FPS.
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?
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.
[...]
> I'm using the timing formula that Luca kindly provided, i.e:
> sleep_time = currenttime - (time_of_first_frame +
> av_rescale_q(pkt.dts, st->time_base, AV_TIME_BASE_Q)).
I am pretty sure it is the opposite:
(time_of_first_frame + av_rescale_q(pkt.dts, st->time_base, AV_TIME_BASE_Q)) -
currenttime
:)
> The problem with this approach, that almost immediately I'm starting
> to get negative values, and basically the loop never sleeps but sends
> the frame immediately.
The sleep_time mentioned above is needed when frames are generated
as soon as possible; if your SDK already sends the frames at the correct
time, sleeping is not needed. The problems you mention might be due to
a mismatch between the timestamps provided by the SDK and the frames
generation times. (this might means that the timestamps are wrong)
> So, to better paraphrase my question, what are the recommended
> strategics for working with variable FPS on video data source?
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.
Luca
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
