Re: [vdr] Weird recording problem
Hi,
It's the same problem I had in France with the channel TNT "France 4". I
proposed this dirty patch in May 2010, without understanding why :
--- remux.c2010-05-04 14:55:50.0 +0200
+++ remux.c.orig 2010-05-04 21:57:38.0 +0200
@@ -960,6 +960,7 @@
return Processed; // flush everything before this new frame
newFrame = true;
independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1; // I-Frame
+ if (((Data[i + 2] >> 3) & 0x07) == 0) { independentFrame = 1;}
if (synced) {
if (framesPerPayloadUnit <= 1)
scanning = false;
I use it since without problem.
Senufo
Date: Fri, 03 Jun 2011 22:33:53 +0200
From: Johan Andersson
Subject: Re: [vdr] Weird recording problem
To: vdr@linuxtv.org
Message-ID:<4de94531.2010...@jna.pp.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Klaus,
I got a new reply from Teracom, where they had looked into this and
could not see any problem on their end. They did say they had recently
changed coding platform for TV6 though but it produced correct codes.
So, I did some further analysis of this, and I believe now the error is
in vdr/remux.c.
It seems the 'new coding platform', before an I-frame, always puts the
picture startcode, ie '0100' at the end of the TS packet. This means
that the code:
independentFrame = ((Data[i + 2]>> 3)& 0x07) == 1; // I-Frame
looks at the wrong byte, as i+2> TS_SIZE
For non-I frames it can appear anywhere in the packet. The idea seems to
be that an I-frame is always at the start of a TS-packet, do not ask me why.
So, your instinct of rejecting my suggestion for a patch was correct.
I have sample TS data of this stream, or dvbsnoop output of the relevant
PID, if you are interested.
/Johan
Johan Andersson skrev 2011-05-29 19:14:
[...]
I got a very positive sounding response from Teracom. I got the
impression they are really going to fix this. For anyone else interested
I simply mailed their support address on their homepage
http://www.teracom.se, ie: kundtja...@teracom.se
/Johan
Klaus Schmidinger skrev 2011-05-28 23:55:
On 28.05.2011 10:57, Johan Andersson wrote:
I sent off a question to customer support at Teracom and got a reply
indicating that they do have an error relating to these channels in
their 'coding platform'.
Thanks for actually doing this - finally a broadcaster who at
least admits *they* have a problem ;-)
'Your problem seems to relate to the error we have', was their
statement. They had no due date for fixing it though.
Maybe they would give this more priority if more people contacted
them about this. Once replying to inquiries takes up a considerable
amount of their time, they might consider doing something about it.
Perhaps you should post here how to contact them, so other viewers
of their channels could also bother them ;-)
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Record with 1.7.4 or 1.7.5 and iptv
Hi, Thanks for your replies. I'm not a specialist but how I can help you ? I can test or modify the code if you tell me how and what must change. Regards Senufo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Record with 1.7.4 or 1.7.5 and iptv
Hi,
I have try to understand how work remux.c with the steam and when I add
in remux.c after
for (int i = PayloadOffset; scanning && i < TS_SIZE; i++) {
scanner <<= 8;
scanner |= Data[i];
line 770 : dbgframes("type = %02X, scanner = %10X \n", type, scanner);
I have this output :
type = 02, scanner = 0
type = 02, scanner = 0
type = 02, scanner = 0
type = 02, scanner = 1
type = 02, scanner =109
type = 02, scanner = 10950
type = 02, scanner =1095000
type = 02, scanner =950
type = 02, scanner = 5000
type = 02, scanner = 1
type = 02, scanner =106
type = 02, scanner = 10600
type = 02, scanner =1060001
type = 02, scanner =60001C0
type = 02, scanner = 1C080
type = 02, scanner =1C08000
type = 02, scanner = C080
type = 02, scanner = 8000
type = 02, scanner = 1
type = 02, scanner =106
type = 02, scanner = 10601
type = 02, scanner =1060101
type = 02, scanner =6010114
type = 02, scanner =1011480
type = 02, scanner =1148000
type = 02, scanner = 1480
type = 02, scanner = 8000
type = 02, scanner = 1
type = 02, scanner =121
type = 02, scanner = 121AA
type = 02, scanner =121AA0A
type = 02, scanner = 21AA0A71
type = 02, scanner = AA0A716A
type = 02, scanner =A716A51
type = 02, scanner = 716A5111
type = 02, scanner = 6A511177
type = 02, scanner = 511177FF
type = 02, scanner = 1177FFA0
type = 02, scanner = 77FFA034
type = 02, scanner = FFA0344A
type = 02, scanner = A0344A2A
type = 02, scanner = 344A2A4A
type = 02, scanner = 4A2A4AC0
...
Never stream with type 0x1B
When I play stream with mplayer as : mplayer rtp://@232.0.1.17:8200 I
have this output
TS file format detected.
Stream not seekable!
VIDEO H264(pid=1217) AUDIO MPA(pid=1317) NO SUBS (yet)! PROGRAM N. 1017
Stream not seekable!
FPS seems to be: 25.00
==
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==
==
Trying to force audio codec driver family libmad...
Opening audio decoder: [libmad] libmad mpeg audio decoder
AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000)
Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
==
Is this is the mpeg2 streams with H264 codec ?
How to identify this stream ?
Thanks for you help.
Regards
Senufo
>/ Hi,
/>/
/>/ I have try the patch and now no have error :
/>/
/>/ unknown frame duration (1800), assuming 25 fps
/>/
/>/ But the problem with Video Data Broken stay.
/>/
/>/ Here are the errors with remux.c compile with static bool DebugFrames =
true;
/>/
/>/ in /var/log/messages
/>/
/>/ Apr 19 19:10:15 solo vdr: [6769] Title: 'Sept à huit' Subtitle: '(null)'
/>/ Apr 19 19:10:15 solo vdr: [6769] record
/mnt/sda8/henri/video_vdr/@Sept_à_huit/2009-04-19.19.10.1-0.rec
/
>Hi,
>Klaus Schmidinger schrieb:
>/ This indicates that cFrameDetector::Analyze() doesn't find any frames.
/>/ Take a look at the code beginning at
/>/
/>/ case 0x1B: // MPEG 4 video
/>/ if (scanner == 0x0109) { // Access Unit
Delimiter
/>/
/>/
/>/ Apparently the scanner never gets to be 0x0109.
/>/ We'll need to know what condition to use to detect the frames.
/
>>According to spec, AUD is optional. Chapter 7.4.1.2.3 is not too
>>complicated to implement and most often sufficient.
>>For complete support, 7.4.1.2.4 is required too, but more
>>compliated and cannot be implemented without in depth parsing of
>>several H.264 data str
Re: [vdr] Record with 1.7.4 or 1.7.5 and iptv
Hi,
I have add
type = 0x1B;
before the
switch (type) {
and now record work fine !!
Senufo
>This looks like the "Access Unit Delimiter" code.
>
>Please try to force 'type' to 0x1B, for instance by putting
>
> type = 0x1B;
>
>right before the
>
> switch (type) {
>
>line. Does it work then?
>
>Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Record with 1.7.4 or 1.7.5 and iptv
Hi,
I found the error. With IPTV you must define the type of stream in channels.conf
In my channels.conf I wrote
TF1;IPTV:1:IPTV|S0P0|UDP|232.0.1.17|8200:P:0:1217=2:1317:0:0:1:0:0:0
where VPID = 1217 and stream type = 2.
If i change stream type with 27 (0x1B in Hexa). Record works fine.
Thanks Klaus for your help
Senufo
On 26.04.2009 18:11, Senufo wrote:
>/ Hi,
/>/
/>/ I have add
/>/
/>/ type = 0x1B;
/>/
/>/ before the
/>/
/>/ switch (type) {
/>/
/>/ and now record work fine !!
/
Well, then all we need is a way to find out the correct
video stream type. Apparently the PMT says it is 2, while
in fact it is 0x1B.
Does anybody know why the PMT is "lying", or how to detect
that it actually isn't 2, but 0x1B?
Klaus
>>/ This looks like the "Access Unit Delimiter" code.
/>>/
/>>/ Please try to force 'type' to 0x1B, for instance by putting
/>>/
/>>/ type = 0x1B;
/>>/
/>>/ right before the
/>>/
/>>/ switch (type) {
/>>/
/>>/ line. Does it work then?
/>>/
/>>/ Klaus
/
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Record with 1.7.4 or 1.7.5 and iptv
Hi, I have tested with the first (TF1) and the second channel (France 2) With this channels.conf TF1;IPTV:1:IPTV|S1P1|UDP|232.0.1.17|8200:P:0:1217=27:1317:0:0:1017:0:0:0 France 2;IPTV:2:IPTV|S1P1|UDP|232.0.1.1|8200:P:0:1201=27:1301=fra:0:0:1001:0:0:0 France 3;IPTV:3:IPTV|S0P0|UDP|232.0.1.2|8200:P:0:1202=2:1302:0:0:1:0:0:0 France 4;IPTV:4:IPTV|S0P0|UDP|232.0.1.9|8200:P:0:1203=2:1303:0:0:1:0:0:0 France 5;IPTV:5:IPTV|S0P0|UDP|232.0.1.4|8200:P:0:1204=2:1304:0:0:1:0:0:0 I can only record TF1 and France 2. With IPTV configured with filters on You can find stream record with emcast here : http://rapidshare.com/files/227699836/TF1.raw.html and http://rapidshare.com/files/227700760/France2.raw.html Regards Senufo >>/ I found the error. With IPTV you must define the type of stream in >>channels.conf />/> In my channels.conf I wrote / >No, yo don't have to. The IPTV plugin has section filters implemented >(if don't disable/blacklist them in setup options!). They seem to work >in your setup too, but, please, correct me if your channel 39 isn't >France 2. A snip from your first post.: >/> France 2;IPTV:2:IPTV|S0P0|UDP|232.0.1.1|8200:P:0:1201=2:1301:0:0:1:0:0:0 />/> changing pids of channel 39 from 0+0=2:0:0:0 to 1210+1210=27:1310=fra:0:0 / >If the channel 39 really is the France 2, so question still remain, why >the VDR's video type detection fails on TF1 as the mplayer do it rigth. >You could provide a small video sample recording the multicast stream http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Record with 1.7.4 or 1.7.5 and iptv
Hi, Rofa, thank you for these details, now I understand better the configuration parameters. Finaly I use these parameters : Use section filtering : yes Disable filters : 0 and, as Klaus say, I have change all channels with stream type = 27 (0x1B). Now I can record all channels. Klaus and Rofa, thank you very much for your help ># scants TF1.raw 2>/dev/null >PAT: >0: sid=0x03f9 pmt_pid=0x045d >PMT: sid=0x03f9 pcr=0x04c1 vpid=0x04c1 [h264] apid=0x0525 [mpeg2audio] >>0x0525: MPEG Audio, layer2, 48000 Hz, 128 kbits/s, stereo >0x04c1: H264 profile=Main level=3.0 sps=0 poc=0 ref=4 544x576 PIC-AFF >SDT: >0: sid=0x03f9 name='TF1' provider='France Telecom' >0x04c1: gop_len: min=3 max=64 avg=45.6 > > France > > 2;IPTV:2:IPTV|S1P1|UDP|232.0.1.1|8200:P:0:1201=27:1301=fra:0:0:1001:0:0:0 > ># scants France2.raw 2>/dev/null >PAT: >0: sid=0x03e9 pmt_pid=0x044d >PMT: sid=0x03e9 pcr=0x04b1 vpid=0x04b1 [h264] apid=0x0515 [mpeg2audio] >0x0515: MPEG Audio, layer2, 48000 Hz, 128 kbits/s, stereo >0x04b1: H264 profile=Main level=3.0 sps=0 poc=0 ref=4 544x576 PIC-AFF >SDT: >0: sid=0x03e9 name='France 2' provider='FT' >0x04b1: gop_len: min=10 max=56 avg=47.2 > > I can only record TF1 and France 2. > > With IPTV configured with filters on > >Both streams seem to be valid. You've enable both PID and NID scanners >on for working channels, but these should be disabled by default (enable >pid scanner only if you don't get the live video and sid scanner if you >don't get EPG). The "Use section filtering" option should be enabled and >"Disable filter" option should NOT contain "PAT (0x00)" entry. Please, >verify these. >"Use section filtering: Define whether the section filtering shall be >used. Section filtering means that IPTV plugin tries to parse and >provide VDR with secondary data about the currently active stream. VDR >can then use this data for providing various functionalities such as >automatic pid change detection and EPG etc. Enabling this feature does >not affect streams that do not contain section data." >"Disable filter: Define an ill-behaving filter to be blacklisted." >The next thing to debug would be: Does cPatFilter::Process() get any >data and why is a wrong value set to Vtype? >BR, >-- >rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Moving to a stream mpeg or h264 with vdr-1.7.9
Hi, When I make a mark with the 0 key if I want to move it by pressing 4 or 6 it works when the stream is the H264 but when it's mpeg2 the mark moves but the image remains static. Regards Senufo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Moving to a stream mpeg or h264 with vdr-1.7.9
On 12/11/2009, Theunis Potgieter wrote: > what is your output device? Hi, I use vdr-xine-0.9.3. on a nvidia card. I have the same problem with and without vdpau with 180.51 and 190.42 nvidia modules. Regards Senufo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Moving to a stream mpeg or h264 with vdr-1.7.9
Hi, I just found an error when I use the keys 4 or 7 for me to move in the mpeg2 stream (vdr-17.9 with vdr-xine 0.9.3). Clear(1785)! StillPicture: 0x191da2a0, 0 FIXME: xineDevice.c:1321 FIXME: xineDevice.c:2075 Clear(1786)! StillPicture: 0x19179110, 0 FIXME: xineDevice.c:1321 FIXME: xineDevice.c:2075 Thanks Senufo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Moving to a stream mpeg or h264 with vdr-1.7.9
HI, thank you, I'll wait for bug fix Regards Senufo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.7.10 no record channel
Hello This weekend I had a problem with the chains of the transponder 778 000 DTT channels with France 4, i> TELE, Gulli, Virgin 17, BFM TV, Direct 8. I could not see them while all other channels were working correctly. So I made a new scan with: sudo w_scan -c fr My new channels.conf: France 4;NTN:778000:B8M2:T:27500:720=2:730=fra:745:0:519:8442:2:0 i>TELE;NTN:778000:B8M2:T:27500:420=2:430=fra:445:0:516:8442:2:0 Gulli;NTN:778000:B8M2:T:27500:620=2:630=fra:645:0:518:8442:2:0 Virgin 17;NTN:778000:B8M2:T:27500:520=2:530=fra:545:0:517:8442:2:0 BFM TV;NTN:778000:B8M2:T:27500:320=2:330=fra:345:0:515:8442:2:0 Direct 8;NTN:778000:B8M2:T:27500:120=2:130=fra:145:0:513:8442:2:0 My old channels.conf France 4;NTN:778000:B8M2:T:27500:166=2:104:0:0:519:8442:2:0 i>TELE;NTN:778000:B8M2:T:27500:163=2:92:0:0:516:8442:2:0 Gulli;NTN:778000:B8M2:T:27500:165=2:100:48:0:518:8442:2:0 Virgin 17;NTN:778000:B8M2:T:27500:164=2:96:44:0:517:8442:2:0 BFM TV;NTN:778000:B8M2:T:27500:162=2:88:0:0:515:8442:2:0 Direct 8;NTN:778000:B8M2:T:27500:160=2:80:32:0:513:8442:2:0 Now I can see these channels directly but when I want to make a record that does not work I have these error messages: May 2 2:09:03 p.m. karmic vdr: [8324] switching device 3 to Channel 9 May 2 2:09:03 p.m. karmic vdr: [8324] Timer 24 (9 from 1409 to 1709 '@ EPISODE TITLE') home May 2 2:09:03 p.m. karmic vdr: [8324] Title: 'L'école des fans' Subtitle: '(null)' May 2 2:09:03 p.m. karmic vdr: [8324] record / video / @ The école_des_fans / 2010-05-02.14.09.9-0.rec May 2 2:09:03 p.m. karmic vdr: [8324] Creating directory / video / @ The école_des_fans / 2010-05-02.14.09.9-0.rec May 2 2:09:03 p.m. karmic vdr: [8324] recording to '/ video / @ The école_des_fans / 2010-05-02.14.09.9-0.rec/1.ts' May 2 2:09:03 p.m. karmic vdr: [11693] recording thread started "(pid = 8324, tid = 11693) May 2 2:09:03 p.m. karmic vdr: [8324] info: Registration has begun May 2 2:09:03 p.m. karmic vdr: [11694] Effects EnigmaNG thread started "(pid = 8324, tid = 11694) May 2 2:09:06 p.m. karmic vdr: [11694] Effects EnigmaNG thread ended (pid = 8324, tid = 11694) May 2 2:09:07 p.m. karmic vdr: [11751] Effects EnigmaNG thread started "(pid = 8324, tid = 11751) May 2 2:09:11 p.m. karmic vdr: [11751] Effects EnigmaNG thread ended (pid = 8324, tid = 11751) May 2 2:09:14 p.m. karmic vdr: [11864] Effects EnigmaNG thread started "(pid = 8324, tid = 11864) May 2 2:09:20 p.m. karmic vdr: [11055] ERROR: video data stream broken May 2 2:09:20 p.m. karmic vdr: [11055] emergency exit request to setup Ignored LUKAS May 2 2:09:21 p.m. karmic vdr: [8324] Timer 24 (9 from 1409 to 1709 '@ The School of fans') set to event Sun 5.2.2010 14:30-16:05 'Lois and Clark' May 2 2:09:34 p.m. karmic vdr: [11693] ERROR: video data stream broken May 2 2:09:34 p.m. karmic vdr: [11693] emergency exit request to setup Ignored LUKAS May 2 2:09:39 p.m. karmic vdr: [11864] Effects EnigmaNG thread ended (pid = 8324, tid = 11864) May 2 2:09:39 p.m. karmic vdr: [12215] Effects EnigmaNG thread started "(pid = 8324, tid = 12215) May 2 2:09:51 p.m. karmic vdr: [11055] ERROR: video data stream broken I'm running Ubuntu 9.10 with 1.7.10 vdr-launched with the following command: screen -S VDR -dm ./vdr -u vdr -c /video/vdrconf/ -v /video -L ./PLUGINS/lib --localedir=$VDRPATH/locale\ -P'sc' \ -P'xine -r' \ -P'streamdev-server'\ -P'streamdev-client'\ -P'skinenigmang' \ -P'extrecmenu' \ -P'epgsearch' \ -P'pin' \ -P'femon' Currently in France some transponders changes configuration to go all digital. Does anyone has an idea? thank you for your help Senufo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.7.10 no record channel
Hi,
I found the problem. VDR does not detect the frame independent in this
stream because in the function :
cFrameDetector:: Analyze (const uchar * Data, int Length)
in the file remux.c.
((Data [i +2]>> 3) & 0x07) is equal to 0 instead of 1 for stream that work.
I applied this patch :
--- remux.c2010-05-04 14:55:50.0 +0200
+++ remux.c.orig 2010-05-04 21:57:38.0 +0200
@@ -960,6 +960,7 @@
return Processed; // flush everything before this new frame
newFrame = true;
independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1; // I-Frame
+ if (((Data[i + 2] >> 3) & 0x07) == 0) { independentFrame = 1;}
if (synced) {
if (framesPerPayloadUnit <= 1)
scanning = false;
and record is working again.
I do not know what has changed in the stream.
I tested this patch since yesterday and so far I have not had any problems.
What do you think?
Senufo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.10 no record channel
Hi,
Thanks Klaus
Klaus I agree, but the video looks good because I can see this live stream and
when I use the patch records are correct.
I did a test with vdr 1.6.0 with the same channels.conf and there I can see the
live stream and recordings works.
Why ?
Senufo
On 05.05.2010 22:11, Senufo wrote:
> Hi,
>
> I found the problem. VDR does not detect the frame independent in this
> stream because in the function :
>
> cFrameDetector:: Analyze (const uchar * Data, int Length)
>
> in the file remux.c.
>
> ((Data [i +2]>> 3) & 0x07) is equal to 0 instead of 1 for stream that work.
>
> I applied this patch :
>
> --- remux.c2010-05-04 14:55:50.0 +0200
> +++ remux.c.orig 2010-05-04 21:57:38.0 +0200
> @@ -960,6 +960,7 @@
>return Processed; // flush everything before this new frame
> newFrame = true;
> independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1; // I-Frame
> + if (((Data[i + 2] >> 3) & 0x07) == 0) { independentFrame = 1;}
> if (synced) {
>if (framesPerPayloadUnit <= 1)
> scanning = false;
>
> and record is working again.
> I do not know what has changed in the stream.
>
> I tested this patch since yesterday and so far I have not had any problems.
>
> What do you think?
If this stream marks independent frames with '0' instead if '1',
I would say it is broken.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Re : vdr 1.7.10 no record channel
Hi,
I read the ISO / IEC 13818-2: 1995 for trying to better understand how
is the detection of I-frames.
In Chapter 6.2 the header image will begin by picture_start_code
in remux.c
if (scan == 0x0100) (/ / Picture Start Code
If I understand the detection of the i-frame is in the
picture_coding_type according to Table 6-12
picture_coding_type / coding method
000 / forbidden
001 / intra-coded (I)
010 / predictive-coded (P)
011 / bidirectionally-predictive-coded (B)
100 / Shall Not Be Used (dc intra-coded (D) in ISO/IEC11172- 2)
101 / reserved
110 / reserved
111 / reserved
I do not understand this line of code:
independentFrame = ((Data [i +2]>> 3) & 0x07) == 1 / / I-Frame
thank you for your answers
Regards
Senufo
On 05/19/10 22:20, Senufo wrote:
> Hi,
>
> Thanks Klaus
> Klaus I agree, but the video looks good because I can see this live
> stream and when I use the patch records are correct.
> I did a test with vdr 1.6.0 with the same channels.conf and there I can
> see the live stream and recordings works.
>
> Why ?
I have no idea.
Of course, the whole frame detection is different in VDR 1.7.
You might want to debug that area to see why it doesn't work
any more. Simply changing that bit from '1' to '0' can't be
the solution.
Klaus
> On 05.05.2010 22:11, Senufo wrote:
>
>> > Hi,
>> > > I found the problem. VDR does not detect the frame independent
in this
>> > stream because in the function :
>> > > cFrameDetector:: Analyze (const uchar * Data, int Length)
>> > > in the file remux.c.
>> > > ((Data [i +2]>> 3) & 0x07) is equal to 0 instead of 1 for stream
>> that work.
>> > > I applied this patch :
>> > > --- remux.c2010-05-04 14:55:50.0 +0200
>> > +++ remux.c.orig 2010-05-04 21:57:38.0 +0200
>> > @@ -960,6 +960,7 @@
>> >return Processed; // flush everything before this new frame
>> > newFrame = true;
>> > independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1; //
I-Frame
>> > + if (((Data[i + 2] >> 3) & 0x07) == 0) { independentFrame = 1;}
>> > if (synced) {
>> >if (framesPerPayloadUnit <= 1)
>> > scanning = false;
>> > > and record is working again.
>> > I do not know what has changed in the stream.
>> > > I tested this patch since yesterday and so far I have not had any
>> problems.
>> > > What do you think?
>>
>
> If this stream marks independent frames with '0' instead if '1',
> I would say it is broken.
>
> Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
