Hello,
I'm use VDR on my server with a DVB-S card. I use it to stream TV channels and record TV shows. Recording works great for SD channels, but is broken for HD channels.
Whenever I ask it to record a HD TV show, it starts recording (but the .ts file doesn't grow in size) and after 30 seconds it terminates unexpectedly. It says the video data stream is broken, but it's actually fine! There are no problems with watching HD channels streamed from VDR...
I suggest VDR should stop taking care about the stream correctness and should just start recording. Because until then vdr-streamdev-server and wget are the only working combo.
Aside from that I don't understand why it terminates completely if it _thinks_ some bad data arrived. Data errors may happen at any time and it's not a valid reason for an emergency exit.
This one's an encrypted DVB-S2 channel, I've tried the FTA BBC HD too and it terminated as well.
The syslog:
Nov 14 11:55:26 hera vdr: [10024] switching device 1 to channel 8 Nov 14 11:55:26 hera vdr: [10024] timer 5 (8 1133-1340 'Rande s celebritou') start Nov 14 11:55:26 hera vdr: [10024] Title: 'Rande s celebritou' Subtitle: '(Win a Date with Tad Hamilton!) Dívce z malého města Kate Bosworth, posedlé hvězdnou slávou, se splní sen! Vyhraje rande se svým idolem filmového plátna a on ji začne zbožňovat. Jejímu nejlepšímu příteli se to' Nov 14 11:55:26 hera vdr: [10024] record /var/lib/video.00/Rande_s_celebritou/2010-11-14.11.33.8-0.rec Nov 14 11:55:26 hera vdr: [10024] cFileName::SetOffset: removing zero-sized file /var/lib/video.00/Rande_s_celebritou/2010-11-14.11.33.8-0.rec/00001.ts Nov 14 11:55:26 hera vdr: [10024] recording to '/var/lib/video.00/Rande_s_celebritou/2010-11-14.11.33.8-0.rec/00001.ts' Nov 14 11:55:26 hera vdr: [10056] recording thread started (pid=10024, tid=10056) Nov 14 11:55:26 hera vdr: [10035] timer 1 (8 1133-1340 'Rande s celebritou') set to event Ne 14.11.2010 11:35-13:30 'Rande s celebritou' Nov 14 11:55:57 hera vdr: [10056] ERROR: video data stream broken Nov 14 11:55:57 hera vdr: [10056] initiating emergency exit Nov 14 11:55:57 hera vdr: [10024] emergency exit requested - shutting down Nov 14 11:55:57 hera vdr: [10024] stopping plugin: streamdev-server
Best regards,
On 14.11.2010 12:07, Luboš Doležel wrote:
Hello,
I'm use VDR on my server with a DVB-S card. I use it to stream TV channels and record TV shows. Recording works great for SD channels, but is broken for HD channels.
Whenever I ask it to record a HD TV show, it starts recording (but the .ts file doesn't grow in size) and after 30 seconds it terminates unexpectedly. It says the video data stream is broken, but it's actually fine! There are no problems with watching HD channels streamed from VDR...
I suggest VDR should stop taking care about the stream correctness and should just start recording. Because until then vdr-streamdev-server and wget are the only working combo.
You can turn off the "emergency exit" in "Setup/Miscellaneous/Emergency exit". However, that won't change the fact that the recording can't be done, I guess.
Aside from that I don't understand why it terminates completely if it _thinks_ some bad data arrived. Data errors may happen at any time and it's not a valid reason for an emergency exit.
My guess is that it fails to detect the frame borders correctly. You may want to set DebugFrames to 'true' in remux.c and see what gets written to the console when you start a recording.
Klaus
Am 14.11.2010 12:07, schrieb Luboš Doležel:
Aside from that I don't understand why it terminates completely if it _thinks_ some bad data arrived. Data errors may happen at any time and it's not a valid reason for an emergency exit.
To clarify this: The emergency exit is triggered if and only if a recording did not record any (not a single byte of) data within 30 seconds. I think this is a valid criteria for an emergency.
In your case, as Klaus already wrote, it may have something to do with the fact that VDR wants to start the recording with an I-frame, and probably can't find one.
Cheers,
Udo
On 14/11/2010 15:15, Udo Richter wrote:
In your case, as Klaus already wrote, it may have something to do with the fact that VDR wants to start the recording with an I-frame, and probably can't find one.
Some patches have been posted suggesting that replacing in remux.c
independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1;
which, as I read the bit definition is correct in doc
http://dvd.sourceforge.net/dvdinfo/mpeghdrs.html
For further info: Frame type = 000 forbidden Frame type = 001 intra-coded (I) - iframe Frame type = 010 predictive-coded (P) - p frame Frame type = 011 bidirectionally-predictive-coded (B) - b frame Frame type = 100 shall not be used(dc intra-coded (D) in ISO/IEC11172-2) Frame type = 101 reserved Frame type = 110 reserved Frame type = 111 reserved
by something equivalent to
independentFrame = ((Data[i + 2] >> 3) & 0x6 == 0
saying basically that what is not a P frame, a D frame or B frame sould be an I-frame. I haven't yet tested it myself although I have a channel that I can play but not record.
Klaus says that the above code is not correct according t specs but failed to explain how we could get other values than 1, 2, 3, 4
-- eric
-- eric
On 14.11.2010 17:45, Eric Valette wrote:
On 14/11/2010 15:15, Udo Richter wrote:
In your case, as Klaus already wrote, it may have something to do with the fact that VDR wants to start the recording with an I-frame, and probably can't find one.
Some patches have been posted suggesting that replacing in remux.c
independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1;
which, as I read the bit definition is correct in doc
http://dvd.sourceforge.net/dvdinfo/mpeghdrs.html
For further info: Frame type = 000 forbidden Frame type = 001 intra-coded (I) - iframe Frame type = 010 predictive-coded (P) - p frame Frame type = 011 bidirectionally-predictive-coded (B) - b frame Frame type = 100 shall not be used(dc intra-coded (D) in ISO/IEC11172-2) Frame type = 101 reserved Frame type = 110 reserved Frame type = 111 reserved
by something equivalent to
independentFrame = ((Data[i + 2] >> 3) & 0x6 == 0
saying basically that what is not a P frame, a D frame or B frame sould be an I-frame. I haven't yet tested it myself although I have a channel that I can play but not record.
Klaus says that the above code is not correct according t specs but failed to explain how we could get other values than 1, 2, 3, 4
I don't see why I would have to ;-) The specs clearly state that only 001 marks an I-frame. Anything else is either explicitly not an I-frame, forbidden or reserved (i.e. undefined).
So unless there is an updated specification that actually assigns valid meanings to values above 4, you might want to contact your provider and ask them what kind of data they are broadcasting.
Klaus
On 14/11/2010 18:12, Klaus Schmidinger wrote:
On 14.11.2010 17:45, Eric Valette wrote:
Klaus says that the above code is not correct according t specs but failed to explain how we could get other values than 1, 2, 3, 4
I don't see why I would have to ;-)
Klaus,
I think I said clearly that the code looks correct and gave the pointer to the specs for unconvinced people. Those wanting to read the full specs http://neuron2.net/library/mpeg2/iso13818-2.pdf
The specs clearly state that only 001 marks an I-frame. Anything else is either explicitly not an I-frame, forbidden or reserved (i.e. undefined). So unless there is an updated specification that actually assigns valid meanings to values above 4, you might want to contact your provider and ask them what kind of data they are broadcasting.
That the only point where I start to disagree: dedicated DVB-T recorders manage to record this channel so here must be something else.
You now have got more than 10 identical reports on various country and various channels.
But thanks again for your work and support.
-- eric
Am 14.11.2010 18:21, schrieb Eric Valette:
I think I said clearly that the code looks correct and gave the pointer to the specs for unconvinced people. Those wanting to read the full specs http://neuron2.net/library/mpeg2/iso13818-2.pdf
Page 72, Table 6-12, picture_coding_type: 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
The patch changes the behavior of VDR to accept picture_coding_type=0 and picture_coding_type=1 as I-Frame. picture_coding_type=0 is clearly specified as forbidden. Anything I've missed?
Cheers,
Udo
On 14/11/2010 19:05, Udo Richter wrote:
Am 14.11.2010 18:21, schrieb Eric Valette:
I think I said clearly that the code looks correct and gave the pointer to the specs for unconvinced people. Those wanting to read the full specs http://neuron2.net/library/mpeg2/iso13818-2.pdf
Page 72, Table 6-12, picture_coding_type: 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
As listed in my first mail indeed.
The patch changes the behavior of VDR to accept picture_coding_type=0 and picture_coding_type=1 as I-Frame. picture_coding_type=0 is clearly specified as forbidden. Anything I've missed?
No. And *as Klaus* I dunno why this should be needed except if other parts of the logics for finding an I-frame is not robust enough for certain streams.
What really annoys me, is rather the duplication of identical bug reports for various DVB type (DVB-S2, DVB-T), various adapter in various countries when playing the stream is just fine.
For the record for myself in france, I can see gulli channels (a kid channel) but fail to record it and m kids are just complaining when I told them to go to sleep and that I will record it and it failed. Now I have more difficulties to send them to sleep ;-)
-- eric
On 14.11.2010 19:17, Eric Valette wrote:
On 14/11/2010 19:05, Udo Richter wrote:
Am 14.11.2010 18:21, schrieb Eric Valette:
I think I said clearly that the code looks correct and gave the pointer to the specs for unconvinced people. Those wanting to read the full specs http://neuron2.net/library/mpeg2/iso13818-2.pdf
Page 72, Table 6-12, picture_coding_type: 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
As listed in my first mail indeed.
The patch changes the behavior of VDR to accept picture_coding_type=0 and picture_coding_type=1 as I-Frame. picture_coding_type=0 is clearly specified as forbidden. Anything I've missed?
No. And *as Klaus* I dunno why this should be needed except if other parts of the logics for finding an I-frame is not robust enough for certain streams.
Of course it may be possible that VDR "looks" at the wrong byte in order to recognize the frame type. In that case, somebody should try to find the proper location and check that byte. Simply allowing undefined values to trigger the I-frame detection is a crude workaround, which is ok if it works for you, but doesn't qualify as an actual *fix*.
Klaus
On 14/11/2010 23:20, Klaus Schmidinger wrote:
On 14.11.2010 19:17, Eric Valette wrote:
On 14/11/2010 19:05, Udo Richter wrote:
Am 14.11.2010 18:21, schrieb Eric Valette:
I think I said clearly that the code looks correct and gave the pointer to the specs for unconvinced people. Those wanting to read the full specs http://neuron2.net/library/mpeg2/iso13818-2.pdf
Page 72, Table 6-12, picture_coding_type: 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
As listed in my first mail indeed.
The patch changes the behavior of VDR to accept picture_coding_type=0 and picture_coding_type=1 as I-Frame. picture_coding_type=0 is clearly specified as forbidden. Anything I've missed?
No. And *as Klaus* I dunno why this should be needed except if other parts of the logics for finding an I-frame is not robust enough for certain streams.
Of course it may be possible that VDR "looks" at the wrong byte in order to recognize the frame type. In that case, somebody should try to find the proper location and check that byte. Simply allowing undefined values to trigger the I-frame detection is a crude workaround, which is ok if it works for you, but doesn't qualify as an actual *fix*.
I never said it is a valid fix. But we just did get one more example of someone that gets 0 instead of the expected one. Are they all using the same buggy stream encoder?
-- eric
On 11/15/2010 08:35 AM, Eric Valette wrote:
I never said it is a valid fix. But we just did get one more example of someone that gets 0 instead of the expected one. Are they all using the same buggy stream encoder?
Probably yes! Once I had exactly the same problem, and I knew my broadcaster was using old Tandberg 8090 series H.264 encoders, then they changed headend encoders and the problem went away!
So for sure there are buggy encoders out there...
Francesco
Am 14.11.2010 19:17, schrieb Eric Valette:
On 14/11/2010 19:05, Udo Richter wrote:
The patch changes the behavior of VDR to accept picture_coding_type=0 and picture_coding_type=1 as I-Frame. picture_coding_type=0 is clearly specified as forbidden. Anything I've missed?
No. And *as Klaus* I dunno why this should be needed except if other parts of the logics for finding an I-frame is not robust enough for certain streams.
What really annoys me, is rather the duplication of identical bug reports for various DVB type (DVB-S2, DVB-T), various adapter in various countries when playing the stream is just fine.
So the next question is whether accepting picture_coding_type=0 as I-Frame is a proper fix. To be precise: Since VDR depends on knowledge of I-Frames, does picture_coding_type=0 guarantee that an I-Frame is starting? Does this hold for ALL TV streams ALL over the world, not just yours?
If any non-I-Frame starts with picture_coding_type=0, the editing function won't be able to show an editing mark on an wrongly detected I-Frame, recordings may start with an non-I-Frame although they're supposed not to, and stuff like that.
Cheers,
Udo
On 15/11/2010 19:46, Udo Richter wrote:
Am 14.11.2010 19:17, schrieb Eric Valette:
On 14/11/2010 19:05, Udo Richter wrote:
The patch changes the behavior of VDR to accept picture_coding_type=0 and picture_coding_type=1 as I-Frame. picture_coding_type=0 is clearly specified as forbidden. Anything I've missed?
No. And *as Klaus* I dunno why this should be needed except if other parts of the logics for finding an I-frame is not robust enough for certain streams.
What really annoys me, is rather the duplication of identical bug reports for various DVB type (DVB-S2, DVB-T), various adapter in various countries when playing the stream is just fine.
So the next question is whether accepting picture_coding_type=0 as I-Frame is a proper fix. To be precise: Since VDR depends on knowledge of I-Frames, does picture_coding_type=0 guarantee that an I-Frame is starting? Does this hold for ALL TV streams ALL over the world, not just yours?
As mentioned its not juts mine and that's exactly what worries me: there are too much reports from many countries and many channels. So unless they all use the same buggy mpeg2ts encoder, it's the sign something is wrong and I don't think a non valid value for picture type for things broadcasted all over the world is likely given the number of DVB recorder but maybe I'm wrong.
--eric
+1
There is a problem here, nobody says that it is VDR fault but saying simply that VDR adopt the full standard and nothing can be done is not enough .. we have a solution for now and implement patch every time we change the release.
This solution cannot be part of VDR core , why not , but my though is : if tomorrow private channels like SAT1 or Kabel1 change their streams, will you let all VDR machine fail to records
Broadcasters do what they want with their stream as long it works for TV and external receiver and absolutely don't care about software receiver .. very few of them take care of what they do, I remember this old story about ac3 stream id in BBC HD who was wrong .. after years they fix it, why doing that ? because it was not OK on hard receiver
At our level , and at mine, I do not understand all source code and dvb specification so as user I (we) try to do our best to help , uploading samples, testing and returning results or bug if any
We can help !!
Best regards
Selon Eric Valette eric.valette@free.fr:
On 15/11/2010 19:46, Udo Richter wrote:
Am 14.11.2010 19:17, schrieb Eric Valette:
On 14/11/2010 19:05, Udo Richter wrote:
The patch changes the behavior of VDR to accept picture_coding_type=0 and picture_coding_type=1 as I-Frame. picture_coding_type=0 is clearly specified as forbidden. Anything I've missed?
No. And *as Klaus* I dunno why this should be needed except if other parts of the logics for finding an I-frame is not robust enough for certain streams.
What really annoys me, is rather the duplication of identical bug reports for various DVB type (DVB-S2, DVB-T), various adapter in various countries when playing the stream is just fine.
So the next question is whether accepting picture_coding_type=0 as I-Frame is a proper fix. To be precise: Since VDR depends on knowledge of I-Frames, does picture_coding_type=0 guarantee that an I-Frame is starting? Does this hold for ALL TV streams ALL over the world, not just yours?
As mentioned its not juts mine and that's exactly what worries me: there are too much reports from many countries and many channels. So unless they all use the same buggy mpeg2ts encoder, it's the sign something is wrong and I don't think a non valid value for picture type for things broadcasted all over the world is likely given the number of DVB recorder but maybe I'm wrong.
--eric
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 11/16/10 09:42, dplu@free.fr wrote:
+1
There is a problem here, nobody says that it is VDR fault but saying simply that VDR adopt the full standard and nothing can be done is not enough .. we have a solution for now and implement patch every time we change the release.
This solution cannot be part of VDR core , why not , but my though is : if tomorrow private channels like SAT1 or Kabel1 change their streams, will you let all VDR machine fail to records
Broadcasters do what they want with their stream as long it works for TV and external receiver and absolutely don't care about software receiver .. very few of them take care of what they do, I remember this old story about ac3 stream id in BBC HD who was wrong .. after years they fix it, why doing that ? because it was not OK on hard receiver
At our level , and at mine, I do not understand all source code and dvb specification so as user I (we) try to do our best to help , uploading samples, testing and returning results or bug if any
I really don't understand all this turmoil about this!
Apparently you have a workaround that suits your needs. Just blindly allowing an undocumented and explicitly forbidden value to indentify an I-frame is not the right thing to do. You can either point me to a DVB spec that clearly defines this value as indicating an I-frame, or you can try to find out whether VDR makes a mistake when detecting the byte that contains the frame type information.
Klaus
Selon Eric Valette eric.valette@free.fr:
On 15/11/2010 19:46, Udo Richter wrote:
Am 14.11.2010 19:17, schrieb Eric Valette:
On 14/11/2010 19:05, Udo Richter wrote:
The patch changes the behavior of VDR to accept picture_coding_type=0 and picture_coding_type=1 as I-Frame. picture_coding_type=0 is clearly specified as forbidden. Anything I've missed?
No. And *as Klaus* I dunno why this should be needed except if other parts of the logics for finding an I-frame is not robust enough for certain streams.
What really annoys me, is rather the duplication of identical bug reports for various DVB type (DVB-S2, DVB-T), various adapter in various countries when playing the stream is just fine.
So the next question is whether accepting picture_coding_type=0 as I-Frame is a proper fix. To be precise: Since VDR depends on knowledge of I-Frames, does picture_coding_type=0 guarantee that an I-Frame is starting? Does this hold for ALL TV streams ALL over the world, not just yours?
As mentioned its not juts mine and that's exactly what worries me: there are too much reports from many countries and many channels. So unless they all use the same buggy mpeg2ts encoder, it's the sign something is wrong and I don't think a non valid value for picture type for things broadcasted all over the world is likely given the number of DVB recorder but maybe I'm wrong.
Klaus Schmidinger wrote:
On 11/16/10 09:42, dplu@free.fr wrote:
+1
There is a problem here, nobody says that it is VDR fault but saying simply that VDR adopt the full standard and nothing can be done is not enough .. we have a solution for now and implement patch every time we change the release.
This solution cannot be part of VDR core , why not , but my though is : if tomorrow private channels like SAT1 or Kabel1 change their streams, will you let all VDR machine fail to records
Broadcasters do what they want with their stream as long it works for TV and external receiver and absolutely don't care about software receiver .. very few of them take care of what they do, I remember this old story about ac3 stream id in BBC HD who was wrong .. after years they fix it, why doing that ? because it was not OK on hard receiver
At our level , and at mine, I do not understand all source code and dvb specification so as user I (we) try to do our best to help , uploading samples, testing and returning results or bug if any
I really don't understand all this turmoil about this!
Apparently you have a workaround that suits your needs. Just blindly allowing an undocumented and explicitly forbidden value to indentify an I-frame is not the right thing to do. You can either point me to a DVB spec that clearly defines this value as indicating an I-frame, or you can try to find out whether VDR makes a mistake when detecting the byte that contains the frame type information.
Klaus
Despite not being a VDR dev, I concur. However I suggest:
1) Samples with problematic MPEG-2 streams should be posted for further examination
2) If it is verified that non-standard flag values are used for I-frames, create a special configuration option for this that is off by default. This will enable users to easily workaround their problems while keeping the correct behavior by default.
And by the way, I'd like to reiterate that my problem is actually in MPEG-4, and not MPEG-2. Could please somebody take a look at that? :-) I can provide a .ts sample if needed or provide any other necessary assistance.
Best regards,
On 11/14/2010 05:45 PM, Eric Valette wrote:
On 14/11/2010 15:15, Udo Richter wrote:
In your case, as Klaus already wrote, it may have something to do with the fact that VDR wants to start the recording with an I-frame, and probably can't find one.
Some patches have been posted suggesting that replacing in remux.c
independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1;
which, as I read the bit definition is correct in doc
http://dvd.sourceforge.net/dvdinfo/mpeghdrs.html
For further info: Frame type = 000 forbidden Frame type = 001 intra-coded (I) - iframe Frame type = 010 predictive-coded (P) - p frame Frame type = 011 bidirectionally-predictive-coded (B) - b frame Frame type = 100 shall not be used(dc intra-coded (D) in ISO/IEC11172-2) Frame type = 101 reserved Frame type = 110 reserved Frame type = 111 reserved
by something equivalent to
independentFrame = ((Data[i + 2] >> 3) & 0x6 == 0
saying basically that what is not a P frame, a D frame or B frame sould be an I-frame. I haven't yet tested it myself although I have a channel that I can play but not record.
Klaus says that the above code is not correct according t specs but failed to explain how we could get other values than 1, 2, 3, 4
-- eric
Thanks Eric, finally I can record Kanal 10 DVB-T in Sweden. Like I said in my previous post about that channel, I don't think the problem is related to vdr but to some error in the stream. This proves that frame type is zero instead of one. /Magnus H
-
dplu＠free.fr -
Eric Valette -
Francesco Saverio Schiavarelli -
Klaus Schmidinger -
Luboš Doležel -
Magnus Hörlin -
Udo Richter