Hi again. After checking the matter some more, I have an important question which might to resolve this issue:
Is it true that in MP4 format (and all other stream-able formats), the specified frame rate is secondary, and the main parameter FFMPEG uses is the frames timestamps? Meaning, the frame can be whichever was set, but the actual streaming + playback would be controlled by the frames timestamps? Regards. 2008/8/31, Stas Oskin <[EMAIL PROTECTED]>: > Hi. > > Another point that I forgot to mention: > > When I have the negative sleep values, I also get the following errors in > VLC: > > " > late picture skipped (572329543999) > ... > dropping early frame > " > > I believe that these messages are due to the incorrect timing, and > because the frames arriving late, the vlc doesn't show them hence > causing the visual artifacts. Fixing the timing would prevent any > frame delays, and prevent the visual artifacts from happening. > > > > ---------- Forwarded message ---------- > From: Stas Oskin <[EMAIL PROTECTED]> > Date: 30/08/2008 23:55 > Subject: Timing MPEG4 frames for RTP/RTSP > To: Libav* user questions and discussions <[email protected]> > > > Hi. > > I would like to bring this issue forward again, as is one of the > issues that I'm constantly battling, and couldn't resolve sufficiently > well. > > My biggest problem here, is that I'm dealing with unreliable source, > which does not send the frames with a constant FPS. It changes all the > time, and sometimes is larger, sometimes is smaller, then the once set > FPS that I'm working with. > > What it leads to is: > 1) If the FPS becomes larger then the one I calculated and set in my > encoding, I get a growing delay. > 2) When it's smaller, I small hangs and visual artifacts (i.e. blocky > outlines for motion and etc...). > > 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)). > > 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. This causes the above mentioned-issues with > visual artifacts. I presume that in normal operation, the formula > should always produce positive values, timed according to expected FPS > (which is unfortunately not in my case). > > So, to better paraphrase my question, what are the recommended > strategics for working with variable FPS on video data source? > > Thanks in advance for any information. > _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
