diff mbox

[ANNOUNCE] H.264 updates for VDR-1.5.9

Message ID 46D86C34.80506@gmx.de
State New
Headers

Commit Message

Reinhard Nissl Aug. 31, 2007, 7:29 p.m. UTC 
  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.

Comments

Petri Helin Aug. 31, 2007, 9:49 p.m. UTC | #1 
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
Reinhard Nissl Aug. 31, 2007, 10:18 p.m. UTC | #2 
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.
Petri Helin Sept. 1, 2007, 7:11 a.m. UTC | #3 
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
diff mbox

Patch

--- ../vdr-1.5.9-orig/ci.c	2007-04-30 15:02:49.000000000 +0200
+++ ci.c	2007-08-31 21:08:30.000000000 +0200
@@ -1880,7 +1880,7 @@  void cCamSlot::AddChannel(const cChannel
   source = Channel->Source();
   transponder = Channel->Transponder();
   if (Channel->Ca() >= CA_ENCRYPTED_MIN) {
-     AddPid(Channel->Sid(), Channel->Vpid(), STREAM_TYPE_VIDEO);
+     AddPid(Channel->Sid(), VPID_FROM_ANY(Channel->Vpid()), STREAM_TYPE_VIDEO);
      for (const int *Apid = Channel->Apids(); *Apid; Apid++)
          AddPid(Channel->Sid(), *Apid, STREAM_TYPE_AUDIO);
      for (const int *Dpid = Channel->Dpids(); *Dpid; Dpid++)
@@ -1901,7 +1901,7 @@  bool cCamSlot::CanDecrypt(const cChannel
   if (cas && cas->RepliesToQuery()) {
      cCiCaPmt CaPmt(CPCI_QUERY, Channel->Source(), Channel->Transponder(), Channel->Sid(), GetCaSystemIds());
      CaPmt.SetListManagement(CPLM_ADD); // WORKAROUND: CPLM_ONLY doesn't work with Alphacrypt 3.09 (deletes existing CA_PMTs)
-     CaPmt.AddPid(Channel->Vpid(), STREAM_TYPE_VIDEO);
+     CaPmt.AddPid(VPID_FROM_ANY(Channel->Vpid()), STREAM_TYPE_VIDEO);
      for (const int *Apid = Channel->Apids(); *Apid; Apid++)
          CaPmt.AddPid(*Apid, STREAM_TYPE_AUDIO);
      for (const int *Dpid = Channel->Dpids(); *Dpid; Dpid++)
--- ../vdr-1.5.9-orig/dvbdevice.c	2007-08-17 15:37:56.000000000 +0200
+++ dvbdevice.c	2007-08-31 21:20:22.000000000 +0200
@@ -758,7 +806,7 @@  bool cDvbDevice::ProvidesChannel(const c
      result = hasPriority;
      if (Priority >= 0 && Receiving(true)) {
         if (dvbTuner->IsTunedTo(Channel)) {
-           if (Channel->Vpid() && !HasPid(Channel->Vpid()) || Channel->Apid(0) && !HasPid(Channel->Apid(0))) {
+           if (Channel->Vpid() && !HasPid(VPID_FROM_ANY(Channel->Vpid())) || Channel->Apid(0) && !HasPid(Channel->Apid(0))) {
 #ifdef DO_MULTIPLE_RECORDINGS
               if (CamSlot() && Channel->Ca() >= CA_ENCRYPTED_MIN) {
                  if (CamSlot()->CanDecrypt(Channel))
@@ -794,7 +842,7 @@  bool cDvbDevice::IsTunedToTransponder(co
 bool cDvbDevice::SetChannelDevice(const cChannel *Channel, bool LiveView)
 {
   int apid = Channel->Apid(0);
-  int vpid = Channel->Vpid();
+  int vpid = VPID_FROM_ANY(Channel->Vpid());
   int dpid = Channel->Dpid(0);
 
   bool DoTune = !dvbTuner->IsTunedTo(Channel);
@@ -855,7 +903,7 @@  bool cDvbDevice::SetChannelDevice(const 
      CHECK(ioctl(fd_audio, AUDIO_SET_AV_SYNC, true));
      }
   else if (StartTransferMode)
-     cControl::Launch(new cTransferControl(this, Channel->GetChannelID(), vpid, Channel->Apids(), Channel->Dpids(), Channel->Spids()));
+     cControl::Launch(new cTransferControl(this, Channel->GetChannelID(), Channel->Vpid(), Channel->Apids(), Channel->Dpids(), Channel->Spids()));
 
   return true;
 }