Issues Playing / Editing Humax HD Fox T2 Saorview Recordings on a PC

dmm1000

Hi All

I have purchased recently a Humax HD Fox T2 (non PVR version) for Saorview
And have downloaded the latest firmware and added an external hard drive – to turn it into a PVR – this all works fine – it records and plays back Saoirview perfectly on the Humax box itself
The problem arises when I go to transfer the recordings to a PC – basically in a nutshell because it seems they are in MPEG4 format and as far as I know using the M2TS container (they have an extension of .TS) they will not even play in VLC (Windows 7)
I have tried various programs to try and even demux the streams to begin within (the ultimate goal is to try to convert to ANY file that will play on at least a PC (but then hopefully XBOX / PS3)
I’ve tried several demuxers such as TSMUXER / DOCTOR TS / VideoRedo / PVAStrumento – they either just crash but mostly complain that the Program Map Table (PMT) is missing from the recorded file

I have been reading on AVForums about this and it seems its ok with getting UK (non HD) freeview recordings playable on a PC because they are MPEG2 but I think that because Saorview is MPEG4 whatever PC Tools / converters I use there is always an issue – so basically I’m stuck with playing recordings back on the Humax HD Fox T2 for now

Has anybody who owns this particular model successfully managed to get Saorview recordings either playing on a PC using a particular software or managed to edit the video / audio (chop out ad breaks etc etc) ?

Apogee

I've noticed that PMT error showing up live on a Vu+ Duo. It might be an error in the transmitted stream, or there may have been changes to the channel settings - might be worth deleting the existing channels and doing a rescan.

For playback on PC, you'll need an MPEG4 codec (such as the one which comes with PowerDVD 8 or above). I find Media Player Classic (such as comes with Real Alternative) better than VLC sometimes for playback.

dellWlan

afterdawn is always good for guides, how to's and info

http://www.afterdawn.com/guides/archive/how_to_play_ts_content_on_playstation_3_ps3.cfm


... just read it though and it says to use tsmuxer...sorry

dmm1000

thanks guys
yes tried most of the software / advice on videohelp.com / afterdawn

it must be a peculiarity in the Saorview mpeg4 stream - will do a rescan and see what happens - or may just replace the humax for another pvr that produces more "pc friendly" recorded files which allow themselves to be demuxed and edited (my main requirement)

Apogee

If you're reading UK forums, then whatever apps they use for HD material on the Humax should also work for Saorview because they're both MPEG4.

Apogee

Well, a quick Google throws up a major potential problem with this box:

Both the HD and HDR encrypt all SD and HD recordings on the drive used for recording. With the HDR you can copy SD recordings to an external drive and they are then unencrypted and can be played on a PC. With the HD it doesn't seem to unencrypt when copying to a second drive (this requires a powered USB hub as well) - I think this is a bug. In both cases you can't unencrypt HD recordings.

If the above is true, then there's a very strong possibility that this receiver sees the Saorview MPEG4 streams and automatically assumes they're HD and therefore encrypts them.

You should check a bit more if anyone has got around this problem with HD material in the UK.

dmm1000

yes thats correct it seems

I read to the end of the thread - 2nd last post sums it up

"The player that is capable of playing these files is the box of electronics that encoded them in the first place."

I'm not holding out for an updated firmware from Humax for this box - time to look for an alternative i think - but i guess for those just looking to use it as a PVR and not to edit files / play recordings on other devices then it does that job ok

Johnboy1951

Is this common? ........ sorry I mean the encryption of the stream when recording it ......

Do all such devices do this or only some?

I find this info very disconcerting ...... :mad:

Apogee

Johnboy1951 wrote: »

Is this common? ........ sorry I mean the encryption of the stream when recording it ......

Do all such devices do this or only some?

I find this info very disconcerting ...... :mad:

Official UK Freesat HD and Freeview HD boxes do. In the case of Freesat HD boxes, you can get around it with the Humax ones by recording HD material in non-Freesat mode.

I'm not sure how many Freeview HD receivers have USB ports for transferring material - if they do, I suspect they are obliged to encrypt the HD material.

Johnboy1951

Apogee wrote: »

Official UK Freesat HD and Freeview HD boxes do. In the case of Freesat HD boxes, you can get around it with the Humax ones by recording HD material in non-Freesat mode.

I'm not sure how many Freeview HD receivers have USB ports for transferring material - if they do, I suspect they are obliged to encrypt the HD material.

Thanks for the info.

Now beginning to wonder about the Saorview situation ... I will be interested to read about Saorview PVR devices ....

STB

Run it through TS Doctor (cypheros).

It will rebuild the PMT for you and save the file with a name of file_fixed after it.

Format Factory and XMedia Recode allow chopping out of adverts of the fixed TS file.

I have no problem with RTE recordings doing this.

You will have problems with BBC HD recordings because they do have protection in the streams.

Apogee

@STB - Do you know why that PMT error is present? Is there something broken in the RTÉ streams?

dmm1000

thanks STB - been there done that - no joy - as soon as i open the file it goes through a series of "tests" the first few it passes in green - then see the failure to find a PMT table is the one in red - see the results - attached

STB

Apogee wrote: »

@STB - Do you know why that PMT error is present? Is there something broken in the RTÉ streams?

There is no protection in the raw transport streams broadcst by RTE (or infact BBC via Freeview etc).

Its controlled by the box Apogee. In order to get freeview HD certification its enforced in the firmware for all Freeview HD boxes. As a knock on effect the Freeview HD box and its interoperability with Saorview as recordings go, are also affected.

Of course any combo box wont have the same limitations. I regularly get PMT errors and have to rebuild it through TS Doctor but it doesnt crash on running Cypheros.

The problem I gather is Freeview HD certified products and the inbuilt protection in play that goes with getting that certification - its only on HD - not SD. Copy control in the UK.

One for those to bear in mind buying Freeviews HD products who want to archive stuff to DVD or move to laptop etc.

@dm1000 - sorry man - I dont crack encryption. However I suggest you look around for alternative "third party" firmware for that Humax model. Its bound to have cheesed someone else off. It will be an issue for a one box solution in cross border areas !

Apogee

I was asking about the PMT errors, not the protection flags. Do you know what is causing the PMT errors?

STB

Yes. It cant find the data. Its normally the PAT it cant find so TS Doctor rebuilds a new one from PMT. If you dont do that VLC crashes.

PAT is the Program Association Table. This table lists all the services found in this Transport Stream. Each service is identified by a PMT. The PAT is always on PID 0.

PMT is the Program Map Table. This table identifies all the Elementary Streams within a service. There is one PMT per service, but there may be more that one PMT on the same PID.

Here is a rebuilt PAT from PMT report for RTE 1.

Apogee

OK, I appreciate the reply, but that wasn't what I was asking either.

I was wondering what is causing the PMT error in the first place i.e. is it a problem at the receive end (poor signal, problematic receiver) or is it a problem at the transmission end (data missing in the transmitted stream, improperly encoded/broken stream)?

STB

I know what your asking but I dont have a DVM400 lying around.

I dont know if looking at basic recent PAT, PMT data would help either. The H264 streams are a little more complex.

Textbook answer is that its one of three things i.e. at TX end

Repitition rate less than 500ms
No or Scrambled PAT/PMT missing in PAT
Table ID not equal to zero for PAT (for PMT ID value is 2).

But that would mean the receiver wouldnt decode anything. So what extra/less is the receiver doing with the TS/TRPs that it is recording. Well its is apparent what extra it is doing on Freeview HD gear.

Withour proper testing equipment you cant compare.

Apogee

Right, getting back to original problem do you know with the Freeview HD receivers, does the receiver encrypt material when it sees a specific (copy protection) flag in the stream, or does it simply turn on encryption when it sees that the video is MPEG4?

Apogee

@dmm1000 - can you do a factory reset on the receiver, rescan the channels and upload a 10-20 sec recording from RTE1 so we could have a look?

dmm1000

hi guys
i sure will - i may not get to do it this weekend - but will upload a short clip / file asap
As far as i know yes - it must be encrypting because it is MPEG4 (surely RTE have no deliberate encryptions in place ? ) - there must be something in the firmware which recognises MPEG4 and then encrypts it (but im guessing in fairness) - I think in order to get Freeview HD certification the set top box must by law encrypt HD recordings (my guess is that although Saorview is MPEG4 but not necessarily HD - (its was TG4 recordings im having problems with) then it goes ahead and encrypts regardless
another interesting side question is - does each Freeview HD box that implements encryption use the same algorithim to encrypt (or is each manufacturer unique in their encryption algorithim ) ?

Also i would like to hear from any users of Walker STB's (those Walkers that can record to USB device) - any of you have issues with trransferring your recordings on a PC (editing / playing) ?

Johnboy1951

On a related note I will post my recent experience with a USB DTT dongle .... one of those 'cheapies'.

I recorded from TG4 last night, the film "The Return of a Man Called Horse".
Using Linux, I recorded fom Kaffeine, to one large file ... 2.6GBs
That file will play in some media players but will for instance crash VLC. That is a problem I have been aware of for some time ..... VLC does not like the format of the Kaffeine file at all it seems.
I ran the file through ffmpeg to 'tidy-up' the m2t stream and VLC will play that readily.

Here is the mediainfo of the recorded file .....

mediainfo '/home/user/Videos/The Return of a Man Called Horse-2.m2t'
General
ID                               : 1001 (0x3E9)
Complete name                    : /home/user/Videos/The Return of a Man Called Horse-2.m2t
Format                           : MPEG-TS
File size                        : 2.61 GiB
Duration                         : 2h 6mn
Overall bit rate                 : 2 959 Kbps

Video
ID                               : 1104 (0x450)
Menu ID                          : 1104 (0x450)
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : Main@L3.0
Format settings, CABAC           : Yes
Format settings, ReFrames        : 4 frames
Format settings, GOP             : M=1, N=48
Codec ID                         : 27
Duration                         : 2h 6mn
Bit rate                         : 2 554 Kbps
Width                            : 544 pixels
Height                           : 576 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.326
Stream size                      : 2.25 GiB (86%)
Color primaries                  : BT.470-6 System B, BT.470-6 System G, BT.601-6 625, BT.1358 625, BT.1700 625 PAL, BT.1700 625 SECAM
Transfer characteristics         : BT.470-6 System B, BT.470-6 System G
Matrix coefficients              : BT.470-6 System B, BT.470-6 System G, BT.601-6 625, BT.1358 625, BT.1700 625 PAL, BT.1700 625 SECAM, IEC 61966-2-4 601

Audio #1
ID                               : 1204 (0x4B4)
Menu ID                          : 1104 (0x450)
Format                           : MPEG Audio
Format version                   : Version 1
Format profile                   : Layer 2
Codec ID                         : 4
Duration                         : 2h 6mn
Bit rate mode                    : Constant
Bit rate                         : 192 Kbps
Channel(s)                       : 2 channels
Sampling rate                    : 48.0 KHz
Compression mode                 : Lossy
Delay relative to video          : -698ms
Stream size                      : 174 MiB (6%)
Language                         : iri

Audio #2
ID                               : 1214 (0x4BE)
Menu ID                          : 1104 (0x450)
Format                           : MPEG Audio
Format version                   : Version 1
Format profile                   : Layer 2
Codec ID                         : 4
Duration                         : 2h 6mn
Bit rate mode                    : Constant
Bit rate                         : 64.0 Kbps
Channel(s)                       : 1 channel
Sampling rate                    : 48.0 KHz
Compression mode                 : Lossy
Delay relative to video          : -676ms
Stream size                      : 57.8 MiB (2%)
Language                         : nar

Text #1
ID                               : 1304 (0x518)-100
Menu ID                          : 1104 (0x450)
Format                           : Teletext

Text #2
ID                               : 1304 (0x518)-888
Menu ID                          : 1104 (0x450)
Format                           : Teletext Subtitle

.. and the 'tidied' file .....

mediainfo /home/user/Videos/tidied-film.m2t
General
ID                               : 1 (0x1)
Complete name                    : /home/user/Videos/test.m2t
Format                           : MPEG-TS
File size                        : 2.48 GiB
Duration                         : 2h 6mn
Overall bit rate                 : 2 811 Kbps

Video
ID                               : 256 (0x100)
Menu ID                          : 1 (0x1)
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : Main@L3.0
Format settings, CABAC           : Yes
Format settings, ReFrames        : 4 frames
Format settings, GOP             : M=1, N=48
Codec ID                         : 27
Duration                         : 2h 6mn
Bit rate                         : 2 478 Kbps
Width                            : 544 pixels
Height                           : 576 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.316
Stream size                      : 2.19 GiB (88%)
Color primaries                  : BT.470-6 System B, BT.470-6 System G, BT.601-6 625, BT.1358 625, BT.1700 625 PAL, BT.1700 625 SECAM
Transfer characteristics         : BT.470-6 System B, BT.470-6 System G
Matrix coefficients              : BT.470-6 System B, BT.470-6 System G, BT.601-6 625, BT.1358 625, BT.1700 625 PAL, BT.1700 625 SECAM, IEC 61966-2-4 601

Audio
ID                               : 257 (0x101)
Menu ID                          : 1 (0x1)
Format                           : MPEG Audio
Format version                   : Version 1
Format profile                   : Layer 2
Codec ID                         : 3
Duration                         : 2h 6mn
Bit rate mode                    : Constant
Bit rate                         : 192 Kbps
Channel(s)                       : 2 channels
Sampling rate                    : 48.0 KHz
Compression mode                 : Lossy
Delay relative to video          : -1s 638ms
Stream size                      : 174 MiB (7%)
Language                         : iri

Menu
ID                               : 4095 (0xFFF)
Menu ID                          : 1 (0x1)
Duration                         : 2h 6mn
List                             : 256 (0x100) (AVC) / 257 (0x101) (MPEG Audio, iri)
Language                         :  / iri
Service name                     : Service01
Service provider                 : FFmpeg
Service type                     : digital television

That of course is in ~SD and not HD as it is from TG4.

I intend to do a similar exercise on some programme on RTE2 to see how that behaves.

Ques:
Is there a suitable section in boards to start a thread about the actual video file being transmitted .... to discuss the various aspects of handling the video files themselves rather than the transport mechanisms?
I had a look but did not spot anything appropriate.

Thanks.

STB

Apogee wrote: »

Right, getting back to original problem do you know with the Freeview HD receivers, does the receiver encrypt material when it sees a specific (copy protection) flag in the stream, or does it simply turn on encryption when it sees that the video is MPEG4?

Well by strict interpretation of the invisible DBook all H264 streams might be affected as UK Freeview SD material is presented in MPEG2, so L3 H264 streams that we use for SD would be a casualty.

The are using look up tables and a decompression algorithm encoded via Huffman.

Apogee

STB wrote: »

Well by strict interpretation of the invisible DBook all H264 streams might be affected as UK Freeview SD material is presented in MPEG2, so L3 H264 streams that we use for SD would be a casualty.

That's an awfully complicated way of saying you don't know either.

Apogee

Johnboy1951 wrote: »

Is there a suitable section in boards to start a thread about the actual video file being transmitted .... to discuss the various aspects of handling the video files themselves rather than the transport mechanisms?
I had a look but did not spot anything appropriate.

I'd say post a new thread in this forum as you'll prob encounter a greater proportion of users interested in it here (and with access to suitable equipment) as anywhere else on boards.

STB

Apogee wrote: »

That's an awfully complicated way of saying you don't know either.

Only members of DTG have a copy of the Dbook (7). The 6th edition was centred around DVB-T2 MPEG4. The latest version 7 has even newer proposals in this area including a structure to enable support for multiple DRMs.

Anyhow would my interpretation be any different to Humax ? For implementation purposes it might have been easier to seperate all H264 streams from archival to PC (and the ultimate fear of getting to the internet, shock horror).

As we know already, some manufacturers have had different interpretations of Dbook guidelines, particularly Panasonic.

The person that might know the answer to the question raised by dmm1000 would be Humax's Chief technologist, Bob Hannent.

Twitter: Bobdvb and his email is his first name at humaxdigital.com.

Apogee

It would make more sense to have a specific copy-protection flag in the stream which would allow broadcasters to turn on/off copy-protection at will. However, who knows whether individual manufacturers wouldn't still cut corners and encrypt all mpeg4 material assuming its all HD.

If we had access to the files from other Freeview HD recs which had been used to record Saorview matieral, we could get an idea whether the OPs problem is due to encryption or something else.

dmm1000

I had lent my friend the Humax to try out last weekend I've asked him to record a few short clips of RTE1 / TG4 and will hopefully have them mid week

dmm1000

Hi Apogee / STB

PM sent giving access to some sample recordings on the Humax HD Fox T2
You can have a play if you get a chance - appreciated

fat-tony

dmm1000 wrote: »

Hi Apogee / STB

PM sent giving access to some sample recordings on the Humax HD Fox T2
You can have a play if you get a chance - appreciated

I have TS stream analyser and a good selection of players if you want me to have a go also;)

dmm1000

sure Tony - pm sent

and anyone else who would like to have a look at some recordings (.ts files) produced by the Humax HD Fox T2 receiver I can PM you the link where you can download them from - I know some of you may even actually enjoy looking at these things but I appreciate it requires use of your spare time

STB

I wouldnt bother dmm1000.

ALL recordings off that box are encrypted, not just the H264 streams. They didnt differentiate between MPEG2 and MPEG4, nevermind MPEG4 H264 L3 and L4.

Nothing can be played outside of on the box itself which holds the decryption key itself.

Apogee

From reading around a bit more, it would appear to be a fool's errand.

It looks as though both the HDR and the HD actually encrypt everything when recording. However, in the case of the HDR, when transferring material from internal HDD to USB stick, the HDR decrypts the SD material.

A good example of that is this thread, where they have put customised firmware which allows them to ftp to the HDR and HD. But in order to access unecrypted SD material on the HDR, you must first decrypt by putting material on USB (or internal partition) before ftping it across.
http://hummy.tv/forum/threads/customised-hdf-file-released.232/page-2#post-2611


In the case of the HD, the firmware has a bug so that nothing is ever decrypted. And I haven't seen any mention of third party cracks to get around this encryption either.

http://hummy.tv/forum/threads/hd-foxt2-transfer.35/#post-757

So the solution would appear to be to get a different box.

fat-tony

dmm1000 wrote: »

sure Tony - pm sent

and anyone else who would like to have a look at some recordings (.ts files) produced by the Humax HD Fox T2 receiver I can PM you the link where you can download them from - I know some of you may even actually enjoy looking at these things but I appreciate it requires use of your spare time

I concur with the other posters. All of the files are encrypted, including it seems, some of the header information so that it looks like there are lots of PIDs in the data stream. The rationale for encrypting material was to enforce a copying restriction on HD material on Freeview which the BBC had requested. On the Freesat recorder (Humax Foxsat HDR), the only files which are encrypted on the disk are those HD files recorded in Freesat mode, which the broadcaster has marked for copy protection. BBC 1 HD, was until recently, stored in the clear on the hard disk. Sometime in April BBC started setting the no copy flag and now it's encrypted. The terrestrial HD versions of the Humax receiver seem to have implemented the encryption in a blanket fashion which makes them unsuitable for anyone who wishes to move the files to other platforms for viewing. The Freesat EPG and the HD muxes of the Freeview platforms are compressed using proprietary Huffman tables which limits the ability to record from the EPG and series linking to boxes carrying the Freesat badge (or to specialist open-source boxes or PC platform applications). Seems a serious restriction on the genuine home user who wants to enjoy HD stuff on different kit in the home, when someone in the pirating business can just use a generic FTA satellite or terrestrial box to record and distribute HD streams:rolleyes:

dmm1000

thanks guys - so its the box itself then which encrypts everything
hummy.tv was the one site i neglected to browse - an alternative firmware might crop up there at some stage but i wont hold my breath
yes - time to consider a replacement box or just stick to using a USB tuner stick / PC for recordings for now ........

DeepBlue

Apogee wrote: »

Well, a quick Google throws up a major potential problem with this box:

Both the HD and HDR encrypt all SD and HD recordings on the drive used for recording. With the HDR you can copy SD recordings to an external drive and they are then unencrypted and can be played on a PC. With the HD it doesn't seem to unencrypt when copying to a second drive (this requires a powered USB hub as well) - I think this is a bug. In both cases you can't unencrypt HD recordings.

This may be worth investigating if you want to get HD recordings onto your PC.

STB

"Foxy does not decrypt HD video from the T2.
However, what it does do is enable the T2 to do this for you"


Clever guys over at Hummy and not just in the use of a turn of phrase. Handy link.

mgc102

Johnboy1951 wrote: »

said :
"I recorded from TG4 ...
That file will play in some media players but will for instance crash VLC. That is a problem I have been aware of for some time ..... VLC does not ...
I ran the file through ffmpeg to 'tidy-up' the m2t stream and VLC will play that readily."

reply :
I have a HDR-Fox T2. software version 1.02.20 (modified )


How did you run the program through ffmpeg. Did it take long to tidy?

On modified humax box there are options like dedup which when run through putty telnet from windows system can tidy up directory on humax file system.

If some one could write a similar package so ffmpeg tidys up the .ts files' m2t stream on box then VLC might play via the FTP server.

On XP and windows 7 (using XBMC) and via UPnP or FTP server I have been able to play .ts files from Freeview. (I am only receiving SD not HD yet). XBMC on windows does not recognise the format of saorview saved file but they are visible in the library. the humax is connected to my network by wifi.

I cant get VLC to ftp to the Humax and UPnP is not in the windows version of VLC. VLC will play the files if they are saved via USB.

I would be keen to get windows xp or windows 7 to recognise the saorview files via WIFI. Maybe use ffmpeg to "tidy up the m2t stream"? .

I have been able to record High Definition RTE2 program on HDR from saorview then move it to USB file and move it to Laptop with windows 7 and it plays seamlessly. (It is slow and jumpy if I play it on laptop direct from USB). This is using VLC on windows 7. XBMC on windows 7 recognises the file format and plays it when transfered via USB but doesnt recognise the format via UPnP connection direct to the Humax HDR.

I realise that to stream from my humax to router and then to laptop via wifi may be slowing the transfer causing a time out.

Gerry Wicklow

TSDOCTOR tidies up TS & TRP files in seconds. AFAIK it works with/creates M2TS also but haven't tried it myself.

Johnboy1951

I do not use Windows so cannot comment on what might be best for that, but here is (I hope) the command I last used.

/usr/bin/ffmpeg -i "<name of video file>.m2t" -acodec copy -vcodec copy -aspect 16:9 -r 25 -top 1 -flags +ildct+ilme -padtop 0 -padbottom 0 -padleft 0 -padright 0 -map 0.0:0.0 -map 0.1:0.1 -f mpegts "<name of video file>.ts"

The audio and video components are copied without change.
I have used 'map' to ensure I get the correct audio stream ... that may change or even be unnecessary I suppose, depending on the original ..... and then forced the use of mpegts format.

No doubt there are better commands for the job, as I am not very familiar with ffmpeg options .....

Kaffeine records in .m2t format and it was to convert those files (VLC would not play them) that I used this.

regards

mgc102

Johnboy1951 wrote: »

The audio and video components are copied without change.
I have used 'map' to ensure I get the correct audio stream ... that may change or even be unnecessary.

From looking at the data before and after it looks like you did change the audio components.

The saorview signal has stream 0.0 video 0.1audio stereo 0.2 audio mono and text (programe info and channel guide info. When you copied and removed all but video and audio stereo streams this allowed VLC to play the file.

I too am unfamiliar with ffmpeg.
I tried to copy mpegts to mpegts with streams 0.0 and 0.1 only, but couldnt do it.

Was there any difference in how the files thumbnail appeared before and after the copy?

I have the customised firmware on the Humax HDR-T2. SD and HD files from freeview and saorview can be moved to USB and then viewed in XBMC or VLC on windows. In XBMC The saorview thumbnail is the first frame of the recording while the freeview thumbnail is a generic icon of moviefilm roll. Would the thumbnail type/appearance be why Freeview SD programs stream ok via XBMC/UPnP but saorview dont?

Johnboy1951

The saorview signal has stream 0.0 video 0.1audio stereo 0.2 audio mono and text (programe info and channel guide info. When you copied and removed all but video and audio stereo streams this allowed VLC to play the file.

You could try playing with a short clip to see what happens. For instance this will work ...

ffmpeg -i <inputfile> -f mpegts  <outputfile>

If the audio channel you wish to retain is the same as the default then all will be OK ..... else you would need to map the audio channel you wish to keep.

Seems the '-f mpegts' format does not retain the extra streams, and the file does play in VLC.

So the simplest command that worked here is

ffmpeg -i <inputfile>  -map 0.0:0.0 -map 0.1:0.1 -f mpegts <outputfile>

Would the thumbnail type/appearance be why Freeview SD programs stream ok via XBMC/UPnP but saorview dont?

I would think it has no effect ... thumbnails, as far as I am aware, are generated by the OS and are not part of the file.

regards.