[linux-dvb] Re: Twinhan DST / TS204 and signal quality questions

[Måns Rullgård <mru@pronto.tv>]

Jukka Tastula <jukka.tastula@kotinet.com> writes:

> On Sunday 15 August 2004 22:52, Måns Rullgård wrote:
>
>> > They seem to be having some weird standards compliance issues with
>> > transmitting here anyway.
>> Here = Finland?  Care to elaborate a little on these issues?
>
> Okay, I admit that maybe "standards compliance issues" was a little bit of 
> a reach but problems still.
>
> YLE/digita/whoever only a while ago announced that they're "fixing" the dvb 
> subtitles. Something about sending an "End of Display Segment" bit in the 
> stream. Still doesn't work that well with many (any?) STBs. Things like 
> these make you wonder how many standard features they're still missing, 
> after all these years.  I'm sure a part of the problem is lack of interest 
> as dvb subtitles aren't very commonly used but can it really be that hard 
> to get it right? They've had 3 years already.

IMHO, there is never an excuse for sending non-compliant data.

> Then the "mux-b" has some technical problems. They say it's because of 
> "static bitrate" (or something like that). What happens is that the 
> picture has huge blocks (doesn't look like the ones you get from low 
> bitrate to me, more like errors) just before ~every other scene change. I 
> can't see this happen on the philips nor the panasonic STB but it happens 
> alot on my nebula. Not very annoying but still, I can definitely see the 
> artifacts. Now digita says on their web page that the problem will be 
> fixed some time in September. I'm not really sure which year they mean, 
> though. Again they've already taken 3 to get it right :) 

Which satellite/transponder is this on?

> Also on mux-b they seem to be throwing in some long (>15) GOPs every once 
> in a while. Some apps complain about them being illegal. Maybe they're 
> poor and got a cheap encoder or something.

This is all I can find about GOP sizes in the DVB spec regarding 25 Hz
SDTV:

5.1.7      Video sequence header

  Encoding:  It is recommended that a video sequence header,
             immediately followed by an I-frame, be encoded at least
             once every 500 milliseconds. If quantizer matrices other
             than the default are used, the appropriate
             intra_quantizer_matrix and/or non_intra_quantizer_matrix
             are recommended to be included in every sequence header.

  NOTE 1:    Increasing the frequency of video sequence headers and
             I-frames will reduce channel hopping time but will reduce
             the efficiency of the video compression;

  NOTE 2:    Having a regular interval between I-frames may improve
             trick mode performance, but may reduce the efficiency of
             the video compression.

A maximum of 500 milliseconds would mean an I frame every 12 frames,
but it is only a recommendation.  Complaining about longer GOPs is
broken behavior.

-- 
Måns Rullgård
mru@pronto.tv