You put a complete analysis into your description (which usually indicates you could fix the issue instead of filing a bug report) but I wonder how I can reproduce the original issue: How can I get double speed output, how does your fix change timestamps?

When we play a mpeg transport stream into the decoder (ffplay or VLC 3.0.1) we see the I-frame (which has a PTS time stamp in the ts before the SPS) played out followed by the P-frames at double speed then a gap before the next I-frame (and PTS) comes along. This does not happen on VLC 2.2.8 but I have not found which version of ffmpeg these are built with. In trying to find out the cause of this problem we discovered the bug that the h->x264_build becomes zero rather than -1. So I added printf into the code as I have shown into h264_slice_header_init(). You can then see this with the bitstream I have sent. We can also fix the issue be setting time_scale in the h264 bitstream to 25000 rather than 50000 but this is not correct as H264 ticks are always in fields regardless of the picture structure.

Ok I understand - when I played the ts steam in VLC media player or our own player (using ffmpeg) we saw the issue in that the picture would stutter with the P-frames comming out twice as fast and then a pause before the next I-frame. As that is quite complicated we looked into just compiling ffmpeg on its own and found this. Your right that it could be another issue we have not yet found. However that variable being set to zero is not correct. I may be able to use ffplay to see what the fix does. My understanding of what was intended in the code is limited so I not sure on the correct fix.