Strange problem with RSTP steaming with DVBViewer as client

[bccrew]

Hello,

 

Since a few days I have a strange problem. I have a server with DVBViewer RS running 3 sundtek dvb-c tuners. All my channels are working except 1, Animal Planet HD.

 

 

Streaming to VLC from the webinterface works, streaming to Ipad2 with the Framework for Rec. Service App works also.

 

Only streaming to different DVBViewer Clients doesn't work. Other channels on the same frequency still work. Data is coming on the PID (I checked with Transedit duh.. otherwise streaming would not work at all.. )

 

I just see a black screen and the dvbsubs running, no audio or video.

 

 

I tried changing the codecs but no avail..

 

No data is arriving in the DVBSource filter..

 

 

[Derrick]

FTA or scrambled?

 

pls. post support.zips (server and client)

[bccrew]

Hello Derrick,

 

FTA this time Attached please find my support files. Strange thing is that streaming to VLC and ipad always works but suddenly stopped working to 2 DVBViewer Clients in my home.

 

It can't be a codec problem imho. I have not updated anything on the 2 computers. The only thing I added lately is the IoS 8.1 folder for the framework.

 

 

I tried changing from UDP streaming to TCP streaming but in fact this should not matter because all other channels on same mux work perfectly.

 

DVB subs keep displaying btw.. but no audio or video

 

 

I checked with Task Manager on the Windows 8.1 client PC and when I tune to the channel, there is still 8.1Mpbs stream arriving on the client but no picture.

 

 

I just can't understand why only this channel...

supportClient.zip

supportServer.zip

Edited March 28, 2015 by bccrew

[Derrick]

are the channel parameters for Animal Planet HD identical at the client and the server?

[bccrew]

Ofcourse I already checked this...

 

The PID's in VLC are the same ones as in the Channel Editor of every DVBViewer Client. I have DVBViewer installed on my HTPC, my laptop and the server itself. Only this channel is not working anymore. I'm going crazy because I cannot seem to find why For some reason the DVBSource filter doesn't see any incoming data in the PID's.

 

At first I thought it should be a client problem because data is still sent to every client (subs, TT,...) but why do other clients work? (VLC, ipad2)

 

Streaming to Kodi also works btw...

 

 

 

Should I analyse further with wireshark?

Edited March 28, 2015 by bccrew

[bccrew]

I just tried to add Unicast devices to my DVBViewer client but the results are the same.. All channels work except for Animal Planet HD

 

 

I'm out of options here...?

[Derrick]

..make sure to use identical copies of the channels.dat on client and server and restart the server.

[bccrew]

The files are identical Derrick.. I even set up another laptop with a fresh DVBViewer installation and let the channel list download on startup when connecting to the DVBViewer Recording Service.

 

Is there any way to further debug the DVBViewer client or DVBSource filter?

[bccrew]

I just tried another test:

 

I stopped the RS and removed all RTSP tuners from the local DVBV client on the server. I scanned for devices and only added 2 dvbc tuners.

 

 

Animal Planet HD still doesn't work. Also BBC One HD not.

 

 

I really have no clue what's going on. Tuner is not the problem, other channels on same frequency work.

 

 

 

I tried tuning onto the channel with DVBDream and they work...

[Derrick]

..if it's not a settings problem, it could be the timing. There's something odd in your 1st screen shot. The PCR seems to be missing. Try again with unchecked "Check Timestamps Continuity" (->apply -> ok -> retune).

 

Also please open the transponder with TransEdit's analyser (see my screen shot). Last not least you can record a short sample with the analyser and upload it to a (free) file server.

 

 

[bccrew]

Check Timestamps Continuity did the trick :s

 

 

I wonder how suddenly this setting got changed on all my computers Is it unchecked by default?

[Derrick]

No, it's checked by default. Maybe the system is too sophisticated and thus less fault tolerant

 

But I've still doubts about you settings. What is the source of your channel list? A PCR is mandatory!

[bccrew]

Hold on... I just did some further testing..

 

Unchecking the "Check Timestamps Continuity" works for BBC One HD and Animal Planet HD but it takes a few seconds and stutters to create a stable graph...

 

You can see DVBSource filter jumping between low and high bitrate.

 

 

I have a mixed channel list, created it myself through scanning. Partly DVB-C channels and DVB-S channels from 28.2

 

 

I already removed the 2 problematic channels from my list, scanned again on the same frequency and I can only get a clear picture when unchecking that "Check Timestamps Continuity" for those 2 channels... When checking that tickbox, the screen goes black again.

Edited March 29, 2015 by bccrew

[Griga]

No, it's checked by default. Maybe the system is too sophisticated and thus less fault tolerant

 

@Derrick: It was you who requested this function some years ago

 

Obviously there is a PCR. A slight misinterpretation of the DVBViewer Filter property page screenshots...

 

@bccrew: "Check Timestamps Continuity" should usually be switched on. However, if a channel permanently broadcasts discontinuous time stamps this error checking mechanism spoils playback completely.

 

Please try DVBViewer Filter 3.9.1,(read the includes ReadMe for more information) which performs a more tolerant error checking. You are using version 3.8.1. I had to rework the code in order to handle the bad time stamp behaviour of internet TV broadcasters.

 

Does it work with DVBViewer Filter 3.9.1 and "Check Timestamps Continuity" ticked?

[bccrew]

Does it work with DVBViewer Filter 3.9.1 and "Check Timestamps Continuity" ticked?

 

 

To be short, no.. I have to untick the box to get a clear picture on both channels.

 

 

Can I debug it further with Transedit?

[Derrick]

BBC One HD from satellite 28E, 10847V? Then the other HD channels like BBC Two HD on this transponder channels should suffer as well. Your screen shot from Animal Planet HD is an encrypted service from the Dutch cable operator Ziggo.

[bccrew]

No it's not... I live in Belgium. I have signed a NDA so I can't say much about it. It's a new provider on cable in my region doing tests to enter the market in Q4 of 2015. Please pm me for more info.

Edited March 30, 2015 by bccrew

[Derrick]

..and BBC HD? Pls. upload some 50MB of "Animal Planet HD" recorded with transedit 4.1.0 from beta section (-> analyze -> left window select service -> right click -> select PIDs -> start recording).

[bccrew]

https://www.sendspace.com/file/5zjlqq

[Derrick]

Tell your cable operator that the PCR of this channel is very jumpy

 

You'll have to switch the source filter to DVB (my favourite view ). The recording can be played without problem but I have a newer version and live playbck is still something different. Though this won't explain your problem with BBC HD.

[Griga]

Some broadcasters seem to mistake the PCR for a random number generator...

[Derrick]

..or the source filter uses the next adaptation field control = 3 without checking the PID for extracting the PCR

 

I've opened the file with TSDoctor expecting lots of PCR errors, but nothing. Then I searched deeper and found another pcr in the audio stream with pid 3202. That's the jumpy one. 3201 is just fine.

 

Could be a severe bug of the source filter..

[Griga]

Then I searched deeper and found another pcr in the audio stream with pid 3202. That's the jumpy one. 3201 is just fine.

 

Well analyzed! I can see it in the Transedit Analyzer -> Hex Viewer and reproduce the issue with the TransEdit preview function that does a live simulation.

 

The source filter behaviour is no bug, but intended. Since the PCR PID specified by the host application may be wrong or nonexistant (we already had such cases...), the DVBViewer Filter checks if the arriving streams contain a PCR. If yes, it is used. However, it doesn't consider that there may be two streams containing contradictory PCRs. Looks like I have to rethink the matter...

[bccrew]

I can record some sample files of channels that don't have this problem if you guys want..? And provide a sample of BBC One HD

[Derrick]

 

However, it doesn't consider that there may be two streams containing contradictory PCRs. Looks like I have to rethink the matter...

Bug or design flaw, the designated PCR should be taken first. And even if there is only a hidden PCR this should be indicated. Otherwise it remains undetected and leads to the wrong conclusion

 

 

I can record some sample files of channels that don't have this problem if you guys want..? And provide a sample of BBC One HD

Only if BBC One HD is from your cable.

[Griga]

the designated PCR should be taken first.

 

There is no time to analyse the streams before making a decision. Since the PCR is the base for all playback timing, it must be retrieved as early as possible. Without a time base playback can't start, and it can't be changed later without stopping and restarting playback. With other words: There is no time to wait (maybe forever) if we can get something better than the first PCR that is arriving.

 

However, using the audio PTS as time base substitute may be a better strategy than risking a wrong PCR.

 

First PCR arrives -> does not match the specified PCR PID -> ignored

Specified PCR never arrives -> Audio PTS is used as time base

 

The handling of (broadcasted) PCR/PTS irregularities always works in some cases and doesn't in other cases - whatever you try. There are no solutions that cover all kinds of PCR/PTS irregularities. The only thing you can do is to heuristically find a solution covering the most frequent irregularities over time...

[Derrick]

There is a PID filter, isn't it?

[Griga]

Sure. But it doesn't help if the video and audio stream of the to-be-played channel contain different PCRs.

 

The issue reported here can be fixed easily, but it may unforseeably give other issues an opportunity to raise their ugly head... and there is only one thing you can rely on: When it happens Derrick will assume "a severe bug in the source filter"

[Derrick]

 

Sure. But it doesn't help if the video and audio stream of the to-be-played channel contain different PCRs.

Then use the PID filters and only take the PCR from a single PID and do not mix different streams. The audio rate of this "HD" channel is appallingly low. Even with first PCR come, first serve, the probability that the 1st PCR is the correct PCR is very high. There is no need to take all you can find without filtering..

 

..and btw. when searching for an explanation the source filter can't be trusted any more

[bccrew]

I have 2 new samples:

 

EEN HD no problems with default DVBViewer settings:

 

https://www.sendspace.com/file/eyyggn

 

 

BBC ONE HD: troubles!

 

https://www.sendspace.com/file/eelj56

[Derrick]

..same story with BBC ONE HD. You'd better take the original from satellite. Shouldn't be a problem in Belgium

 

As shown before due to a design error DVBViewer mixes the faulty hidden pcr with the correct pcr. No problem with EEN HD. Apparently your cable provider is transcoding external HD services.

 

/edit

 

BBC ONE HD is even worse because I can't play this file with any member of the DVBViewer family no matter what dvb source settings I use. Even with TSPlayer (normally the most resilient method ) I have to move the slider first before a picture is shown.

 

All other players (VLC, MPC) will play the file without any problem. Same with streaming to my new Samsung 4kTV

[Derrick]

The reason why the BBC ONE HD file reacts different could be the fact, that by accident the 1st ts_packet containing an embedded pcr (adaptation field control = 3) comes from the audio stream.

[bccrew]

I guess it's due to a recent change at the provider. These are the only 2 channels that have a problem and they happen to be on the same frequency and they used to work without problems.

 

I'll try to pass the feedback to their technicians....

 

Should the PCR always be present in the Video stream? Is the DVB Clock something only applicable for dvb-s? Where can I read up on these specifications?

Edited April 1, 2015 by bccrew

[Derrick]

 

Should the PCR always be present in the Video stream?

No, there can be a separate pid for the pcr or it can be embedded in some other stream e.g. audio. The application knows where to find it from the PMT.

 

 

Is the DVB Clock something only applicable for dvb-s? Where can I read up on these specifications?

It's the system clock for transport streams (ts). You'll find everything in the ISO 13818-1

 

 

PCR_PID – This is a 13-bit field indicating the PID of the Transport Stream packets which shall contain the PCR fields

valid for the program specified by program_number.

If another stream with a different pid also contains a pcr, the application simply should ignore this. Apparently only DVBViewer looks at other locations as well.