On 20.06.2011 00:22, Udo Richter wrote:
Am 19.06.2011 22:57, schrieb Klaus Schmidinger:
On 19.06.2011 12:41, Klaus Schmidinger wrote:
- Fixed detecting frames in case the Picture Start Code or Access Unit
Delimiter extends over TS packet boundaries (reported by Johan Andersson).
I'm afraid this change causes a short distortion in video and audio when VDR switches from one .ts file to the next during replay. I have yet to investigate and fix this, just wanted to warn people who make important recordings with this new version - which, of course, nobody should do, since it is a developer version ;-)
Thanks for the hint, reverted to 1.7.18 for now. Or, of course, would have if I were using a developer version, which nobody would do. ;)
Can you provide a diff that reverts just that changeset so we can use all the other goodies of 1.7.19 for now? Eh, could, if we would use developer builds, of course. ;)
Please try the attached patch with VDR 1.7.19.
cRecorder::Action() now buffers TS packets in case the frame type is not yet known when a new payload starts. This adds no overhead for channels that broadcast the frame type within the first TS packet of a payload; it only kicks in if that information is not in the first TS packet.
For testing you may want to set MaxVideoFileSize (in setup.conf) to a lower value, so that recordings are split into many files.
Since I don't know of any channel I can receive that doesn't encode the picture type in the first TS packet of a new payload, I was only able to test whether the distortion problem is gone for "normal" channels ("unnormal" being those that don't encode the picture type in the first TS packet ;-). Therefore the actual buffering functionality is untested.
If you get a "frame type not in first packet of payload - buffering" or any other of the new log messages, please let me know.
Klaus