Hi again, Luca. > I just found something. When I disabled the timing, and started to > send the encoded frames immediately, no more jumps occur. > > But: > 1) I have more garbage pixels - a lot. > 2) The delay is growing of course. > > I also should mention that I'm sometimes getting negative wait values > (as high as 200 milliseconds), meaning I should have sent the frame > long time ago. In this case I simply send the frame immediately. > > Could this be the reason? But how timing and missed frames are related? > > Regards. >
After more testings, I found out that the problem is definitely within the timing formula, or more precisely, within the fps coming from the video source. Here what I found: 1) When I used 15 fps constant (which was a bug btw), I got good results from LAN source (which limited to 15 fps), but not from ADSL source (as I reported before). 2) When I dynamically calculated the fps (according to buffer of ~80 frames), I got 20 for ADSL source, and 14 or 16 for LAN source. The results were now reversed - good video from ADSL and issues (jumps and pixel garbage) from LAN source (even that the difference was only one frame per second). So, the target fps should definitely match the source fps, otherwise these frame lose issues happen. Following these results, my questions are: 1) Any tips for precisely calculating the fps to match the source? 2) Alternatively, is it possible to set the re-streamed video to a constant fps (15 for example)? I recall that ffmpeg has the -r flag, which causes it to output the video in specified frame rate. Any idea if this could help here? 3) You mentioned that I can either pre-send some packets to compensate for network, or to smooth the output rate. Can you provide more information about these methods, or where they can be read about? Thanks in advance. _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
