Can your box record the Olympic HD streams

grahamlthompson

In memoriam
Joined
Aug 3, 2006
Messages
25,815
Reaction score
4,434
Points
3,988
Location
Redditch
In order to clarify the situation, can anyone with a Freesat pvr different to the ones already posted see if they can record one of the BBC Olympic HD streams.

I will start the ball rolling


Foxsat-HDR - NO
 
Technisat HDFS- YES Echostar- YES

Thanks can you live pause, rewind and fast forward when replaying the recording. Apols should have asked this first.
 
grahamlthompson said:
In order to clarify the situation, can anyone with a Freesat pvr different to the ones already posted see if they can record one of the BBC Olympic HD streams.

I will start the ball rolling

Foxsat-HDR - NO

?? Really? I hope it can as mine accepted the series link. Why can't it do that?
 
?? Really? I hope it can as mine accepted the series link. Why can't it do that?

When it finishes recording it deletes the recording .ts file as it thinks it's zero length. The .ts file it creates and then deletes is very odd. Medianinfo reckons there is no video content. AV2HDR crashes if you try and load it.

As a workaround you can add the SD streams to the epg using the custom firmware.
 
ok, after asking SO many questions yesterday, I try to provide some answers.

1) red button functionality has changed since yesterday. Whilst yesterday red button behaved like freeview (ie it would actually change channel when selecting a stream, now it stays on the Olympic RB channel

2) recording now works, whilst it did not yesterday

3) live pause works

4) BBC DOG is now a better size, but unlike online, still says BBC sport with rings

5) Olympic football graphics are still as awful as yesterday and looking 10 years old. and still telling you which half is played - the most global of sports does not require which half but does require an indication which /shirts/shorts are which team, esp when they have similar flags.

6) manual SD channels look bad, but to me look even worse on freeview SD.
 
As a workaround you can add the SD streams to the epg using the custom firmware.

I'm trying to add the SD channels using the custom firmware, but where do I find the SD Olympic channels listed in the Channel Editor? I can only see channels 151 - 174 which are the HD ones.
 
I'm trying to add the SD channels using the custom firmware, but where do I find the SD Olympic channels listed in the Channel Editor? I can only see channels 151 - 174 which are the HD ones.
Do a manual (non-Freesat) scan first, then "import" in the channel editor.
 
When it finishes recording it deletes the recording .ts file as it thinks it's zero length. The .ts file it creates and then deletes is very odd. Medianinfo reckons there is no video content. AV2HDR crashes if you try and load it.

As a workaround you can add the SD streams to the epg using the custom firmware.

Hi Graham
Any ideas what's different about these channels and why the HDR responds in this way? :confused:
 
Hi Graham
Any ideas what's different about these channels and why the HDR responds in this way? :confused:

Not sure, but the format of the .ts file is very peculiar.

Looking at the file with Medianinfo shows no video content at all :confused:

File properties in Windows Explorer says 1920 x 1080 pixels.

Opening the file using AV2HDR crashes it (I was trying to build a working .nts).
Raydon is very busy at the moment, hopefully in a while he will get a chance to have a look.

Splash Lite plays the content.

It's not the first time this has been a problem. When CH4-HD first started test transmissions on Eutelsat28A then non-freesat test recordings had the same problem. The stream was altered a short while just before the channel launched on Freesat.
 
Not sure, but the format of the .ts file is very peculiar.

Looking at the file with Medianinfo shows no video content at all :confused:

Just recorded a couple of mins on a non-freesat box and mediainfo says:

General
Complete name : E:\This is BBC Olympics 1 HD.ts
Format : MPEG-TS
Format profile : No PAT/PMT
File size : 159 MiB
Duration : 2mn 9s
Overall bit rate : 10.2 Mbps

Video
ID : 512 (0x200)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=1, N=48
Duration : 2mn 9s
Bit rate : 9 548 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.184
Stream size : 147 MiB (93%)
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 640 (0x280)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Duration : 2mn 9s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -751ms
Stream size : 2.97 MiB (2%)

Don't know if this is any use. FWIW on a quick scan it looks more or less identical to Starplus HD when it was FTA for a day or two.
 
An observation regarding recordings of BBC Olympic HD channels being of zero length:-

Although an .nts file is created it remains at zero bytes throughout the recording.
 
Don't know if this is any use. FWIW on a quick scan it looks more or less identical to Starplus HD when it was FTA for a day or two.

It might well help Raydon or others figure out what's going on.

I should have said very limited video info (no resolution). Here's the data from a Foxsat

General
ID : 2022 (0x7E6)
Complete name : E:\ZeroTS\This is BBC Olympics 2 HD_20120724_1656.ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 260 MiB

Video
ID : 512 (0x200)
Menu ID : 7803 (0x1E7B)
Format : AVC
Format/Info : Advanced Video Codec
Format version : Version 2
Format profile : [email protected]
Codec ID : 27
Frame rate : 25.000 fps
Chroma subsampling : 4:2:0

Audio
ID : 640 (0x280)
Menu ID : 7803 (0x1E7B)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : 4
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -951ms
Language : English

Menu
ID : 256 (0x100)
Menu ID : 7803 (0x1E7B)
List : 512 (0x200) (AVC) / 640 (0x280) (MPEG Audio, English)
Language : / English
 
An observation regarding recordings of BBC Olympic HD channels being of zero length:-

Although an .nts file is created it remains at zero bytes throughout the recording.

I have a hunch that the data the Foxsat uses to build the .nts file is missing from the data stream. Could be the reason why AV2HDR crashes on the original file. Remuxing the file using TSmuxergui produces a file that AV2HDR reports as being of undeterminate length or less than 30 seconds.
 
Barry at My Humax has just posted Humax are working on a fix - watch this space :D

Now followed by a post from Humax. Post 16 is spot on.
 
Last edited:
Just had a peek at a sample .ts I captured on my Foxsat HDR from one of the Olympic HD channels and there were no regular 0x47 sync bytes in the file. In the transport stream format used on the HDR each packet is exactly 192 bytes long. The first 4 bytes are used for timing, and the fifth is always the sync byte 0x47.
G.L.T. can you examine your sample in a hex editor and see if it contains sync bytes as the sample I took was while the channel was just displaying an information screen, not a live broadcast.
 
Last edited:
Just read myhumax thread and Humax's explanation, good they seem to be pulling out the stops to find a fix.

I wonder why they are using a different structure for the transport stream to BBC1 etc? I note that it has mpeg layer 2 audio but don't see that being relevent.

Anyone got any ideas why there's the missing timming information?

Is it because the stream is distributed to other broadcasters?
 
I wonder why they are using a different structure for the transport stream to BBC1 etc? I note that it has mpeg layer 2 audio but don't see that being relevent.

Anyone got any ideas why there's the missing timming information?

Is it because the stream is distributed to other broadcasters?

I'm not sure the timing information is missing. Searching for 0x47 in an olympics recording and something from BBC HD preview just produced identical results: bytes found at 0, D8, 170, 228, 2E0, 398 (plus a few others of course but these were the ones in common). Does this suggest the timing info is still there? NB recorded on a NON freesat box.

Could it be something to do with GOP length?
 
Last edited:
G.L.T. can you examine your sample in a hex editor and see if it contains sync bytes as the sample I took was while the channel was just displaying an information screen, not a live broadcast.

So was mine, off to see the daughter in Bridgwater in a bit so won't have chance to grab another sample till Monday.
 
I'm not sure the timing information is missing. Searching for 0x47 in an olympics recording and something from BBC HD preview just produced identical results: bytes found at 0, D8, 170, 228, 2E0, 398 (plus a few others of course but these were the ones in common). Does this suggest the timing info is still there?

Could it be something to do with GOP length?

The BBC have started using longer GOP's in the last couple of months on BBC1 and BBC HD as far as I can see, particularly noticeable at the end of a program when there's a static image. This doesn't seem to cause any problems and saves bits.

DVD specification stipulates MPEG 2 15 frames max but I've never found a DVD player that would't play longer GOPS.

But who knows?

Quote from Bob H at Humax:

Bob H said:
Just to provide some detail:– The problem exists because in the way that the stream is being encoded the box cannot build the required PVR indexing correctly. This causes it to get confused and believe the recording is zero in time. Other devices use other indexing mechanisms. The problem is now understood.– As soon as we became aware that the issue could not be resolved at the broadcast end, engineering resource (in the UK) which was already monitoring the situation was quickly dedicated to producing a fix.– Releasing
software too quickly is a risk to the consumers, we could easily accidentally break something else in the process.– When a fix is available a beta version *may* be released before we have finished our internal quality sign-off, this would have to be sanity checked first by us and freesat, and the aim of this would be to give you the choice of risk vs function.
I hope for there to be more information later today but I am not going to pre-empt any of that until we have everything aligned.
 
Last edited:
I'm not sure the timing information is missing. Searching for 0x47 in an olympics recording and something from BBC HD preview just produced identical results: bytes found at 0, D8, 170, 228, 2E0, 398 (plus a few others of course but these were the ones in common). Does this suggest the timing info is still there? NB recorded on a NON freesat box.

Could it be something to do with GOP length?
I don't think so, that would only affect the program stream. Transport stream packets are exactly 192 bytes long, regardless of the program stream payload contained within them. The sync byte 0x47 must appear in the fifth byte and every 192 bytes thereafter or it's not recognised as a valid transport stream.
 
Have rescanned Humax in NON-FREESAT mode and can record the SD channels at 5331 onwards. If you are brave you can install the Channel Editor package and change the channel ID from Non-free sat to Free-sat and have it in your Freesat EPG
 
Well what can I say? I have been watching the Olympics on tv since Tokyo 64 and this just blows it all away, ok we can't record in HD (on Foxsat yet!) but we can watch our choice of sports on 24 HD streams and record SD (using the excellent custom firmware developed by a dedicated group of enthusiasts)
I was very impressed with the extra dimension HD provides in close up sports like table tennis and gymnastics, it would be really great to be able to record it in HD, lets hope Humax bite the bullet and release the fix soon, if only in a downloadable file format and not a broadcast update that may cause havoc if it goes wrong.
 

The latest video from AVForums

TV Buying Guide - Which TV Is Best For You?
Subscribe to our YouTube channel
Back
Top Bottom