Hi,
I'd like to invite you to test the attached patch which now also supports MPEG1 video streams (vdr-1.3.27-remux-repacker.patch).
Besides that, a major change has been made in error reporting. Previous versions often reported a buffer overflow (although there was no buffer overflow) just as an indication for not beeing able to handle the data. Most likely this lead to the assumption that the repacker got stuck.
VDR-1.3.28 will also (most likely) receive the second attached patch "vdr-1.3.27-dvbplayer-sequence-end-code.patch". It will cause a still image to be immediately shown by (softdevices like) vdr-xine, e. g. when moving or jumping to cutting marks. Does this patch have any bad impact on FF-devices?
As old recordings (prior to VDR-1.3.26 or 1.3.27 with cVideoRepacker disabled) can have fragmented frames and VDR doesn't handle them correctly when passing still images to a device, it is hardly possible to edit cutting marks (at least) in vdr-xine for such recordings.
The patch http://home.vr-web.de/~rnissl/vdr-1.3.24-dvbplayer.patch is a hack to at least fix the I-frames needed for fast forward, fast rewind, slow rewind and editing cutting marks. As you may see, it collides with the attached dvbplayer patch, so you have to decide whether to use the attached one and just edit new recordings or to use the one taken at version 1.3.24 and be able to edit new and old -- but only MPEG2 -- recordings.
Bye.
Hi Reinhard.
Tried the new repacker, but it was not successful : Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 1545 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 493 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Jul 18 08:42:04 media last message repeated 5 times Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 1398 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 4 bytes to sync on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 1545 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 493 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Jul 18 08:42:04 media last message repeated 5 times Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 1398 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 4 bytes to sync on next picture Jul 18 08:42:20 media vdr[4970]: ERROR: 1 ring buffer overflow (65 bytes dropped) Jul 18 08:42:26 media vdr[4970]: ERROR: 10022 ring buffer overflows (1884136 bytes dropped) Jul 18 08:42:32 media vdr[4970]: ERROR: 9840 ring buffer overflows (1849920 bytes dropped) Jul 18 08:42:35 media vdr[4968]: ERROR: video data stream broken Jul 18 08:42:35 media vdr[4968]: initiating emergency exit Jul 18 08:42:35 media vdr[4555]: emergency exit requested - shutting down
----- Original Message ----- From: "Reinhard Nissl" rnissl@gmx.de To: "Klaus Schmidinger's VDR" vdr@linuxtv.org Sent: Sunday, July 17, 2005 11:17 AM Subject: [vdr] VDR-1.3.27: updated cVideoRepacker
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.0/49 - Release Date: 16/07/2005
Hi,
Simon Baxter wrote:
Tried the new repacker, but it was not successful :
Thanks for the report. Please specify some additional information:
There are several threads involved (4972, 4969, 4970, 4968). Please send the lines too, where these threads were created, respectively include them in the next report.
Which kind of DVB hardware do you use: S, C or T?
Is it related to a single channel?
How long does it take from switching to the channel until VDR restarts?
Does it just happen for recordings (see below)?
Are you using a FF card or a softdevice solution like vdr-xine?
It might be possible, that at 08:42:04 the cVideoRepacker was resyncing, e. g. due to some garbage that is comming in after switching the channel.
Strange is that there are two threads (4972 and 4969) that are feeding cVideoRepacker. Should there be a racecondition that spawns two threads for this job somewhere else in VDR?
Or are these two theads driving two instances of cVideoRepacker with the same data as both threads report the same messages and sync in 08:42:04?
Please tell us the versions of kernel and dvb-driver. Is NPTL enabled or disabled?
Are you using other plugins that might attach a further receiver (osd-teletext triggered some threading issues some time ago)?
Thread 4968 seems to be a recorder. It considers the data stream to be broken as it hasn't seen any data for MAXBROKENTIMEOUT (= 30 seconds), i. e. since cVideoRepacker got synced. Please add two log messages to cRepacker::Put() so that we can see how cVideoRepacker delivers data after 08:42:04. Maybe a further log message at the beginning and end of cVideoRepacker::Repack() would be useful too, to see whether cVideoRepacker gets stuck.
static int Put(.....) { esyslog(">>>>> cRepacker::Put"); // <============
int n = ResultBuffer->Put(Data, Count); if (n != Count) esyslog(.....);
esyslog("<<<<< cRepacker::Put"); // <============
return n; }
void cVideoRepacker::Repack(.....) { esyslog(">>>>> cVideoRepacker::Repack()"); // <============
// synchronisation is detected some bytes after frame start. const int SkippedBytesLimit = 4;
// reset local scanner localStart = -1;
. . .
// report that syncing dropped some bytes if (skippedBytes > SkippedBytesLimit) { esyslog(.....); skippedBytes = SkippedBytesLimit; }
esyslog("<<<<< cVideoRepacker::Repack()"); // <============ }
Thanks in advance for your help!
Bye.
attached
Which kind of DVB hardware do you use: S, C or T?
Wintv Nova-T
Is it related to a single channel?
has only happened once - will test further
How long does it take from switching to the channel until VDR restarts?
has only happened once, and it happened 7 mins after switching - will test further
Does it just happen for recordings (see below)?
so far, yes
Are you using a FF card or a softdevice solution like vdr-xine?
yes, vdr-xine
sorry couldn't tell you ):
2.6.11.8 and video4linux-20050625-194702 nptl is NOT being used
Are you using other plugins that might attach a further receiver (osd-teletext triggered some threading issues some time ago)?
-P'xine -q -r -s' -P'skincurses' -P'remote -i /dev/input/event2' -P'sysinfo' -P'mplayer' -P'dvd' -P'femon' -P'clock'
happy to help, but you'll need to help me out here. What should I be adding to where?
begin 666 Reinhard.txt M2G5L(#$X(# X.C(Q.C4U(&UE9&EA('9D<ELT-S8X73H@8VAA;FYE;" R,R H M8FED('1V*2!E=F5N=" P.#HP," G0FED(&9O<B!A($)A<F=A:6X@3&EV92<@ M<W1A='5S(#0-"DIU;" Q." P.#HR,3HU-B!M961I82!V9');-#4U-5TZ('1I M;65R(#$@*#$@,3$Q,"TQ,C4P("=*=61G92!*=61Y?DIU9&=E($IU9'DG*2!S M970@=&@979E;G0@36]N(#$X+C W+C(P#0HP-2 Q,3HS,"TQ,CHQ-2 G0V%R M($)O;W1Y)PT*2G5L(#$X(# X.C(Q.C4V(&UE9&EA('9D<ELT-34U73H@=&EM M97(@,B H-" P.#(U+3 Y,# @)T5V97)Y8F]D>2!,;W9E<R!287EM;VYD)RD@ M<V5T('1O(&5V96YT($UO;B Q."XP-RX-"C(P,#4@,#@Z,S M,#@Z-34@)T5V M97)Y8F]D>2!,;W9E<R!287EM;VYD)PT*2G5L(#$X(# X.C(Q.C4Y(&UE9&EA M(&=D;2UA=71O;&]G:6XH<&%M7W5N:7@I6S0W,#-=.B!S97-S:6]N(&]P96YE M9"!F;W(@=7-E<B!V9')U<V5R(&)Y("AU:60],"D-"DIU;" Q." P.#HR,CHP M,"!M961I82!G8V]N9F0@*'9D<G5S97(M-#@T."DZ('-T87)T:6YG("AV97)S M:6]N(#(N."XQ*2P@<&ED(#0X-#@@=7-E<B G=F1R=7-E<B<-"DIU;" Q." P M.#HR,CHP,"!M961I82!G8V]N9F0@*'9D<G5S97(M-#@T."DZ(%)E<V]L=F5D M(&%D9')E<W,@(GAM;#IR96%D;VYL>3HO971C+V=C;VYF+V=C;VYF+GAM;"YM M86YD871O#0IR>2(@=&@82!R96%D+6]N;'D@8V]N9FEG=7)A=&EO;B!S;W5R M8V4@870@<&]S:71I;VX@, T*2G5L(#$X(# X.C(R.C P(&UE9&EA(&=C;VYF M9" H=F1R=7-E<BTT.#0X*3H@4F5S;VQV960@861D<F5S<R B>&UL.G)E861W M<FET93HO:&]M92]V9')U<V5R+RYG8V]N9B(@=&@80T*=W)I=&%B;&4@8V]N M9FEG=7)A=&EO;B!S;W5R8V4@870@<&]S:71I;VX@,0T*2G5L(#$X(# X.C(R M.C P(&UE9&EA(&=C;VYF9" H=F1R=7-E<BTT.#0X*3H@4F5S;VQV960@861D M<F5S<R B>&UL.G)E861O;FQY.B]E=&,O9V-O;F8O9V-O;F8N>&UL+F1E9F%U M;'0-"G,B('1O(&$@<F5A9"UO;FQY(&-O;F9I9W5R871I;VX@<V]U<F-E(&%T M('!O<VET:6]N(#(-"DIU;" Q." P.#HR,CHP,B!M961I82!K97)N96PZ(&-X M.#A?=V%K975P.B T(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E(#$I#0I* M=6P@,3@@,#@Z,C(Z,#8@;65D:6$@;&%S="!M97-S86=E(')E<&5A=&5D(#(@ M=&EM97,-"DIU;" Q." P.#HR,CHP-B!M961I82!K97)N96PZ(%5$1BUF<R!) M3D9/(%5$1B P+CDN."XQ("@R,# T+S(Y+S Y*2!-;W5N=&EN9R!V;VQU;64@ M)U-53%1!3E-?3T9?4U=)3D<G+"!T#0II;65S=&%M<" Q.3DY+S T+S U(# T M.C(Y("@Q,#-C*0T*2G5L(#$X(# X.C(R.C Y(&UE9&EA(&ME<FYE;#H@8W@X M.%]W86ME=7 Z(#(@8G5F9F5R<R!H86YD;&5D("AS:&]U;&0@8F4@,2D-"DIU M;" Q." P.#HR,CHQ,2!M961I82!G8V]N9F0@*'9D<G5S97(M-#@T."DZ(%)E M<V]L=F5D(&%D9')E<W,@(GAM;#IR96%D=W)I=&4Z+VAO;64O=F1R=7-E<B\N M9V-O;F8B('1O(&$-"G=R:71A8FQE(&-O;F9I9W5R871I;VX@<V]U<F-E(&%T M('!O<VET:6]N(# -"DIU;" Q." P.#HR,CHQ,2!M961I82!K97)N96PZ(&-X M.#A?=V%K975P.B R(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E(#$I#0I* M=6P@,3@@,#@Z,C(Z,3,@;65D:6$@:V5R;F5L.B!C>#@X7W=A:V5U<#H@,R!B M=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L(#$X(# X.C(R.C$S M(&UE9&EA(&ME<FYE;#H@8W@X.%]W86ME=7 Z(#0@8G5F9F5R<R!H86YD;&5D M("AS:&]U;&0@8F4@,2D-"DIU;" Q." P.#HR,CHQ-"!M961I82!K97)N96PZ M(&-X.#A?=V%K975P.B R(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E(#$I M#0I*=6P@,3@@,#@Z,C(Z,30@;65D:6$@:V5R;F5L.B!C>#@X7W=A:V5U<#H@ M,R!B=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L(#$X(# X.C(R M.C$T(&UE9&EA(&ME<FYE;#H@8W@X.%]W86ME=7 Z(#(@8G5F9F5R<R!H86YD M;&5D("AS:&]U;&0@8F4@,2D-"DIU;" Q." P.#HR,CHQ-2!M961I82!K97)N M96PZ(&-X.#A?=V%K975P.B V(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E M(#$I#0I*=6P@,3@@,#@Z,C(Z,3<@;65D:6$@:V5R;F5L.B!C>#@X7W=A:V5U M<#H@,B!B=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L(#$X(# X M.C(R.C$X(&UE9&EA(&QA<W0@;65S<V%G92!R97!E871E9" S('1I;65S#0I* M=6P@,3@@,#@Z,C(Z,3@@;65D:6$@:V5R;F5L.B!C>#@X7W=A:V5U<#H@,R!B M=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L(#$X(# X.C(R.C$Y M(&UE9&EA(&ME<FYE;#H@8W@X.%]W86ME=7 Z(#(@8G5F9F5R<R!H86YD;&5D M("AS:&]U;&0@8F4@,2D-"DIU;" Q." P.#HR,CHQ.2!M961I82!K97)N96PZ M(&-X.#A?=V%K975P.B R(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E(#$I M#0I*=6P@,3@@,#@Z,C(Z,C @;65D:6$@=F1R6S0W-S%=.B!L;V%D:6YG("]V M:61E;R]V9'(M,2XS+C(W+W1H96UE<R]S='1N9RUD969A=6QT+G1H96UE#0I* M=6P@,3@@,#@Z,C(Z,C(@;65D:6$@:V5R;F5L.B!C>#@X7W=A:V5U<#H@,R!B M=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L(#$X(# X.C(R.C(R M(&UE9&EA(&ME<FYE;#H@8W@X.%]W86ME=7 Z(#0@8G5F9F5R<R!H86YD;&5D M("AS:&]U;&0@8F4@,2D-"DIU;" Q." P.#HR,CHR,R!M961I82!K97)N96PZ M(&-X.#A?=V%K975P.B U(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E(#$I M#0I*=6P@,3@@,#@Z,C0Z-3(@;65D:6$@;G1P9%LS-C S73H@<WEN8VAR;VYI M>F5D('1O($Q/0T%,*# I+"!S=')A='5M(#$P#0I*=6P@,3@@,#@Z,C0Z-3(@ M;65D:6$@;G1P9%LS-C S73H@:V5R;F5L('1I;64@<WEN8R!D:7-A8FQE9" P M,#0Q#0I*=6P@,3@@,#@Z,C4Z,# @;65D:6$@=F1R6S0U-35=.B!T:6UE<B R M("@T(# X,C4M,#DP," G179E<GEB;V1Y($QO=F5S(%)A>6UO;F0G*2!S=&%R M= T*2G5L(#$X(# X.C(U.C P(&UE9&EA('9D<ELT-34U73H@<F5C;W)D("]V M:61E;R]V9'(M,2XS+C(W+T5V97)Y8F]D>5],;W9E<U]287EM;VYD+S(P,#4M M,#<M,3@N,#@Z,C4N.3DN.3D-"BYR96,-"DIU;" Q." P.#HR-3HP,B!M961I M82!V9');-#<V.%TZ(&-H86YN96P@-R H2516,RD@979E;G0@,#@Z,#4@)U%U M:6YC>2<@<W1A='5S(#0-"DIU;" Q." P.#HR-3HP,B!M961I82!V9');-#<V M.%TZ(&-H86YN96P@,3,@*$E45B!.97=S*2!E=F5N=" P.#HP," G2516($YE M=W,G('-T871U<R T#0I*=6P@,3@@,#@Z,C4Z,#(@;65D:6$@=F1R6S0W-CA= M.B!C:&%N;F5L(#,@*$E45C$I(&5V96YT(# W.C P("='3516(%1/1$%9)R!S M=&%T=7,@- T*2G5L(#$X(# X.C(U.C S(&UE9&EA('9D<ELT-S8X73H@8VAA M;FYE;" T("A#:&%N;F5L(#0I(&5V96YT(# W.C,P("=":6<@0G)O=&AE<B<@ M<W1A='5S(#0-"DIU;" Q." P.#HR-3HP,R!M961I82!V9');-#4U-5TZ('-W M:71C:&EN9R!T;R!C:&%N;F5L(#4-"DIU;" Q." P.#HR-3HP,R!M961I82!V M9');-#4U-5TZ(&EN9F\Z($-H86YN96P@;F]T(&%V86EL86)L92$-"DIU;" Q M." P.#HR-3HP,R!M961I82!V9');-#<V.%TZ(&-H86YN96P@." H130I(&5V M96YT(# V.C P("=":6<@0G)O=&AE<B!,:79E)R!S=&%T=7,@- T*2G5L(#$X M(# X.C(U.C T(&UE9&EA('9D<ELT-S8X73H@8VAA;FYE;" V("A)5%8R*2!E M=F5N=" P-CHP," G1TU45C(G('-T871U<R T#0I*=6P@,3@@,#@Z,C4Z,#D@ M;65D:6$@=F1R6S0U-35=.B!S=VET8VAI;F<@=&@8VAA;FYE;" T#0I*=6P@ M,3@@,#@Z,C4Z-3D@;65D:6$@;G1P9%LS-C S73H@:V5R;F5L('1I;64@<WEN M8R!E;F%B;&5D(# P,#$-"DIU;" Q." P.#HR-SHP,R!M961I82!N='!D6S,V M,#-=.B!S>6YC:')O;FEZ960@=&@.#(N.3(N,3DW+C$Q-2P@<W1R871U;2 R M#0I*=6P@,3@@,#@Z,C<Z,3<@;65D:6$@;FUB9%LS-CDR73H@6S(P,#4O,#<O M,3@@,#@Z,C<Z,3<L(#!=(&YM8F0O;FUB9%]B96-O;65?;&UB+F,Z8F5C;VUE M7VQO8V%L7VUA<W1E<E]S= T*86=E,B@S.38I#0I*=6P@,3@@,#@Z,C<Z,3<@ M;65D:6$@;FUB9%LS-CDR73H@(" J*BHJ*@T*2G5L(#$X(# X.C(W.C$W(&UE M9&EA(&YM8F1;,S8Y,ETZ#0I*=6P@,3@@,#@Z,C<Z,3<@;65D:6$@;FUB9%LS M-CDR73H@("!386UB82!N86UE('-E<G9E<B!-141)02!I<R!N;W<@82!L;V-A M;"!M87-T97(@8G)O=W-E<B!F;W(@=V]R:V=R;W5P#0I-64=23U50(&]N('-U M8FYE=" Q,2XQ,"XQ,"XQ,0T*2G5L(#$X(# X.C(W.C$W(&UE9&EA(&YM8F1; M,S8Y,ETZ#0I*=6P@,3@@,#@Z,C<Z,3<@;65D:6$@;FUB9%LS-CDR73H@(" J M*BHJ*@T*2G5L(#$X(# X.C(W.C$W(&UE9&EA(&YM8F1;,S8Y,ETZ(%LR,# U M+S W+S$X(# X.C(W.C$W+" P72!N;6)D+VYM8F1?8F5C;VUE7VQM8BYC.F)E M8V]M95]L;V-A;%]M87-T97)?<W0-"F%G93(H,SDV*0T*2G5L(#$X(# X.C(W M.C$W(&UE9&EA(&YM8F1;,S8Y,ETZ(" @*BHJ*BH-"DIU;" Q." P.#HR-SHQ M-R!M961I82!N;6)D6S,V.3)=.@T*2G5L(#$X(# X.C(W.C$W(&UE9&EA(&YM M8F1;,S8Y,ETZ(" @4V%M8F$@;F%M92!S97)V97(@345$24$@:7,@;F]W(&$@ M;&]C86P@;6%S=&5R(&)R;W=S97(@9F]R('=O<FMG<F]U< T*35E'4D]54"!O M;B!S=6)N970@,3 N,3 N,3 N,3(-"DIU;" Q." P.#HR-SHQ-R!M961I82!N M;6)D6S,V.3)=.@T*2G5L(#$X(# X.C(W.C$W(&UE9&EA(&YM8F1;,S8Y,ETZ M(" @*BHJ*BH-"DIU;" Q." P.#HS,#HQ,"!M961I82!V9');-#<V.%TZ(&-H M86YN96P@-" H0VAA;FYE;" T*2!E=F5N=" P.#HS," G179E<GEB;V1Y($QO M=F5S(%)A>6UO;F0G('-T871U<R T#0I*=6P@,3@@,#@Z,S4Z,3(@;65D:6$@ M=F1R6S0W-CA=.B!C:&%N;F5L(#,@*$E45C$I(&5V96YT(# X.C,U("='3516 M("T@3$L@5$]$05DG('-T871U<R T#0I*=6P@,3@@,#@Z,S<Z,SD@;65D:6$@ M:6YI=#H@;W!E;B@O9&5V+W!T<R\P*3H@3F@<W5C:"!F:6QE(&]R(&1I<F5C M=&]R>0T*2G5L(#$X(# X.C,X.C S(&UE9&EA("]S8FEN+VUI;F=E='1Y6S0Y M.#E=.B!T='DQ.B!I;G9A;&ED(&-H87)A8W1E<B P>#D@:6X@;&]G:6X@;F%M M90T*2G5L(#$X(# X.C,X.C X(&UE9&EA(&EN:70Z(&]P96XH+V1E=B]P=',O M,"DZ($YO('-U8V@@9FEL92!O<B!D:7)E8W1O<GD-"DIU;" Q." P.#HS.3HP M,"!M961I82!G<&U;,S8T,5TZ("HJ*B!I;F9O(%MM:6-E+F,H,3<V-BE=.@T* M2G5L(#$X(# X.C,Y.C P(&UE9&EA(&=P;5LS-C0Q73H@:6UP<S(Z($%U=&\M M9&5T96-T960@:6YT96QL:6UO=7-E(%!3+S(-"DIU;" Q." P.#HS.3HP,B!M M961I82!I;FET.B!O<&5N*"]D978O<'1S+S I.B!.;R!S=6-H(&9I;&4@;W(@ M9&ER96-T;W)Y#0I*=6P@,3@@,#@Z,SDZ,3 @;65D:6$@:V5R;F5L.B!C>#@X M7W=A:V5U<#H@,B!B=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L M(#$X(# X.C0P.C R(&UE9&EA(&EN:70Z(&]P96XH+V1E=B]P=',O,"DZ($YO M('-U8V@@9FEL92!O<B!D:7)E8W1O<GD-"DIU;" Q." P.#HT,CHP-"!M961I M82!V9');-#DW,ETZ(&-6:61E;U)E<&%C:V5R.B!F;W5N9"!S>7-T96T@<W1A M<G0@8V]D93H@<W1R96%M('-E96US('1O(&)E('-C<F%M8FQE9"!O#0IR(&YO M="!D96UU;'1I<&QE>&5D#0I*=6P@,3@@,#@Z-#(Z,#0@;65D:6$@=F1R6S0Y M-S)=.B!C5FED96]297!A8VME<CH@<VMI<'!E9" Q-30U(&)Y=&5S('=H:6QE M('-Y;F-I;F<@;VX@;F5X="!P:6-T=7)E#0I*=6P@,3@@,#@Z-#(Z,#0@;65D M:6$@=F1R6S0Y-S)=.B!C5FED96]297!A8VME<CH@<VMI<'!E9" T.3,@8GET M97,@=VAI;&4@<WEN8VEN9R!O;B!N97AT('!I8W1U<F4-"DIU;" Q." P.#HT M,CHP-"!M961I82!V9');-#DW,ETZ(&-6:61E;U)E<&%C:V5R.B!S:VEP<&5D M(#(P,SD@8GET97,@=VAI;&4@<WEN8VEN9R!O;B!N97AT('!I8W1U<F4-"DIU M;" Q." P.#HT,CHP-"!M961I82!L87-T(&UE<W-A9V4@<F5P96%T960@-2!T M:6UE<PT*2G5L(#$X(# X.C0R.C T(&UE9&EA('9D<ELT.3<R73H@8U9I9&5O M4F5P86-K97(Z('-K:7!P960@,3,Y."!B>71E<R!W:&EL92!S>6YC:6YG(&]N M(&YE>'0@<&EC='5R90T*2G5L(#$X(# X.C0R.C T(&UE9&EA('9D<ELT.3<R M73H@8U9I9&5O4F5P86-K97(Z('-K:7!P960@-"!B>71E<R!T;R!S>6YC(&]N M(&YE>'0@<&EC='5R90T*2G5L(#$X(# X.C0R.C T(&UE9&EA('9D<ELT.38Y M73H@8U9I9&5O4F5P86-K97(Z(&9O=6YD('-Y<W1E;2!S=&%R="!C;V1E.B!S M=')E86T@<V5E;7,@=&@8F4@<V-R86UB;&5D(&-"G(@;F]T(&1E;75L=&EP M;&5X960-"DIU;" Q." P.#HT,CHP-"!M961I82!V9');-#DV.5TZ(&-6:61E M;U)E<&%C:V5R.B!S:VEP<&5D(#$U-#4@8GET97,@=VAI;&4@<WEN8VEN9R!O M;B!N97AT('!I8W1U<F4-"DIU;" Q." P.#HT,CHP-"!M961I82!V9');-#DV M.5TZ(&-6:61E;U)E<&%C:V5R.B!S:VEP<&5D(#0Y,R!B>71E<R!W:&EL92!S M>6YC:6YG(&]N(&YE>'0@<&EC='5R90T*2G5L(#$X(# X.C0R.C T(&UE9&EA M('9D<ELT.38Y73H@8U9I9&5O4F5P86-K97(Z('-K:7!P960@,C S.2!B>71E M<R!W:&EL92!S>6YC:6YG(&]N(&YE>'0@<&EC='5R90T*2G5L(#$X(# X.C0R M.C T(&UE9&EA(&QA<W0@;65S<V%G92!R97!E871E9" U('1I;65S#0I*=6P@ M,3@@,#@Z-#(Z,#0@;65D:6$@=F1R6S0Y-CE=.B!C5FED96]297!A8VME<CH@ M<VMI<'!E9" Q,SDX(&)Y=&5S('=H:6QE('-Y;F-I;F<@;VX@;F5X="!P:6-T M=7)E#0I*=6P@,3@@,#@Z-#(Z,#0@;65D:6$@=F1R6S0Y-CE=.B!C5FED96]2 M97!A8VME<CH@<VMI<'!E9" T(&)Y=&5S('1O('-Y;F,@;VX@;F5X="!P:6-T M=7)E#0I*=6P@,3@@,#@Z-#(Z,C @;65D:6$@=F1R6S0Y-S!=.B!%4E)/4CH@ M,2!R:6YG(&)U9F9E<B!O=F5R9FQO=R H-C4@8GET97,@9')O<'!E9"D-"DIU M;" Q." P.#HT,CHR-B!M961I82!V9');-#DW,%TZ($524D]2.B Q,# R,B!R M:6YG(&)U9F9E<B!O=F5R9FQO=W,@*#$X.#0Q,S8@8GET97,@9')O<'!E9"D- M"DIU;" Q." P.#HT,CHS,B!M961I82!V9');-#DW,%TZ($524D]2.B Y.#0P M(')I;F<@8G5F9F5R(&]V97)F;&]W<R H,3@T.3DR,"!B>71E<R!D<F]P<&5D M*0T*2G5L(#$X(# X.C0R.C,U(&UE9&EA('9D<ELT.38X73H@15)23U(Z('9I M9&5O(&1A=&$@<W1R96%M(&)R;VME;@T*2G5L(#$X(# X.C0R.C,U(&UE9&EA M('9D<ELT.38X73H@:6YI=&EA=&EN9R!E;65R9V5N8WD@97AI= T*2G5L(#$X M(# X.C0R.C,U(&UE9&EA('9D<ELT-34U73H@96UE<F=E;F-Y(&5X:70@<F5Q M=65S=&5D("T@<VAU='1I;F<@9&]W;@T*2G5L(#$X(# X.C0R.C,U(&UE9&EA M('9D<ELT-34U73H@<W1O<'!I;F<@<&QU9VEN.B!C;&]C:PT*2G5L(#$X(# X M.C0R.C,U(&UE9&EA('9D<ELT-34U73H@<W1O<'!I;F<@<&QU9VEN.B!F96UO M;@T*2G5L(#$X(# X.C0R.C,U(&UE9&EA('9D<ELT-34U73H@<W1O<'!I;F<@ M<&QU9VEN.B!D=F0-"DIU;" Q." P.#HT,CHS-2!M961I82!V9');-#4U-5TZ M('-T;W!P:6YG('!L=6=I;CH@;7!L87EE<@T*2G5L(#$X(# X.C0R.C,U(&UE M9&EA('9D<ELT-34U73H@<W1O<'!I;F<@<&QU9VEN.B!S>7-I;F9O#0I*=6P@ M,3@@,#@Z-#(Z,S4@;65D:6$@=F1R6S0U-35=.B!S=&]P<&EN9R!P;'5G:6XZ M(')E;6]T90T*2G5L(#$X(# X.C0R.C,U(&UE9&EA('9D<ELT-34U73H@<W1O M<'!I;F<@<&QU9VEN.B!S:VEN8W5R<V5S#0I*=6P@,3@@,#@Z-#(Z,S4@;65D M:6$@=F1R6S0U-35=.B!S=&]P<&EN9R!P;'5G:6XZ('AI;F4-"DIU;" Q." P M.#HT,CHS-2!M961I82!V9');-#4U-5TZ(&QO861I;F<@+W9I9&5O+W9D<BTQ M+C,N,C<O=&AE;65S+W-T=&YG+61E9F%U;'0N=&AE;64-"DIU;" Q." P.#HT M,CHS-2!M961I82!V9');-#4U-5TZ('1I;65R(#(@*#0@,#@R-2TP.3 P("=% M=F5R>6)O9'D@3&]V97,@4F%Y;6]N9"<I('-T;W -"DIU;" Q." P.#HT,CHS M-B!M961I82!V9');-#4U-5TZ('-A=F5D('-E='5P('1O("]V:61E;R]V9'(M M,2XS+C(W+W-E='5P+F-O;F8-"DIU;" Q." P.#HT,CHS-B!M961I82!V9'); M-#4U-5TZ(&1E;&5T:6YG('!L=6=I;CH@8VQO8VL-"DIU;" Q." P.#HT,CHS M-B!M961I82!V9');-#4U-5TZ(&1E;&5T:6YG('!L=6=I;CH@9F5M;VX-"DIU M;" Q." P.#HT,CHS-B!M961I82!V9');-#4U-5TZ(&1E;&5T:6YG('!L=6=I M;CH@9'9D#0I*=6P@,3@@,#@Z-#(Z,S8@;65D:6$@=F1R6S0U-35=.B!D96QE M=&EN9R!P;'5G:6XZ(&UP;&%Y97(-"DIU;" Q." P.#HT,CHS-B!M961I82!V M9');-#4U-5TZ(&1E;&5T:6YG('!L=6=I;CH@<WES:6YF;PT*2G5L(#$X(# X M.C0R.C,V(&UE9&EA('9D<ELT-34U73H@9&5L971I;F<@<&QU9VEN.B!R96UO M=&4-"DIU;" Q." P.#HT,CHS-B!M961I82!V9');-#4U-5TZ(&1E;&5T:6YG M('!L=6=I;CH@<VMI;F-U<G-E<PT*2G5L(#$X(# X.C0R.C,V(&UE9&EA('9D M<ELT-34U73H@9&5L971I;F<@<&QU9VEN.B!X:6YE#0I*=6P@,3@@,#@Z-#(Z M,S8@;65D:6$@=F1R6S0U-35=.B!E>&ET:6YG#0I*=6P@,3@@,#@Z-#(Z,S8@ B;65D:6$@=F1R6S0U-35=.B!E;65R9V5N8WD@97AI="$-"@`` ` end
Hi,
Simon Baxter wrote:
Hhm, there is nothing mentioned about these threads. I was looking for messages like the following:
Jul 16 23:13:02 video vdr[3153]: switching to channel 2055 Jul 16 23:13:02 video vdr[3516]: non blocking file reader thread ended (pid=3516, tid=507914) Jul 16 23:13:02 video vdr[3515]: dvbplayer thread ended (pid=3515, tid=491529) Jul 16 23:13:02 video vdr[3573]: transfer thread started (pid=3573, tid=524297) Jul 16 23:13:02 video vdr[3574]: receiver on device 1 thread started (pid=3574, tid=540682) Jul 16 23:13:02 video vdr[3575]: TS buffer on device 1 thread started (pid=3575, tid=557067) Jul 16 23:13:04 video vdr[3573]: setting audio track to 1 Jul 16 23:13:14 video vdr[3153]: switching device 1 to channel 2055 Jul 16 23:13:14 video vdr[3153]: timer 1 (2055 2313-2318 '@TITLE EPISODE') start Jul 16 23:13:14 video vdr[3153]: waiting for EPG info... Jul 16 23:13:18 video vdr[3153]: no EPG info available Jul 16 23:13:18 video vdr[3153]: record /video/@ASTRA_HD/2005-07-16.23:13.50.50.rec Jul 16 23:13:18 video vdr[3153]: creating directory /video/@ASTRA_HD Jul 16 23:13:18 video vdr[3153]: creating directory /video/@ASTRA_HD/2005-07-16.23:13.50.50.rec Jul 16 23:13:18 video vdr[3153]: recording to '/video/@ASTRA_HD/2005-07-16.23:13.50.50.rec/001.vdr' Jul 16 23:13:18 video vdr[3582]: file writer thread started (pid=3582, tid=573452) Jul 16 23:13:18 video vdr[3583]: recording thread started (pid=3583, tid=589837) Jul 16 23:13:18 video vdr[3153]: max. latency time 5 seconds Jul 16 23:18:00 video vdr[3583]: recording thread ended (pid=3583, tid=589837) Jul 16 23:18:00 video vdr[3582]: file writer thread ended (pid=3582, tid=573452)
Do you find any file that contains this data? On my system it is in /var/log/messages. Maybe you have to run vdr with debugging enabled (-l 3).
It might be possible, that at 08:42:04 the cVideoRepacker was resyncing, e. g. due to some garbage that is comming in after switching the channel.
You wrote it happend just once so far (plus once with 1.3.26). Did you get some image distortions from time to time (or just rarely)? Maybe cVideoRepacker just discovered some stream corruption that otherwise (= before 1.3.26) would only have been noticeable on screen. Something like that might also be a driver issue.
Maybe some of the missing logfile entries would put light on this issue.
I think, none of them should have any receiver active. Maybe it's just the transfer thread for live-TV and the recorder thread that both have a receiver running. What happend to live-TV at that time?
Sorry, it seems that the below marked lines where not obvious enough. They have to go into remux.c, cRepacker::Put() respectively cVideoRepacker::Repack(). Be aware that these changes will produce big logfiles :-(
Bye.
Hi,
I'd like to invite you to test the attached patch which now also supports MPEG1 video streams (vdr-1.3.27-remux-repacker.patch).
I only had a single negative report so far. But as it was the only report at all, there are just a few possibilities:
A) there was just a single tester B) all positive testers didn't report their success C) all positive testers are still waiting for failure
Anyway, VDR-1.3.28 is right ahead, so please hurry up testing ;-)
Bye.
On Thu, Jul 21, 2005 at 11:05:39PM +0200, Reinhard Nissl wrote:
A) there was just a single tester
You are wrong here :-)
B) all positive testers didn't report their success C) all positive testers are still waiting for failure
I shall go in C) :-)
Anyway, VDR-1.3.28 is right ahead, so please hurry up testing ;-)
My VDR runs lots of time with it now, without problem !!!
Hello Reinhard,
On Thu, 21 Jul 2005 23:05:39 +0200 Reinhard Nissl rnissl@gmx.de wrote:
| I only had a single negative report so far. But as it was the only | report at all, there are just a few possibilities: | | A) there was just a single tester | B) all positive testers didn't report their success | C) all positive testers are still waiting for failure | | Anyway, VDR-1.3.28 is right ahead, so please hurry up testing ;-)
Sorry, i haven't have too much time to play with VDR lately, but so far my VDR 1.3.27 has been working really nicely since i've installed it.
I'd like to help you with this, can you just tell me :
- a quick reminder of why this needs to be changed, and - will it break something to my old (and very old) recording, will i still be able to edit them ? - as i don't use the Xine plugin, do i only need the vdr-1.3.27-remux-repacker.patch ?
...
ok i've just patched my already somewhat patched VDR :) and will report any issues
Thanks,
Philippe
FYI: my setup : 1 FF Rev 1.3 TT DVB-S, VDR 1.3.27, Plugins: mplayer/mp3,dvd, dvdselect,femon,weather-ng,streamdev,text2skin
Hi,
Philippe Gramoullé wrote:
VDR's index file for recordings has byte granularity but adresses complete PES packets. When VDR needs to send an I frame to a device (e. g. for fast forward or editing cutting marks) it seeks to the index of the I frame and reads the data up to the next B frame, i. e. it stops just before the PES packet which contains the start of the B frame. But it is likely that this packet also contains the tail of the I frame before the B frame starts. So VDR will read to few data which results in an incomplete I frame. The result is that xine doesn't show incomplete frames, i. e. moving a cutting mark results in no screen update. A FF card might have shown some garbage or blackness in the last few lines of the image.
cVideoRepacker resolves this issue by ensuring to start a new PES packet when a new frame starts.
It will not break any old recordings. For old recordings, you still have to apply a (soon to be updated) patch, that resolves the short I frames issue in a different way. The patch is not necessary for new recordings but it won't hurt either.
As I expect VDR-1.3.28 to contain both patches, I'd like you to test both, too. As at least most DVD still images contain a sequence end code, I'd expect a FF card to handle it correctly, too.
Bye.
On Samstag, 23. Juli 2005 13:45, Reinhard Nissl wrote:
Are there some sample streams available ? I'm asking this because I get an updated picture upon moving cut marks. That is with softdevice running with vdr-1.3.27 and vdr-1.2.1 recordings.
Perhaps it's time to test your patch too :-) .
Hi,
Stefan Lucke wrote:
Well, any stream will do, especially HDTV streams. The result depends on the implementation. When softdevice displays incomplete frames, everything works almost properly. Maybe you see that part of the image's last slice may be black or garbage.
xine-lib discards incomplete frames. The problem exists for quite a long time already. My first approach in successfully displaying a still image was to send the data 4 times to xine. But this didn't work anymore when I wanted to edit cut marks for the HDTV broadcast Spiderman. After debugging a lot, I realized that the I frame was incomplete. The last slice was completely missing.
With the patches it is now possible to send the still image just once to xine, which speeds up moving cut marks accordingly.
Bye.
On Samstag, 23. Juli 2005 21:29, Reinhard Nissl wrote:
Thats the same as softdevice does.
But this didn't work anymore when I wanted to edit cut marks for the HDTV broadcast Spiderman.
Oh, I never tried HDTV streams.
That sounds fine. I'll try "sending once" in softdevice too. Thanks for your explanation.
On Friday 22 July 2005 00:05, Reinhard Nissl wrote:
B) all positive testers didn't report their success C) all positive testers are still waiting for failure
It's been running over a week now so I think it's safe to say it doesn't cause any problems on my setup with dxr3.