[FFmpeg-devel] [PATCH] Check for not synchronized packets (very small feed file, very slow client connection)
milan.matejec at gmail.com
Tue Apr 14 12:36:37 CEST 2015
sorry but that doesn't make sense. FFM is internal exchange format and
temporary feed file in this format is created every time ffserver is
started so why keep backward compatibility? Also adding checks for it would
create needless amount of code in it.
2015-04-14 1:10 GMT+02:00 Michael Niedermayer <michaelni at gmx.at>:
> On Sun, Apr 12, 2015 at 11:30:32PM +0200, Milan Matejec wrote:
> > Hi,
> > attached is patch for encoding/decoding .ffm format. When you set a
> > size of feed file to too small number (I tried 20k) and try to connect to
> > ffserver from very slow connection (simulated by reading 8k chunks and
> > wait 3 seconds) .ffm decoder will after a few seconds (10 maybe more ...)
> > stuck in endless "READ_HEADER" state because it got unreal size of .ffm
> > data packet (it's 24bits so take some random number - usually something
> > about 10MB) leading to immediately return after *ffm_is_avail_data()*.
> > patch adds a packet header with signature so after loading header it
> > to check if signature is there. If not then it logs an error and tries to
> > reset a packet and read header again. It's not a best solution but better
> > than end up in an endless loop ...
> please split the patch in 2, one for the demuxer and one for the muxer
> make sure the code works with only one patch applied and interoperation
> between versions that have and do not have the patch is fully fine
> it appears its not with this patchset
> also please attach patches normally and dont double encode them
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> It is what and why we do it that matters, not just one of them.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel