DBSTalk Forum banner
Status
Not open for further replies.
1 - 13 of 13 Posts

·
Godfather
Joined
·
284 Posts
Discussion Starter · #1 ·
I'm wondering if we aren't blaming the HR20 for bad MPEG4 feeds. I saw in another thread where someone said the OTA broadcast toggled from SD to HD, and this coincided with people having problems.

So, I wonder if the HR20 were to better handle these sort of issues (SD/HD swapping, signal drops outs/loss, etc), if the lockups/bad recordings issues would go away. Obviously to be replaced with recordings with blanks in them.

But at that point, we'd be pointing the finger at the networks instead of the HR20. I just think that the problems are so random that it might be seemingly random because of the various local feeds and their respective quality (or lack thereof).

Perhaps if D* were to make the HR20 more robust in handling bad feeds or error conditions in the feeds, it'd remain more stable and we could focus on getting the problematic stations to fix their broadcasts!
 

·
Lifetime Achiever
Joined
·
21,332 Posts
Speaking about the 'E3 release, there was strong evidence that you are somewhat correct. MPEG4 feeds were not robust and exacerbated problems for some people. And I can understand where problems in the MPEG4 feed can easily occur. Many local stations are still toying with their HD datastreams, forcing many people to rescan OTA often; glitches; etc. So when D* transcodes the ugly HD streams into MPEG4 both the transcoder likely needs to be more robust as well as the HR20.

On the other hand, many of us had similar problems without using MPEG4 or without even having MPEG4 feeds. Clearly, the box was not baked enough in testing to meet the standards for a piece of consumer electronics.

Cheers,
Tom
 

·
Godfather
Joined
·
284 Posts
Discussion Starter · #3 ·
tibber said:
So when D* transcodes the ugly HD streams into MPEG4 both the transcoder likely needs to be more robust as well as the HR20.
Excellent point, the encoding is surely part of the equation. I'm simply not convinced that the unit itself is fully to blame.

Unfortunately, they probably did (do) all their testing with pristine MPEG4 streams. So perhaps adding some additional bad or broken feeds to their QA will improve things, since they will be able to better work around the broadcast issues.

It's just a suggestion. I know that I have been guilty in the past of only testing for positive conditions. But I quickly learned to think like my customers and do things outside of the bounds of what an ideal user would do. I'm fairly sure they are not testing with any garbage or broken streams. I think it'd help the stability and robustness of the unit immensely if they were to start doing so.
 

·
Legend
Joined
·
192 Posts
tibber said:
So when D* transcodes the ugly HD streams into MPEG4 both the transcoder likely needs to be more robust as well as the HR20.
That brings up a question in my mind - Does D* transcode from MPEG2 to MPEG4 or do they get an uncompressed (e.g. ASI or HD-SDI) stream from the network and encode into MPEG4 (therefore it's just encoding not transcoding)?
 

·
I used to be a rocket scientist
Joined
·
12,182 Posts
Interesting observation that seems to hit the nail right on the head.

You know, about a year ago when the 5G video iPods hit the streets, there were lots of problems with MPEG4 videos for it, especially H.264 (the same standard picked by D* for MPEG4 locals). There were a variety of fixes released over the subsequent months, both by Apple (for the iPod itself and for QT7 which formed the basis for most encoding apps) and by 3rd party developers using QT and home-grown routines to encode or transcode video for playback on the boxes. After a few months as the bugs were worked out and the error-handling was tightened up at both ends, the boxes started working as advertised.

I hope (and still believe) that this is what's going on with the HR20. If it was an Apple "iHD" box, I might be more confident still. :lol:
 

·
Godfather
Joined
·
284 Posts
Discussion Starter · #6 ·
pgiralt said:
That brings up a question in my mind - Does D* transcode from MPEG2 to MPEG4 or do they get an uncompressed (e.g. ASI or HD-SDI) stream from the network and encode into MPEG4 (therefore it's just encoding not transcoding)?
Hmm I'm not certain but I think it's a raw OTA feed (but that feed is probably MPEG4 to begin with) so it's transcoding it in a sense (compressing it).
 

·
Legend
Joined
·
107 Posts
I do remember in the earlier days of my first non-dvr HD D* box, that variations in the adherence to standards from the OTA channels would cause lockups and other issue quite frequently. In fact I knew to never leave my system tuned to an OTS HD channel or I could expect with high certainty that when I next tried to use, it wouls require a hard reset. These situations subsided over time and with several firmware updates. So, it stands to reason that we might be experiencing the same things with the implementation of MPEG4 locals. Whether we blame the box or the networks, the net result is that in all likeliehood these issues will diminish over time.
 

·
Banned
Joined
·
4,642 Posts
Does the H20 handle local MPEG4 HD channels? If it does, don't blame the stations. Remember the H20 had been out for quite some time now. If it can get MPEG4 signals shouldn't the HR20?
 

·
Godfather
Joined
·
284 Posts
Discussion Starter · #9 ·
Wolffpack said:
Does the H20 handle local MPEG4 HD channels? If it does, don't blame the stations. Remember the H20 had been out for quite some time now. If it can get MPEG4 signals shouldn't the HR20?
Completely different. It doesn't have to record anything, it's just a tuner.
 

·
Banned
Joined
·
4,642 Posts
jkc120 said:
Completely different. It doesn't have to record anything, it's just a tuner.
Yea, I knew that. My point was that if folks are thinking the problem is with the MPEG4 feed, from original HD OTA signal, through the DTV uplink and downlink, then the H20 would be experiencing the same signal problems. Since the H20 isn't, the problem doesn't seem to be the MPEG4 signal itself, just how the HR20 handles/records/plays that signal.

So, yes completely different as long as we don't start blaming the feed. The problem is with how the HR20 handles the signal. And if the H20 can do it correctly, maybe the HR20 team should grab some folks from the H20 coding side and ask them how they did it.
 

·
Banned
Joined
·
4,642 Posts
tibber said:
Speaking about the 'E3 release, there was strong evidence that you are somewhat correct. MPEG4 feeds were not robust and exacerbated problems for some people. And I can understand where problems in the MPEG4 feed can easily occur. Many local stations are still toying with their HD datastreams, forcing many people to rescan OTA often; glitches; etc. So when D* transcodes the ugly HD streams into MPEG4 both the transcoder likely needs to be more robust as well as the HR20.

On the other hand, many of us had similar problems without using MPEG4 or without even having MPEG4 feeds. Clearly, the box was not baked enough in testing to meet the standards for a piece of consumer electronics.

Cheers,
Tom
These are the comments I'm reffering to in my posts above. If the H20 can decode and play these same MPEG4 signals but the HR20 can't, I don't see how this is a signal problem.
 

·
Banned
Joined
·
4,642 Posts
jkc120 said:
Excellent point, the encoding is surely part of the equation. I'm simply not convinced that the unit itself is fully to blame.

Unfortunately, they probably did (do) all their testing with pristine MPEG4 streams. So perhaps adding some additional bad or broken feeds to their QA will improve things, since they will be able to better work around the broadcast issues.

It's just a suggestion. I know that I have been guilty in the past of only testing for positive conditions. But I quickly learned to think like my customers and do things outside of the bounds of what an ideal user would do. I'm fairly sure they are not testing with any garbage or broken streams. I think it'd help the stability and robustness of the unit immensely if they were to start doing so.
Does anyone know what MPEG4 decoder chips the H20 and HR20 are using? Maybe it's at the hardware level.
 

·
Godfather
Joined
·
340 Posts
Wolffpack said:
These are the comments I'm reffering to in my posts above. If the H20 can decode and play these same MPEG4 signals but the HR20 can't, I don't see how this is a signal problem.
I think the HR20 and the H20 probably use the same decoders. The HR20 is probably decoding the MPEG4 signals fine. I think the recording part of the HR20 is seeing minor glitches in the decoded signal (which wouldn't affect live viewing) and is dumping the recording (partial, deleted, or missed). This then has a domino effect screwing up other things in the unit (lock ups, unresponsive, etc.). Then most of the time a reset gets it back on track. Until it happens again. Then the cycle repeats itself. I am probably 100% wrong but just wanted to give my thoughts.:)
 
1 - 13 of 13 Posts
Status
Not open for further replies.
Top