The attached patch reactivates some of the frame detecting code that was already in VDR 1.7.16, and adds a method of determining whether the current video stream consists of separate "fields" instead of complete frames. If this is the case, it puts two subsequent fields together to one frame in the index file.
I know that the way this is detected (by counting the number of "frames" between two I-frames) is "guesswork", but until I see a case where this fails I'd say it still beats having a complete H.264 parser in there ;-)
Please test the patch (which is against VDR 1.7.17) by recording all kinds of streams (SD and HD) available to you and verify that, when replaying such a recording
- the current and total time in the replay progress display is correct. - fast forward/rewind works properly - setting an editing mark, jumping to it and moving it around updates the picture accordingly
The patch activates 'DebugFrames', so whenever a recording starts VDR prints something like this to stderr:
/50 /50 /50 /50 /30 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /10 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /30 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /10 Delta = 1800 FPS = 50.00 FPPU = 1 NF = 32 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /30 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /10 *
If you encounter a channel where one of the above tests fails, please send me the data VDR has printed to stderr when the recording started. Maybe it can help to further fine tune this.
Please do all testing with newly created recordings that have been done with a VDR that has this patch applied.
Klaus