Hello!
I'm experiencing what I'd call a glitch of VDR's frame detector class.
There's a define #define MIN_TS_PACKETS_FOR_FRAME_DETECTOR 5. According to my experiences, this number of TS packages in not always enough to detect frames as early as possible. Thus it is a matter of chance if detection will be fed with enough data to detect the first frame or if it will glitch through to another one. I think we should avoid such situations.
I attached demo code (needs some includes and to be compiled and linked with VDR) which shows the behaviour and I stored a short TS sample at http://ein-eike.de/wordpress/wp-content/uploads/2014/01/vdr-sample.ts The code checks when an I frame is found, at first with full data available, and then with data dripping in with a frame size of 5, 6 ... until the dripping data yields the same result as the flooding data.
I get the following output from the given example:
Checking file at offset 0 Without frame limit... Found I frame after 190256 bytes With frame limit 5... Found I frame after 398560 bytes With frame limit 6... Found I frame after 190256 bytes TS package frame size needed for this video block: 6 Maximum TS package frame size needed for this video recording: 6
Unfortunately, I cannot tell if 6 is the definite number to avoid such glitches or if other circumstances would need a higher number. I wrote the code such as people might try it out on their video files so we could experiment. (I could provide a Linux executable as well.)
Ciao, Eike
On 13.01.2014 21:38, Eike wrote:
Hello!
I'm experiencing what I'd call a glitch of VDR's frame detector class.
There's a define #define MIN_TS_PACKETS_FOR_FRAME_DETECTOR 5. According to my experiences, this number of TS packages in not always enough to detect frames as early as possible. Thus it is a matter of chance if detection will be fed with enough data to detect the first frame or if it will glitch through to another one. I think we should avoid such situations.
I attached demo code (needs some includes and to be compiled and linked with VDR) which shows the behaviour and I stored a short TS sample at http://ein-eike.de/wordpress/wp-content/uploads/2014/01/vdr-sample.ts The code checks when an I frame is found, at first with full data available, and then with data dripping in with a frame size of 5, 6 ... until the dripping data yields the same result as the flooding data.
I get the following output from the given example:
Checking file at offset 0 Without frame limit... Found I frame after 190256 bytes With frame limit 5... Found I frame after 398560 bytes With frame limit 6... Found I frame after 190256 bytes TS package frame size needed for this video block: 6 Maximum TS package frame size needed for this video recording: 6
Unfortunately, I cannot tell if 6 is the definite number to avoid such glitches or if other circumstances would need a higher number. I wrote the code such as people might try it out on their video files so we could experiment. (I could provide a Linux executable as well.)
Can you name a satellite channel where this problem occurs?
Klaus
On 14.01.2014 10:44, EikeSauer@t-online.de wrote:
Hello!
Can you name a satellite channel where this problem occurs?
No, I'm using DVB-T. The recording I've linked is taken from RBB.
If you're interested in using the results, I could setup a survey so that people can test their own streams.
This would certainly be interesting. If this is a real problem, I wouldn't mind increasing MIN_TS_PACKETS_FOR_FRAME_DETECTOR (within reason).
Klaus
-
Eike -
EikeSauer＠t-online.de
-
Klaus Schmidinger