Hello!
I need some help from VDR users - for variety reasons especially from those not in Germany. There's a glitch in the frame detection of VDR. It sometimes misses the first possibility to record a stream. It looks on frames of at least 5 * 188 bytes, and depending on the stream, sometimes 6 frames are needed. Trouble is, I'm not sure if 6 is enough for everybody. Thus I need your tests.
You need ot be able to compile a VDR to help. First, in the VDR directory, you do a:
make
Then you compile the attached C++ file (unziped, of course):
g++ -c framedetectortest.cpp
Then you're linking it: g++ -o framedetectortest framedetectortest.o remux.o ringbuffer.o thread.o tools.o i18n.o sections.o channels.o device.o audio.o ci.o receiver.o transfer.o player.o osdbase.o status.o skins.o osd.o config.o font.o sources.o menu.o recording.o videodir.o timers.o epg.o dvbplayer.o menuitems.o remote.o keys.o interface.o plugin.o cutter.o themes.o svdrp.o eit.o eitscan.o shutdown.o filter.o sourceparams.o dvbsubtitle.o pat.o sdt.o nit.o dvbdevice.o diseqc.o recorder.o dvbci.o libsi/libsi.a -lfontconfig -lfreetype -lpthread -ldl - ljpeg
Now you've got an application called framedetectortest, which you can feed your vdr recordings (*.ts files) to:
./framedetectortest 00002.ts
The output looks about like this:
Checking file at offset 0 Without frame limit... Found I frame after 99452 bytes With frame limit 5... Found I frame after 220336 bytes With frame limit 6... Found I frame after 99452 bytes TS package frame size needed for this video block: 6 Maximum TS package frame size needed for this video recording: 6
I need reports which number your stream resulted in (the "Maximum TS package frame size") and what you've tested (Cable? Satellite? Terrestrical? HD, SD? Your country?). The result is interesting even if it is 5 or 6.
Thanks in advance, Eike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I need reports which number your stream resulted in (the "Maximum TS package frame size") and what you've tested (Cable? Satellite? Terrestrical? HD, SD? Your country?). The result is interesting even if it is 5 or 6.
Hello,
I checked recordings HD and SD from Austrian IPTV (a1tv), the result was always 5.
The same applies to DVB-C recordings from UPC-Vienna.
Michael
15.01.2014 19:45, Eike kirjutas:
Hi,
Cable operator Starman, Estonia: On the different channels both 5 and 6 exists. It seems that on the local channels it's 6 and in the retransmitted from sat channels - 5 (for example Showtime).
With some records I have got like this: framedetectorte[20894]: segfault at 0 ip b73a75c5 sp bfc2a650 error 4 in libc-2.17.so[b7338000+185000]
Eike wrote:
I need reports which number your stream resulted in (the "Maximum TS package frame size") and what you've tested (Cable? Satellite? Terrestrical? HD, SD? Your country?). The result is interesting even if it is 5 or 6.
I tested DVB-S SD recordings from three different TV networks in New Zealand and all reported 5 as the maximum TS frame size.
Regards,
Richard
Hallo,
anbei mal die Infos über mein Archiv (~1.6 TB - 100MB Maxsize):
5 : 9455 6 : 6132 7 : 57 8 : 52 9 : 36 10 : 23 11 : 16 12 : 20 13 : 6 14 : 8 15 : 8 16 : 6 17 : 4 19 : 1 83 : 1
ich denke, mit 6 hätte man bereits den Großteil erschlagen (>98.5%) und mit 10 ist man sogar bei >99.5%.
Und wer weiß, ob die mit 83 nicht sogar einfach nur defekt ist ...
Gruß,
Jogi
On Tue, Jan 14, 2014 at 09:34:07PM +0100, Eike wrote:
Testing on a range of recordings of DVB-T in Australia;
root@htpc:~# cat /tmp/size.txt | grep "Maximum TS" | sort -n | uniq -c
1 Maximum TS package frame size needed for this video recording: 32
122 Maximum TS package frame size needed for this video recording: 5
42 Maximum TS package frame size needed for this video recording: 6
1 Maximum TS package frame size needed for this video recording: 7
On 17 January 2014 09:51, Antti Hartikainen ami+vdr@ah.fi wrote:
Hello again!
Thanks for your submissions, coming from Germany, Austria, Netherlands, Czech, Finland, Esotnia, Australia and New Zealand!
Most people reported that a window/frame size of 6 packages has been fine for all their streams. Some larger numbers could be traced back to broken parts of a stream, but at least one recording doesn't seem to have a fault and still yields a frame size of 13. It's coming from WDR Köln HD, perhaps someone wants to check this sender as well.
Klaus offered to use 10 as the new value so we've got some safety margin to the vast majority of values reported.
Some people asked why VDR is so sparing about the number of packages it demands. A recording will not start before this number of packages has been delivered and at the end, the buffer will not deliver a smaller number and thus "swallow" the rest, so the number should not be too large.
Thanks for your participation, Eike
The attached patch increases MIN_TS_PACKETS_FOR_FRAME_DETECTOR to 100 and itroduces counting the number of actual video TS packets in cTsPayload in order to be able to record channels that sometimes need even more than 10 TS packets for detecting frame borders.
While the frame type can typically be detected by processing at most two video TS packets, there may be several TS packets from other PIDs between the first and second video TS packet. Previously cTsPayload counted all TS packets against MIN_TS_PACKETS_FOR_FRAME_DETECTOR, and that number was intentionally kept small in order to keep the actual data processing at a minimum. With this patch, MIN_TS_PACKETS_FOR_FRAME_DETECTOR will be set to a presumably very safe large value, which only has an impact on the ringbuffer and should not increase processing costs there. The new MAX_TS_PACKETS_FOR_VIDEO_FRAME_DETECTION now defines the number of actual video TS packets that will be processed. There are also WRN_... macros in remux.c, which control some debug messages in case the safety margin for these limits is exceeded. You can try setting these to lower values for experimenting.
Please try this patch and let me know if the warning is ever triggered with the given values (or, in case you're experimenting with reduced values, what were the highest values that still triggered warnings).
Klaus
-
Antti Hartikainen -
Arthur Konovalov -
Eike -
Jochen Heuer -
Kende -
Klaus Schmidinger -
Michael Frank -
Michal Novotny -
Richard Scobie -
Torgeir Veimo