Hi,
the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer. The changes to earlier releases are:
- H264::cParser has been enhanced to provide information for H264::cContext::GetFramesPerSec() and therefore outsourced into separate files. - cVideoRepacker generates Access Unit Delimiters in case they are not part of the stream.
These changes should make VDR ready for the upcoming IFA fair in regard to the broadcasts on the temporary channel EinsFestival HD.
The other attached patch vdr-1.5.9-framespersec.patch tries to replace the macro FRAMESPERSEC by a function call GetFramesPerSec() which analyses a recordings first video frame to determine frames per second which are used to calculated a recordings length. The changes to earlier releases are:
- add support for H.264 recordings by making use of the above mentioned H264::cParser, as frame timing stuff is quite complex. H.264 support can be turned off by putting a comment around the macro ADD_H264_SUPPORT in tools.c.
This change provides correct recording length reports for recordings taken on EinsFestival HD as this channel broadcasts 50p, i. e. without the patch, VDR will report recording times which are twice the actual time.
The patch in general may especially be useful for people with PAL and NTSC recordings, as in this scenario it was never possible to find a single setting for FRAMESPERSEC. Although FRAMESPERSEC has been replaced on many locations, it is still used to read/write cutting marks file, to stay compatible.
Have fun while expecting the next vdr-xine-release ;-)
Bye.
Reinhard Nissl wrote:
Hi,
the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer. The changes to earlier releases are:
- H264::cParser has been enhanced to provide information for H264::cContext::GetFramesPerSec() and therefore outsourced into separate files.
- cVideoRepacker generates Access Unit Delimiters in case they are not part of the stream.
Should this patch make it possible to record H.264 encoded stream? I have applied the patch and can see in the channels menu that Canal+ HD Film uses H.264 codec, but I can not record the channel (nor watch it...).
-Petri
Hi,
Petri Helin wrote:
the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer. The changes to earlier releases are:
- H264::cParser has been enhanced to provide information for H264::cContext::GetFramesPerSec() and therefore outsourced into separate files.
- cVideoRepacker generates Access Unit Delimiters in case they are not part of the stream.
Should this patch make it possible to record H.264 encoded stream? I
It should. It works for the German DVB-S2 HD channels on Astra and it worked for LuxeTV HD on Hotbird in the past.
have applied the patch and can see in the channels menu that Canal+ HD Film uses H.264 codec, but I can not record the channel (nor watch it...).
Is this the channel you've mentioned (I've applied a DVB-S2 patch, so the entry may differ from your's a little)?
CANAL+ FILM HD;Harmonic:11470:vC56M2S0Z0:S13.0E:27500:10331+331:332=pol;333=ORY:551:100:15423:318:1400:0
On my system, VDR says this channel is encrypted. Do you have the necessary means to receive this channel?
Bye.
Reinhard Nissl wrote:
Hi,
Petri Helin wrote:
the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer. The changes to earlier releases are:
- H264::cParser has been enhanced to provide information for H264::cContext::GetFramesPerSec() and therefore outsourced into separate files.
- cVideoRepacker generates Access Unit Delimiters in case they are not part of the stream.
Should this patch make it possible to record H.264 encoded stream? I
It should. It works for the German DVB-S2 HD channels on Astra and it worked for LuxeTV HD on Hotbird in the past.
have applied the patch and can see in the channels menu that Canal+ HD Film uses H.264 codec, but I can not record the channel (nor watch it...).
Is this the channel you've mentioned (I've applied a DVB-S2 patch, so the entry may differ from your's a little)?
CANAL+ FILM HD;Harmonic:11470:vC56M2S0Z0:S13.0E:27500:10331+331:332=pol;333=ORY:551:100:15423:318:1400:0
On my system, VDR says this channel is encrypted. Do you have the necessary means to receive this channel?
The channel I mean is the same, I think, but provided by my local cable operator. Here is the entry in channels.conf: Canal+ Film HD;Telenor:330000:C0M256:C:6900:10512+512:640=eng;641=eng:0:B00:3306:0:22:0
I have a valid subscription and this particular channel dis work when I tested it with the ts-recording and h264-patches available here: http://phivdr.dyndns.org/vdr
My subscription is ending in 24 hours, so I'd like to know if I can record the channel before making my mind whether to continue the subscription ;)
-Petri
Hi,
Petri Helin wrote:
The channel I mean is the same, I think, but provided by my local cable operator. Here is the entry in channels.conf: Canal+ Film HD;Telenor:330000:C0M256:C:6900:10512+512:640=eng;641=eng:0:B00:3306:0:22:0
I have a valid subscription and this particular channel dis work when I tested it with the ts-recording and h264-patches available here: http://phivdr.dyndns.org/vdr
Can you provide me with a few MB of TS stream from that channel?
Something like czap and cat /dev/dvb/adapterX/dvr0 > sample.ts should do the trick.
My subscription is ending in 24 hours, so I'd like to know if I can record the channel before making my mind whether to continue the subscription ;)
Then you have to hurry now, I won't have much time tomorrow evening.
Bye.
Hi,
Reinhard Nissl wrote:
Can you provide me with a few MB of TS stream from that channel?
Something like czap and cat /dev/dvb/adapterX/dvr0 > sample.ts should do the trick.
The TS sample you've sent me looks ok, i. e. it can be parsed by H264::cParser.
Please locate the following location in cVideoRepacker::Repack() in file remux.c:
// remember start of the data const uchar *payload = data; const uchar *NalPayload = payload;
while (todo > 0) {
and add the following line before the while:
if (h264parser) { static FILE *f = fopen("/video/sample.es.h264", "wb"); fwrite(data, 1, todo, f); fflush(f); }
The line will write the PES packet's content into file /video/sample.es.h264 when a h264parser exists. Then please send me some MB of the file.
Bye.
Hi,
Reinhard Nissl wrote:
The line will write the PES packet's content into file /video/sample.es.h264 when a h264parser exists. Then please send me some MB of the file.
The file you've sent me doesn't contain any useful data. You can have a look at it yourself:
od -Ax -t x1 -v sample2.es.h264 | less -S
You need to find at least the sequence 00 00 01. Otherwise it's garbage.
I'll go to bed soon, so here's a quick description how to go on:
- add this function to cRepacker virtual void LogTS(const uint8_t *Buf) {} - add this function to cVideoRepacker virtual void LogTS(const uint8_t *Buf) { if (h264parser) { static FILE *f = fopen("/video/sample.ts", "wb"); fwrite(Buf, 1, 188, f); fflush(f); } } - change this area in ts_to_pes() like that:
void cTS2PES::ts_to_pes(const uint8_t *Buf) // don't need count (=188) { if (!Buf) return; if (repacker) repacker->LogTS(Buf); if (Buf[1] & TS_ERROR)
Be careful to just have a single cVideoRepacker instance write into this file, i. e. either activate transfer mode on this channel or make a recording on this channel but not both at the same time.
Have a look at this file with
od -Ax -t x1 -v -w188 sample.ts | less -S
and locate the sequence 00 00 01 multiple times. It should then be possible to record this channel although it doesn't work for now, as cVideoRepacker didn't find any startcode (00 00 01) in the sample.es.h264 from above.
Bye.
Reinhard Nissl wrote:
Hi,
Reinhard Nissl wrote:
The line will write the PES packet's content into file /video/sample.es.h264 when a h264parser exists. Then please send me some MB of the file.
The file you've sent me doesn't contain any useful data. You can have a look at it yourself:
od -Ax -t x1 -v sample2.es.h264 | less -S
You need to find at least the sequence 00 00 01. Otherwise it's garbage.
I'll go to bed soon, so here's a quick description how to go on:
- add this function to cRepacker virtual void LogTS(const uint8_t *Buf) {}
- add this function to cVideoRepacker virtual void LogTS(const uint8_t *Buf) { if (h264parser) { static FILE
*f = fopen("/video/sample.ts", "wb"); fwrite(Buf, 1, 188, f); fflush(f); } }
- change this area in ts_to_pes() like that:
void cTS2PES::ts_to_pes(const uint8_t *Buf) // don't need count (=188) { if (!Buf) return; if (repacker) repacker->LogTS(Buf); if (Buf[1] & TS_ERROR)
Be careful to just have a single cVideoRepacker instance write into this file, i. e. either activate transfer mode on this channel or make a recording on this channel but not both at the same time.
Have a look at this file with
od -Ax -t x1 -v -w188 sample.ts | less -S
and locate the sequence 00 00 01 multiple times. It should then be possible to record this channel although it doesn't work for now, as cVideoRepacker didn't find any startcode (00 00 01) in the sample.es.h264 from above.
Bye.
I have made the changes and did some testing, but there are no "00 00 01" series in the data at all. Some strange patterns I can see, but mostly just garbage. I will try again this evening when I can be sure that there is a program running.
Fortunately I remembered wrong the end date of my subscription, it is valid until the end of this month, so I have 24 hours more to test this...
-Petri
Reinhard Nissl wrote:
Hi,
Reinhard Nissl wrote:
The line will write the PES packet's content into file /video/sample.es.h264 when a h264parser exists. Then please send me some MB of the file.
The file you've sent me doesn't contain any useful data. You can have a look at it yourself:
od -Ax -t x1 -v sample2.es.h264 | less -S
You need to find at least the sequence 00 00 01. Otherwise it's garbage.
I'll go to bed soon, so here's a quick description how to go on:
- add this function to cRepacker virtual void LogTS(const uint8_t *Buf) {}
- add this function to cVideoRepacker virtual void LogTS(const uint8_t *Buf) { if (h264parser) { static FILE
*f = fopen("/video/sample.ts", "wb"); fwrite(Buf, 1, 188, f); fflush(f); } }
- change this area in ts_to_pes() like that:
void cTS2PES::ts_to_pes(const uint8_t *Buf) // don't need count (=188) { if (!Buf) return; if (repacker) repacker->LogTS(Buf); if (Buf[1] & TS_ERROR)
Be careful to just have a single cVideoRepacker instance write into this file, i. e. either activate transfer mode on this channel or make a recording on this channel but not both at the same time.
Have a look at this file with
od -Ax -t x1 -v -w188 sample.ts | less -S
and locate the sequence 00 00 01 multiple times. It should then be possible to record this channel although it doesn't work for now, as cVideoRepacker didn't find any startcode (00 00 01) in the sample.es.h264 from above.
Bye.
I have now tested when there is a program running (I am even seeing the dvb-subtitles with xineliboutput), but still there are no "00 00 01" series in the sample.ts. Anything more I could test with?
-Petri
On Thu, Aug 30, 2007 at 08:44:27PM +0300, Petri Helin wrote:
I have now tested when there is a program running (I am even seeing the dvb-subtitles with xineliboutput), but still there are no "00 00 01" series in the sample.ts. Anything more I could test with?
I lost the stream also today. The subtitles were visible, but no sound. vlc of course did not got anything to show.
After a several (10 - 15) try I did manage to tune to CD channel and got sound also using xineliboutput. After getting the sound I did try vlc and got stream also.
There is some problems on tuning or encrypting hd channels. Because I do have only budget cards without cams, my canal+ card is on my dbox2 and I'm using xx plugin to access the card.
...hanu
Hi,
Petri Helin wrote:
I have now tested when there is a program running (I am even seeing the dvb-subtitles with xineliboutput), but still there are no "00 00 01" series in the sample.ts. Anything more I could test with?
I'm sorry, I can't help you any further. Try to get a correctly decrypted TS first, then it should work out of the box.
When you have a look at the first sample.ts you've sent me with this command
od -Ax -t x1 -v -w188 sample.ts | less -S
then you can find the sequence 00 00 01 09 which is a H.264 access unit delimiter. So it once must have worked to get a properly decrypted TS.
Bye.
Reinhard Nissl wrote:
Hi,
Petri Helin wrote:
I have now tested when there is a program running (I am even seeing the dvb-subtitles with xineliboutput), but still there are no "00 00 01" series in the sample.ts. Anything more I could test with?
I'm sorry, I can't help you any further. Try to get a correctly decrypted TS first, then it should work out of the box.
When you have a look at the first sample.ts you've sent me with this command
od -Ax -t x1 -v -w188 sample.ts | less -S
then you can find the sequence 00 00 01 09 which is a H.264 access unit delimiter. So it once must have worked to get a properly decrypted TS.
Bye.
When I tried again with streamdev-plugin sending TS-stream to a vlc client and letting it dump the TS-stream, I can find the "00 00 01 09" delimiter in the dumped stream. So if it works with the combination above, what could be missing from VDR itself that prevents it from doing the same?
-Petri
On Fri, Aug 31, 2007 at 12:05:12AM +0300, Petri Helin wrote:
When I tried again with streamdev-plugin sending TS-stream to a vlc client and letting it dump the TS-stream, I can find the "00 00 01 09" delimiter in the dumped stream. So if it works with the combination above, what could be missing from VDR itself that prevents it from doing the same?
Maybe there is something to do with the Welho's way of broadcasting the Canal+ HD dvb-s2 stream again in dvb-c?
I do have a subscription also on Thor 1W, so I'll try to do some tests using dvb-s2 during the weekend.
(The dish splitter is on another room, so there can be some waf negotiations during the weekend ;))
..hanu
Hi,
Hannu Tirkkonen wrote:
When I tried again with streamdev-plugin sending TS-stream to a vlc client and letting it dump the TS-stream, I can find the "00 00 01 09" delimiter in the dumped stream. So if it works with the combination above, what could be missing from VDR itself that prevents it from doing the same?
Maybe there is something to do with the Welho's way of broadcasting the Canal+ HD dvb-s2 stream again in dvb-c?
I do have a subscription also on Thor 1W, so I'll try to do some tests using dvb-s2 during the weekend.
Please keep in mind, that my patch doesn't add DVB-S2 support.
Bye.
Reinhard Nissl wrote:
Hi,
Reinhard Nissl wrote:
Have a look at this file with
od -Ax -t x1 -v -w188 sample.ts | less -S
and locate the sequence 00 00 01 multiple times. It should then be possible to record this channel although it doesn't work for now, as cVideoRepacker didn't find any startcode (00 00 01) in the sample.es.h264 from above.
Bye.
I tried again by using streamdev-plugin to send TS-stream to a vlc client, which I set to dump the TS-stream. In the dumped stream I can find the "00 00 01" start codes.
-Petri
On Wed, Aug 29, 2007 at 11:38:39PM +0300, Petri Helin wrote:
Reinhard Nissl wrote:
Hi,
the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer. The changes to earlier releases are:
- H264::cParser has been enhanced to provide information for H264::cContext::GetFramesPerSec() and therefore outsourced into separate files.
- cVideoRepacker generates Access Unit Delimiters in case they are not part of the stream.
Should this patch make it possible to record H.264 encoded stream? I have applied the patch and can see in the channels menu that Canal+ HD Film uses H.264 codec, but I can not record the channel (nor watch it...).
-Petri
I did apply this h264 patch and streamdev patch from: http://www.vdr-developer.org/mantisbt/view.php?id=382
Now the load of the server is low when tuned to Canal+ HD and I can watch the stream using vlc. The recording at least outputs something to hard disk ;)
...hanu
On Thu, Aug 30, 2007 at 12:05:08AM +0300, Hannu Tirkkonen wrote:
I did apply this h264 patch and streamdev patch from: http://www.vdr-developer.org/mantisbt/view.php?id=382
Now the load of the server is low when tuned to Canal+ HD and I can watch the stream using vlc. The recording at least outputs something to hard disk ;)
Well... the video part of the recordings seems to be corrupted. vlc cannot show any video; there's only audio.
projectx says (hundreds of lines on 34MB recording): !> error in pes_extension of pes-ID 0xBD @ pos: 112153 (1554 / 14 / 15 / true / false) -> found PES-ID 0xBD (private stream 1) @ 112153 !> error in pes_extension of pes-ID 0xE0 @ pos: 134640 (2048 / 14 / 15 / true / false) !> error in pes_extension of pes-ID 0xE0 @ pos: 188715 (2048 / 14 / 15 / true / false) !> error in pes_extension of pes-ID 0xE0 @ pos: 247087 (2048 / 19 / 20 / true / false) .... -> more than 500 warnings/errors, stop logging.. -> dropping video data, GOP larger than 6MB -> dropping video data, GOP larger than 6MB
od does find 00 00 01 09 sequences from the file.
The live stream can be watched with vlc, and saving the stream with vlc creates a file that can be watched again with mplayer or vlc.
There is 34MB of the recording on http://hotel.hanu.com/~hanu/h264
...hanu
El Jueves, 30 de Agosto de 2007, Hannu Tirkkonen escribió:
On Thu, Aug 30, 2007 at 12:05:08AM +0300, Hannu Tirkkonen wrote:
I did apply this h264 patch and streamdev patch from: http://www.vdr-developer.org/mantisbt/view.php?id=382
Now the load of the server is low when tuned to Canal+ HD and I can watch the stream using vlc. The recording at least outputs something to hard disk ;)
Well... the video part of the recordings seems to be corrupted. vlc cannot show any video; there's only audio.
projectx says (hundreds of lines on 34MB recording): !> error in pes_extension of pes-ID 0xBD @ pos: 112153 (1554 / 14 / 15 / true / false) -> found PES-ID 0xBD (private stream 1) @ 112153 !> error in pes_extension of pes-ID 0xE0 @ pos: 134640 (2048 / 14 / 15 / true / false) !> error in pes_extension of pes-ID 0xE0 @ pos: 188715 (2048 / 14 / 15 / true / false) !> error in pes_extension of pes-ID 0xE0 @ pos: 247087 (2048 / 19 / 20 / true / false) ....
I have this errors also with the ttxtsubs .They are not important in mpeg-2 streams. Perhaps ttxtsubs corupts the mpeg-4 stream.
Jose Alberto
-> more than 500 warnings/errors, stop logging.. -> dropping video data, GOP larger than 6MB -> dropping video data, GOP larger than 6MB
od does find 00 00 01 09 sequences from the file.
The live stream can be watched with vlc, and saving the stream with vlc creates a file that can be watched again with mplayer or vlc.
There is 34MB of the recording on http://hotel.hanu.com/~hanu/h264
...hanu
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Hannu Tirkkonen wrote:
Well... the video part of the recordings seems to be corrupted. vlc cannot show any video; there's only audio.
projectx says (hundreds of lines on 34MB recording): !> error in pes_extension of pes-ID 0xBD @ pos: 112153 (1554 / 14 / 15 / true / false) -> found PES-ID 0xBD (private stream 1) @ 112153 !> error in pes_extension of pes-ID 0xE0 @ pos: 134640 (2048 / 14 / 15 / true / false) !> error in pes_extension of pes-ID 0xE0 @ pos: 188715 (2048 / 14 / 15 / true / false) !> error in pes_extension of pes-ID 0xE0 @ pos: 247087 (2048 / 19 / 20 / true / false) .... -> more than 500 warnings/errors, stop logging.. -> dropping video data, GOP larger than 6MB -> dropping video data, GOP larger than 6MB
ProjectX doesn't understand H.264. It assumes MPEG2 and therefore sees an overfull GOP.
od does find 00 00 01 09 sequences from the file.
The live stream can be watched with vlc, and saving the stream with vlc creates a file that can be watched again with mplayer or vlc.
There is 34MB of the recording on http://hotel.hanu.com/~hanu/h264
Plays perfectly here with vdr-xine-0.7.11 and xine-lib-cvs from my homepage + vdr-xine's xine-lib.patch. If I play it in slow motion, my PC is fast enough to decode and display all frames.
Bye.
Reinhard Nissl wrote: the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
Hi, I trying to compile vdr-1.5.9 with h264 patches but vdr-xine-0.7.10 plugin give me error:
xineDevice.c: In member function 'int PluginXine::cXineDevice::PlayCommon3(const uchar*, int, int64_t)': xineDevice.c:1387: error: cannot call member function 'int cRemux::ScanVideoPacket(const uchar*, int, int, uchar&)' without object xineDevice.c: In function 'bool PluginXine::getPTS(const uchar*, int, int64_t&, bool, bool, double&, double&, double&, double&, double*)': xineDevice.c:2017: error: cannot call member function 'int cRemux::ScanVideoPacket(const uchar*, int, int, uchar&)' without object make[1]: *** [xineDevice.o] Error 1
Is there any solution? Please help me.
Regards, AK
Hi,
Arthur Konovalov wrote:
I trying to compile vdr-1.5.9 with h264 patches but vdr-xine-0.7.10 plugin give me error:
xineDevice.c: In member function 'int PluginXine::cXineDevice::PlayCommon3(const uchar*, int, int64_t)': xineDevice.c:1387: error: cannot call member function 'int cRemux::ScanVideoPacket(const uchar*, int, int, uchar&)' without object xineDevice.c: In function 'bool PluginXine::getPTS(const uchar*, int, int64_t&, bool, bool, double&, double&, double&, double&, double*)': xineDevice.c:2017: error: cannot call member function 'int cRemux::ScanVideoPacket(const uchar*, int, int, uchar&)' without object make[1]: *** [xineDevice.o] Error 1
Is there any solution?
Use vdr-xine-0.7.11 please.
Bye.
On 8/29/07, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
These changes should make VDR ready for the upcoming IFA fair in regard to the broadcasts on the temporary channel EinsFestival HD.
Referring to the problems I've had with this patch, I'd like to know if the reason was that the channel I'm trying to watch/record is encrypted. Have you had chance to test this with an encrypted channel? Or is that out of the question and the reason is something else?
-Petri
Hi,
Petri Helin wrote:
the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
These changes should make VDR ready for the upcoming IFA fair in regard to the broadcasts on the temporary channel EinsFestival HD.
Referring to the problems I've had with this patch, I'd like to know if the reason was that the channel I'm trying to watch/record is encrypted. Have you had chance to test this with an encrypted channel?
No, I didn't have a chance to test this.
Or is that out of the question and the reason is something else?
One part of my patch adds some functionality to cVideoRepacker and therefore has no influence on the TS level.
But another part modifies VPID to transport the information that this channel uses H.264. This is done by adding 10000 to the normal VPID which is in the range 0..8191. The decimal offset 10000 was chosen over the hex offset 0x10000 as the real VPID should still be recognizable in channels.conf without using a calculator.
The drawback is, that the decimal offset isn't simply clipped away by assigning the patched VPID for example to a variable of type short or when masking it with 0x1fff. Therefore it is necessary to add some special clipping code at each location where the patched VPID is entered into some data structure which is then given to DVB API functions.
So, there is the chance that this clipping is missing at a location where the VPID is scheduled for decrypting. This could be the reason why the video TS packets do not get decrypted.
But I don't understand why streamdev still delivers a decrypted video stream in that case. Can it be that the client asks streamdev to filter certain TS packets and therefore uses the correct VPID?
Bye.
Reinhard Nissl wrote:
But I don't understand why streamdev still delivers a decrypted video stream in that case. Can it be that the client asks streamdev to filter certain TS packets and therefore uses the correct VPID?
Yes. In http streaming mode streamdev parses PIDs directly from PMT and does not use VDR channel data. But the VDR<->VDR streaming mode probably does not work if PIDs are not "real" ones.
- Petri
Hi,
Petri Hintukainen wrote:
But I don't understand why streamdev still delivers a decrypted video stream in that case. Can it be that the client asks streamdev to filter certain TS packets and therefore uses the correct VPID?
Yes. In http streaming mode streamdev parses PIDs directly from PMT and does not use VDR channel data. But the VDR<->VDR streaming mode probably does not work if PIDs are not "real" ones.
Please try the attached patch which adds VPID clipping to some locations.
Bye.
Hi,
Reinhard Nissl wrote:
But I don't understand why streamdev still delivers a decrypted video stream in that case. Can it be that the client asks streamdev to filter certain TS packets and therefore uses the correct VPID?
Yes. In http streaming mode streamdev parses PIDs directly from PMT and does not use VDR channel data. But the VDR<->VDR streaming mode probably does not work if PIDs are not "real" ones.
Please try the attached patch which adds VPID clipping to some locations.
Please try this one. I better should have checked the previous one before posting -- it contained changes for DVB-S2 support.
Bye.
Reinhard Nissl wrote:
Hi,
Reinhard Nissl wrote:
But I don't understand why streamdev still delivers a decrypted video stream in that case. Can it be that the client asks streamdev to filter certain TS packets and therefore uses the correct VPID?
Yes. In http streaming mode streamdev parses PIDs directly from PMT and does not use VDR channel data. But the VDR<->VDR streaming mode probably does not work if PIDs are not "real" ones.
Please try the attached patch which adds VPID clipping to some locations.
Please try this one. I better should have checked the previous one before posting -- it contained changes for DVB-S2 support.
I can gladly tell you that now there are several "00 00 01" blocks in the sample.ts file. So something has changed to better. But for some reason I am unable to play the sample.ts file. This is what mplayer tells me when I try to replay:
# mplayer -demuxer 35 -vo xv -ao alsa -identify /video/sample.ts MPlayer dev-SVN-r23893-4.1.2 (C) 2000-2007 MPlayer Team CPU: Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz (Family: 6, Model: 15, Stepping: 6) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2 113 audio & 236 video codecs
Playing /video/sample.ts. libavformat file format detected. ID_VIDEO_ID=0 [lavf] Video stream found, -vid 0 VIDEO: [mpg1] 0x0 0bpp 90000.000 fps 0.0 kbps ( 0.0 kbyte/s) ID_FILENAME=/video/sample.ts ID_DEMUXER=lavf ID_VIDEO_FORMAT=mpg1 ID_VIDEO_BITRATE=0 ID_VIDEO_WIDTH=0 ID_VIDEO_HEIGHT=0 ID_VIDEO_FPS=90000.000 ID_VIDEO_ASPECT=nan ID_LENGTH=30.64 ========================================================================== Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.4.0b Selected video codec: [mpeg12] vfm: libmpeg2 (MPEG-1 or 2 (libmpeg2)) ========================================================================== ID_VIDEO_CODEC=mpeg12 Audio: no sound Starting playback... V: 0.0 1/ 1 ??% ??% ??,?% 0 0
Exiting... (End of file)
I am now also able to record h.264 encoded programs, just like mpeg2 encoded, and as a result xxx.vdr files are created. But still, i cannot replay them either.
-Petri
Hi,
Petri Helin wrote:
Please try the attached patch which adds VPID clipping to some locations.
I can gladly tell you that now there are several "00 00 01" blocks in the sample.ts file. So something has changed to better. But for some reason I am unable to play the sample.ts file. This is what mplayer tells me when I try to replay:
I can play the sample TS file you've sent me with
mplayer -vc ffh264 sample.ts
mplayer incorrectly chose mpeg12 in your case, as it doesn't expect H.264 in the TS's PES packets.
I am now also able to record h.264 encoded programs, just like mpeg2 encoded, and as a result xxx.vdr files are created. But still, i cannot replay them either.
Stock xine-lib-1.1.7 or higher can play those files. You may also want to use vdr-xine-0.7.11 with a patched xine-lib-1.1.8 or stock xine-lib-1.2.
mplayer doesn't expect H.264 in PES files and therefore looks for a MPEG1/2 sequence header.
BTW: Thank you very much for pointing me into the right direction regarding this issue!
NOTE: be aware that FFmpeg doesn't support interlaced streams properly at the moment. It typically crashes after a few frames. In my xine-lib.patch for xine-lib-1.1.8 I've therefore disabled decoding of interlaced frames (more or less properly).
Bye.
Reinhard Nissl wrote:
Hi,
Petri Helin wrote:
Please try the attached patch which adds VPID clipping to some locations.
I can gladly tell you that now there are several "00 00 01" blocks in the sample.ts file. So something has changed to better. But for some reason I am unable to play the sample.ts file. This is what mplayer tells me when I try to replay:
I can play the sample TS file you've sent me with
mplayer -vc ffh264 sample.ts
mplayer incorrectly chose mpeg12 in your case, as it doesn't expect H.264 in the TS's PES packets.
Whatever I try, I am not able to play the TS capture. But that's not a big deal.
I am now also able to record h.264 encoded programs, just like mpeg2 encoded, and as a result xxx.vdr files are created. But still, i cannot replay them either.
Stock xine-lib-1.1.7 or higher can play those files. You may also want to use vdr-xine-0.7.11 with a patched xine-lib-1.1.8 or stock xine-lib-1.2.
Yes, I have now tried with the current xine-lib (1.1-branch) from mercury and I can actually play the 001.vdr file. Nice! Yesterday I just hastily tested with mplayer.
BTW: Thank you very much for pointing me into the right direction regarding this issue!
You are very welcome, since your h.264 support for VDR is greatly appriciated :)
NOTE: be aware that FFmpeg doesn't support interlaced streams properly at the moment. It typically crashes after a few frames. In my xine-lib.patch for xine-lib-1.1.8 I've therefore disabled decoding of interlaced frames (more or less properly).
Bye.
Xine does not crash, but the playback is really slow and there are "ghost effects" in the picture. Xine puts out this kind of messages all the time:
[h264 @ 0xb61168f4]concealing 6960 DC, 6960 AC, 6960 MV errors video_out: throwing away image with pts 455968 because it's too old (diff : 574). video_out: throwing away image with pts 448768 because it's too old (diff : 7774). video_out: throwing away image with pts 452368 because it's too old (diff : 4174). ffmpeg_video_dec: error decompressing frame ffmpeg_video_dec: error decompressing frame
I have an Intel Core 2 Duo E6300 (1,83GHz) which might not be enough. Do you have the xine-lib.patch for disabling interlaced frames available for download somewhere?
-Petri
Hi,
Petri Helin wrote:
I am now also able to record h.264 encoded programs, just like mpeg2 encoded, and as a result xxx.vdr files are created. But still, i cannot replay them either.
Stock xine-lib-1.1.7 or higher can play those files. You may also want to use vdr-xine-0.7.11 with a patched xine-lib-1.1.8 or stock xine-lib-1.2.
Yes, I have now tried with the current xine-lib (1.1-branch) from mercury and I can actually play the 001.vdr file. Nice! Yesterday I just hastily tested with mplayer.
Sure, it's odd that mplayer cannot play such 001.vdr files at the moment. I already had a look into mplayer's source and discovered why mplayer chose the wrong codec, but I'm still waiting for someone else to fix this issue. Digging around in the hardly known code of FFmpeg and now also mplayer plus creating patches eats a lot of time.
NOTE: be aware that FFmpeg doesn't support interlaced streams properly at the moment. It typically crashes after a few frames. In my xine-lib.patch for xine-lib-1.1.8 I've therefore disabled decoding of interlaced frames (more or less properly).
Xine does not crash, but the playback is really slow and there are "ghost effects" in the picture. Xine puts out this kind of messages all the time:
[h264 @ 0xb61168f4]concealing 6960 DC, 6960 AC, 6960 MV errors video_out: throwing away image with pts 455968 because it's too old (diff : 574). video_out: throwing away image with pts 448768 because it's too old (diff : 7774). video_out: throwing away image with pts 452368 because it's too old (diff : 4174). ffmpeg_video_dec: error decompressing frame ffmpeg_video_dec: error decompressing frame
I get similar messages here. Try to play the stream in slow motion and they should go away.
I have an Intel Core 2 Duo E6300 (1,83GHz) which might not be enough. Do you have the xine-lib.patch for disabling interlaced frames available for download somewhere?
The attached patch is also part of the larger xine-lib.patch included in vdr-xine-0.7.11.tgz.
Bye.
Hi,
Reinhard Nissl wrote:
the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
After the above patch, my "sync early" patch fails to apply. Attached you'll find an updated version which should apply cleanly.
Bye.
-
Arthur Konovalov -
Hannu Tirkkonen -
Jose Alberto Reguero -
Petri Helin -
Petri Hintukainen -
Reinhard Nissl