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. 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? > > 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 am pretty sure it is the opposite: > (time_of_first_frame + av_rescale_q(pkt.dts, st->time_base, AV_TIME_BASE_Q)) > - currenttime > :) You right of course - mistake in copy/paste. But if I use SDK timestamps, I don't actually need this formula? > > 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) Will check, as so far I 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? Thanks again for your time. _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
