[FFmpeg-devel] [PATCH] Fixed issues preventing ffserver write_index and files_size from being set correctly which was breaking ffserver streaming.

[Michael Niedermayer]

On Sat, Feb 20, 2016 at 09:33:49AM +0200, Oliver Collyer wrote:
> Hi all
> 
> My first patch/appearance in these parts so please go easy on me if I’ve done anything wrong!
> 
> I discovered that ffserver streaming was broken (it seems like it has been since 20th November) and I opened a ticket for this (https://trac.ffmpeg.org/ticket/5250 <https://trac.ffmpeg.org/ticket/5250>).
> 
> I spent yesterday learning git bisect (with the kind help of cehoyos) to painstakingly track down the cause. This was made more difficult due to the presence of a segfault in ffserver during the period where the bug was introduced so I first had to identify when and how that was fixed and then retrospectively apply that fix again for each step of the second git bisect to find the actual bug.
> 
> Anyway, the fruits of my labour are the innocent looking patch below to correct a couple of typos and define a valid range for two variables.
> 
> One thing is that I’m unsure of the correct range for write_index and file_size in the patch for ffmdec.c. I’ve simply chosen INT64_MAX.

patch applied, looks good, just the mail doesnt work 1:1 as commit
message


> 
> A general Q as a curious onlooker - is there not any kind of basic testing process for ffmpeg? When the mistake below was made a quick test of ffserver would have revealed it, but even if that didn’t occur is there not any kind of testing checklist done before release a branch such as 3.0?. Or does it all just rely on the community trying things out and if nobody happens to use ffserver and reports an issue then there is no other safety net?

I am pushing for ffserver regression tests to added to fate since a
long time. There are some old but not fully working tests in fate, see
git grep ffserver tests

Its neccessary that any such test works on all platforms on which it
is enabled, anything it compares must match, if it compares some
file output byte per byte then this must match between platforms


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160221/d8602937/attachment.sig>