- This topic has 71 replies, 3 voices, and was last updated 4 years, 9 months ago by
.
-
Posts
-
Just remembered how easy it used to be to extract .ts files from my old Thomson DHD4000 and then simply rename to .mpeg and it becomes playable via VLC on a PC with no transcoding needed.
Tried the same today using the FTP option to download a couple of films from Film4 as .ts files that hadn’t been transcoded and guess what? They play fine with VLC on a PC when renamed to .mpeg
I also used to take advantage of the “no transcoding needed” to turn such SD broadcasts quickly into DVDs for personal use (e.g. I had all of the “Something Special” episodes recorded for my SEN son).
Just something to bear in mind if you want to easily extract non-HD broadcasts for archival. Probably not news to anyone really, but just in case it is…
Filezilla (on laptop) using the FTP server that was added in the latest release.
Tried a few different SD channels with the same level of success, so I presume SD remains broadcast in Mpeg2. Not even tried with HD as I’d presume encryption would make that a non-starter.
Would work at command line too of course.
larkim – 15 mins ago »
Filezilla (on laptop) using the FTP server that was added in the latest release.
Tried a few different SD channels with the same level of success, so I presume SD remains broadcast in Mpeg2. Not even tried with HD as I’d presume encryption would make that a non-starter.
The files that I have downloaded are encoded with H264/AVC and AAC audio.
I have tried every combination in Filezilla. Can you please post an eaxmple omitting your local IP address
I presume the password is 0000. Is the name Humaxftp ?
Are you downloading from SD channels only? Accessed via aura:0000 on port 2323, downloading from the file tree which is /Recordings/ByChannels/014_Film4 for example.
IP address is the “normal” one – 192.168.1.1xx in my case
larkim – 9 mins ago »
IP address is the “normal” one – 192.168.1.1xx in my case
That has always worked. The FTP server was added in the latest update. It’s the box web interface html server.
No need to change anything. VLC will play the transport stream container as is.
Also plays from a usb stick with a otg adaptor on saMsung phone and tablet.
Full container details downloaded from BBC1-HD recording.
General
ID : 0 (0x0)
Complete name :
DownloadsAntiques Road Trip (2).tsFormat : MPEG-TS
File size : 753 MiB
Duration : 44 min 41 s
Overall bit rate mode : Variable
Overall bit rate : 2 356 kb/s
Video
ID : 100 (0x64)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, RefFrames : 2 frames
Frame mode : Frame doubling
Format settings, GOP : M=1, N=30
Codec ID : 27
Duration : 44 min 39 s
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Audio
ID : 200 (0xC8)
Menu ID : 1 (0x1)
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 2
Format profile : LC
Muxing mode : ADTS
Codec ID : 15
Duration : 44 min 38 s
Bit rate mode : Variable
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
larkim – 20 mins ago »
Are you downloading from SD channels only? Accessed via aura:0000 on port 2323, downloading from the file tree which is /Recordings/ByChannels/014_Film4 for example.
HD – 1080p/1080i is rescaled to 720 x 576 using the much more efficient H24/AVC codec.
The box has to transcode Live HD TV on the fly so that you can watch the HD channels in the Aura app.
Aha, I see what you’re getting at. I may have ignored what actual codec was in use, so where I’ve said mpeg2 it might well be H264 with AAC. The last time I did anything from a transport stream was about 10-12 years ago so if the broadcast standard has shifted from mpeg2 for SD channels too then that’s my error. I’ve deleted the files already so will redownload and confirm what type of file I’m seeing. I suspect you’re right that the file extension is irrelevant, that used to be a step that was probably necessary for an older clunky piece of software that i was using to force it to recognise what was inside the container.
Think we’re at cross purposes here.
I’m talking solely about downloading un-transcoded recordings which are generated only from SD channels and then those channels being immediately playable locally on a PC or other device without any fresh transcoding being needed. It may be that that same file can be transcoded without much (or any) noticeable loss into H264, and thus reduce file size significantly but I’m not interested in that.
Given the encrypted nature of HD broadcasts I never had any expectation that those recordings could be lifted off the box in their original format, and therefore transcoding on the box would always need doing.
I’ll confirm the stream formats in a while when I’ve got some time to ftp across SD channel recordings and then identify the codecs via VLC or similar.
larkim – 11 mins ago »
Aha, I see what you’re getting at. I may have ignored what actual codec was in use, so where I’ve said mpeg2 it might well be H264 with AAC. The last time I did anything from a transport stream was about 10-12 years ago so if the broadcast standard has shifted from mpeg2 for SD channels too then that’s my error. I’ve deleted the files already so will redownload and confirm what type of file I’m seeing. I suspect you’re right that the file extension is irrelevant, that used to be a step that was probably necessary for an older clunky piece of software that i was using to force it to recognise what was inside the container.
SD channels still use mpeg2 for Video compression and mpeg1 layer 2 for audio.
Humax boxes have always used transport stream as the container. For HD channels , the actual video is M2ts (as used on bluray. Same on satellite HD sources.
Far too much legacy kit to change to H264.
OK then.
So back to where I started, if a user uses the FTP protocol to download a file from the box, users can be confident that the files are playable and require no transcoding if the recording was made on a non-HD channel.
I presume you can see that from your end too?
larkim – 4 mins ago »
OK then.
So back to where I started, if a user uses the FTP protocol to download a file from the box, users can be confident that the files are playable and require no transcoding if the recording was made on a non-HD channel.
I presume you can see that from your end too?
I have not been able to use the FTP protocol.
Tried adding it to Filezilla site manager without success.
Guessing it’s used to download recordings to mobile devices using the aura app. I downloaded one to my tablet as a test.
The tablet reports the .ts and a .jpg thumbnail image downloaded.
But they are hidden so no way to tell what the format bitrate etc is.
The new software has options for the transcoding bitrate. But setting a higher one does not seem to make much difference at least using the box webserver.
Daft question, but have you enabled the FTP server in the settings following the most recent FW update?
- You must be logged in to reply to this topic.