Transcoded network streams are containing several errors.

[Leslie.H]

I was updating the ffmpeg components on a common stream recording server. The result is terrible. The video quality changed to unacceptable. I didn’t modify anything, only replaced the ffmpeg static Windows builds.

You can check the attached files:

cmd_new.bat is the command which has the output film_new.mkv. The full console log is console_new.txt.

cmd_old.bat is the command which has the output film_old.mkv. The full console log is console_old.txt.

It seems a critical bug.

[mkver]

The first thing I see is that the log for the new build contains:

[udp @ 000000bfad4abe00] 'overrun_nonfatal' option was set but it is not supported on this build (pthread support is required)
[udp @ 000000bfad4abe00] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)

Which means that you should test a build with pthreads.

[Leslie.H]

Yes. I know, but there is no effect of these options. The output has the same errors when I remove these options.

[mkver]

Of course removing these options from a build without pthreads doesn't change anything, because they are not supported (i.e. even if you set those options, they are not really active). As I said: Test a build with pthreads.

(If I am not mistaken, then ​this project can be used to build ffmpeg with pthreads.)

[Leslie.H]

I have uploaded the outputs without the options for both old and new ffmpeg build.
I think the new ffmpeg should generate good outputs wihtout pthread.

Of course removing these options from a build without pthreads doesn't change anything, because they are not supported (i.e. even if you set those options, they are not really active). As I said: Test a build with pthreads.

(If I am not mistaken, then ​this project can be used to build ffmpeg with pthreads.)

[mkver]

Can you pinpoint the first occurence of the bug using e.g. ​old zeranoe builds?

[Leslie.H]

The oldest available version is:
ffmpeg-20190101-1dcb5b7-win64-static.zip

The output has the same errors.

Can you pinpoint the first occurence of the bug using e.g. ​old zeranoe builds?

[Leslie.H]

I used this site to download the older versions:

​https://www.videohelp.com/software/ffmpeg/old-versions

Based on the tests, the result is the following:
The last good version is:

ffmpeg-20161207-6b95da9-win64-static.zip 2016-12-07

ffmpeg version N-82785-g6b95da9 Copyright (c) 2000-2016 the FFmpeg developers

built with gcc 5.4.0 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-decklink --enable-zlib
libavutil 55. 41.101 / 55. 41.101
libavcodec 57. 66.109 / 57. 66.109
libavformat 57. 58.101 / 57. 58.101
libavdevice 57. 2.100 / 57. 2.100
libavfilter 6. 68.100 / 6. 68.100
libswscale 4. 3.101 / 4. 3.101
libswresample 2. 4.100 / 2. 4.100
libpostproc 54. 2.100 / 54. 2.100

The next version with errors is:

ffmpeg-3.2.2-win64-static.zip 2016-12-17

ffmpeg version 3.2.2 Copyright (c) 2000-2016 the FFmpeg developers

built with gcc 5.4.0 (GCC)
configuration: --enable-gpl --enable-version3 --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-decklink --enable-zlib
libavutil 55. 34.100 / 55. 34.100
libavcodec 57. 64.101 / 57. 64.101
libavformat 57. 56.100 / 57. 56.100
libavdevice 57. 1.100 / 57. 1.100
libavfilter 6. 65.100 / 6. 65.100
libswscale 4. 2.100 / 4. 2.100
libswresample 2. 3.100 / 2. 3.100
libpostproc 54. 1.100 / 54. 1.100

I hope it can help.

Can you pinpoint the first occurence of the bug using e.g. ​old zeranoe builds?

[mkver]

The last working version has -disable-w32threads, the version with errors is missing this. In other words: This really seems to be an issue about w32threads vs pthreads.

[Edit]: You are comparing an old release of a branch with a snapshot of git master. This is wrong. See, developement of FFmpeg (and lots of other software projects) works roughly as follows:
When the time is right, a new release is made. This is what most package maintainers use. New features and bugfixes (which might introduce regressions) are then added to the "master" branch and aren't incorporated into the release branches by default (unless they fix a bug that was already present in the release branch and if the patch applies to the release branch at all and if it doesn't change API/ABI compability). You can see this above: The libavformat versions are 57.56.100 vs 57.58.101.

[Leslie.H]

I also tested 3.2. Which is a good version:

ffmpeg version 3.2 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 5.4.0 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-libebur128 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-decklink --enable-zlib
libavutil 55. 34.100 / 55. 34.100
libavcodec 57. 64.100 / 57. 64.100
libavformat 57. 56.100 / 57. 56.100
libavdevice 57. 1.100 / 57. 1.100
libavfilter 6. 65.100 / 6. 65.100
libswscale 4. 2.100 / 4. 2.100
libswresample 2. 3.100 / 2. 3.100
libpostproc 54. 1.100 / 54. 1.100

Can anybody build a new win64 static and dynamic build without w32thread?
I could test it.

Replying to mkver:

The last working version has -disable-w32threads, the version with errors is missing this. In other words: This really seems to be an issue about w32threads vs pthreads.

[Edit]: You are comparing an old release of a branch with a snapshot of git master. This is wrong. See, developement of FFmpeg (and lots of other software projects) works roughly as follows:
When the time is right, a new release is made. This is what most package maintainers use. New features and bugfixes (which might introduce regressions) are then added to the "master" branch and aren't incorporated into the release branches by default (unless they fix a bug that was already present in the release branch and if the patch applies to the release branch at all and if it doesn't change API/ABI compability). You can see this above: The libavformat versions are 57.56.100 vs 57.58.101.

[mkver]

​Here are some builds to try.

[Leslie.H]

Thank you!
Results are not too promising:

1. winthreads version has the errors in the output file.
2. pthread version didn't generate output file. I had to add fifo_size because circular buffer overrun messages were generated. I attached the console log. The exit was hard, because the ffmpeg was halted (?).

[Leslie.H]

May we say that, it is not possible to solve?

[Marton Balint]

Using a big enough buffer_size should fix this. Threading for UDP input is not really needed if the kernel buffers all input. And you set the kernel (socket) UDP buffer size with the buffer_size option.

[Marton Balint]

User confirmed that increasing buffer_size fixes this.