> On Feb 28, 2018, at 4:12 PM, Nicolas George <geo...@nsup.org> wrote: > > Philip Prindeville (2018-02-28): >> I’m working on network test and measurement and I’ve been tasked to >> write a test suite for streaming video performance. >> >> This will run inside headless embedded devices (i.e. routers, probes, >> etc) so has no hardware to render to. It’s the streaming itself and >> the end-to-end network transport that I’m interested in, observing >> jitter, stalls, etc. >> >> To that end, I wanted to write an output device that I can select as >> the output driver to which the stream will be parsed and synchronized >> to the appropriate frame rate, collect statistics for CBR/VBR/ABR, >> etc. but which doesn’t actually do any rendering. >> >> Whatever I write I’ll upstream, but it seems like it might be >> generically useful. >> >> I’m a network head and I’ve hacked DVB-S, so I’m vaguely familiar with >> MPEG-4 AVC stream format. I want to inspect enough of the stream to >> be able to ensure synchronization with the frame rate, correctness of >> the stream, etc. but not the expensive/unnecessary parts. >> >> Any guidance for someone jumping into this for the first time? > > Quick answer: look if "ffmpeg -i ... -f framecrc -" could be a good base > for your project; and look at -f null for the wrapped-frame > optimization. If you work at the muxer level, you do not need to know > anything about the bitstream format. > > Regards, > > -- > Nicolas George
Thanks, I’ll look at it shortly. Will that level (muxer) give me visibility into synchronization so I can pace playback to 1:1 rate? -Philip _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
