Tvheadend

I decided to take a stab at this myself and came up with https://github.com/mamarley/tvheadend/commit/371d3c7ba548505713aaea487785bbb51e2e9984. (It is of course incomplete and currently not mergeable, but this is just a first attempt.) This causes 60fps video to be displayed. However, my attempt to double the framerate (video.c:175) apparently didn't take for some reason because the player application still reports the original framerate (usually 29.97) and some players spew errors about invalid timecodes. Additionally, I had to comment out the PTS check in tvh_video_context_encode(), otherwise all the extra frames get dropped for invalid PTS. I have a feeling this also has something to do with my attempt to double the framerate failing from above. However, I cannot find anyplace else where the framerate of the output stream is set and I am not knowledgeable enough with FFmpeg or video encoding/decoding in general to understand what might be going wrong. Does anyone have any advice on what I might be screwing up? Thanks!

I ended up migrating all my stuff to GitLab, so the updated link is https://gitlab.com/mamarley/tvheadend/commit/371d3c7ba548505713aaea487785bbb51e2e9984.

30i video mean 30 odd and 30 even lines
witch is 1/4 frames of 60p not sure how from destroyed source will recreate original source,
even use Yadif (x2) deinterlacer.

That isn't always true; it depends on the framerate of the source material. It is definitely possible to interlace 30p material into 30i with the first and second field being source from the same frame. If this is deinterlaced with a framerate-doubling algorithm, it will turn into frame-doubled 30p video, which is indeed pointless.

However, it is also quite common to interlace 60p material into 30i with each field derived from a different frame. When this material is deinterlaced with a framerate-doubling deinterlacer, the deinterlacer reconstitutes an entire frame from each field, resulting in 60p output, which is obviously much smoother (and more closely resembles the uninterlaced source material) than the 30p output that would be generated by a non-framerate-doubling deinterlacer.

This latter case is what I am trying to handle.