Hi, thanks for answering > your audio hardware limits it based on the samplerate you set and a > limited queues size that was the reason, I'll try another way to do that (I thought FFMPEG provided timing... all I know is achieved by reverse enginering!), But I'd like to know if I'm doing the right thing, I mean, would it be correct to limit the decoding thread on a fixed size of the queues (decoded audio frames and uncompressed video frames) and do the timing when rendering audio or video? > ffplay is a good example ... well, yes but not so easy to read the code, I'd like to provide a c++ commented simple player example in the future, if this can help newbie like me > you simply have to look at the dts of the packets and wait in either the > decoder or render threads ... I tried that but I noticed that the packet dts (audio e video) are not 1 to 1, so I'm trying to figure it out how this is achieved in ffplay anyway, thanks again I'll keep on researching... Bye ----- Original Message ----- From: "Michael Niedermayer" <michaelni at gmx.at> To: "FFmpeg development discussions and patches" <ffmpeg-devel at mplayerhq.hu> Sent: Friday, January 26, 2007 3:59 PM Subject: Re: [Ffmpeg-devel] AV Synchronization question > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel at mplayerhq.hu > http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4