I’m working on a frame accurate stream switch. My current iteration is using vapoursynth to serve frames to ffplay. I have the vapoursynth script set up to take a keyboard input and then change to stream without skipping forward to the next iframe. There is a 500 ms delay between the keyboard action and the video switching. The good news is that it is frame accurate, the bad news is that 500 ms is a LONG delay. My initial assumption was that ffplay had a buffer in place but I dropped the MIN_FRAMES to 5 from 25 and the delay is still present (and still at ~500 ms).
I know this isn’t a vapoursynth forum but I’m trying to eliminate ffplay as the source of the delay. When ffplay is receiving data from a yuv4mpegpipe with MIN_FRAMES set to 5, how much of a delay is there between receiving the frames and displaying them? What are the EXTERNAL_CLOCK_MIN_FRAMES AND EXTERNAL_CLOCK_MAX_FRAMES for? here’s my command vspipe -y4m script.vpy - | ffplay pipe: -sync video Thanks > On Aug 28, 2015, at 9:25 AM, Marton Balint <c...@passwd.hu> wrote: > > On Thu, 27 Aug 2015, Dan Gordon wrote: > >> I am trying to reduce the size of the buffer for ffplay, it looks like the >> default is around 500 ms. I have been looking through the code but >> unfortunately, I’m struggling with understanding it as I’m not too familiar >> with c yet. Can somebody point me in the right direction on how to reduce >> this default value? >> > > The packet buffer size is controlled by MIN_FRAMES. > > Regards, > Marton > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
