Black Hole
May contain traces of nut
Currently unreviewed. Please report errors.
This section of the forum is for discussion of file manipulation in general, not specific to any particular Humax (or other) recorder. Naturally, being on this forum, by and large the source of the video/audio files will have been a Humax recorder.
For a recording originating from a PVR of some sort, the first issue is to ensure the recording file (probably a .TS) is not encrypted. If you don't know whether it is, the easy way to check is to try playing the file using VLC. I recommend VLC because it is a free download available for most operating systems and hardware, and is able to handle just about any media file thrown at it. If VLC won't play a PVR file, chances are the file is encrypted (ie locked to the recorder which recorded it), or damaged in some other way.
Check the relevant forum section for details how to ensure recordings exported from your particular hardware is not encrypted. In some cases, this is only possible for StDef recordings (not HiDef), and in some instances is not available at all. Encryption can be disabled entirely on Foxsat-HDR by application of a firmware patch; HDR-FOX can export StDef recordings decrypted as standard, and modified to decrypt HiDef recordings; HD-FOX can be modified to decrypt all recordings.
Usually, somebody will complain that some software or other that they want to use to edit some video (or whatever) won't take .TS as input. There could be several reasons for that, not necessarily because the software in question doesn't literally take .TS:
HOWEVER: not all codecs are compatible with all containers. You could not, for example, re-mux a .MP4 with the H.264/AVC video codec into a .MPG container.
The process of changing codec is called re-encoding. You should always try to avoid re-encoding, because a) it loses quality (ie it's "lossy"), and b) it is slow depending on hardware. Re-encoding audio isn't too bad from either point of view, and can be done on (eg) HDR-FOX hardware, but you really want to avoid re-encoding video if at all possible (and definitely not on an HDR-FOX, which simply doesn't have sufficient RAM let alone processing power).
All that said, suppose you've made sure the recording is not encrypted, and changing the file extension to .m2ts hasn't solved the problem, what to do?
You could go googling for a fancy package which might or might not do what you want, or you could do what the geeks do and reach for FFMPEG. It's free, it does everything you are ever likely to want, it is in active development so even if it doesn't do it now you can put in a request to get it done, and it is available for practically every hardware platform and operating system. The minor downside traded for this flexibility is that FFMPEG is a command-line tool (DON'T BAULK!).
All that means is you have to open a command console in Windows, Linux, or whatever, and type your commands in like we always used to. So what? You really ought to be able to do that anyway, and you don't have to know what you're doing so long as you can copy-and-paste. Once you have a command or series of commands which you often use to achieve some particular repetitive task, it's easy enough to capture those commands in a .bat (Windows) or shell script (Linux) to run automatically.
<work-in-progress> Compatibility Table of Containers and Codecs </work-in-progress>
Identifying File Contents
There are various ways of detecting the contents of media files. VLC has a Properties menu tool for inspecting files, or there is the popular Mediainfo extension for the Windows (and Linux?) file explorer. However, along with FFMPEG comes FFPROBE and FFPLAY. FFPLAY is a media player, and I won't discuss it further – have a toy with it if you like and/or need a media player you can launch from the command line, but it obviously won't work on the HDR-FOX/HD-FOX command console.
FFPROBE provides the means to inspect media files on the command line, and if...
...produces no output (other than an end-of-input notification), you can be sure the file is either not a media file or is encrypted.
What you get out of FFPROBE for a decrypted recording from HDR-FOX/HD-FOX is a catalogue of all the (many) streams within the TS (M2TS) including broadcast baggage, so much of it can be ignored.
To run any of these commands, the executable (ffmpeg.exe, ffprobe.exe) must be on the command search path. For Windows, the easy way to do this is to have the executable in the same directory as the working files. This is less straightforward in Linux, because the current directory is not automatically on the command search path. Either way, it would be ideal to install ffmpeg.exe in the system directories so that it is available on the command line everywhere. Google it for your particular OS. FFMPEG and FFPROBE are already available on the command path in the WebIF command console.
The remainder of this 101 is a list of FFMPEG commands to achieve a variety of tasks.
FFMPEG Cook-Book
In the examples below, strings contained in angle brackets "<...>" are place-holders representing user input which will alter according to circumstances. Instead of typing that string explicitly, the user must substitute their own text, eg the filename of the video data they are trying to process:
Some command switches for FFMPEG are ubiquitous, and described here rather than frequently in the command examples:
1. Change the Container Format Without Re-Encoding
FFMPEG auto-detects its input and doesn't have to be told what it is (except by file extension). It also assumes which output format to use from the output file extension. The only remaining element required is to tell it to copy the streams in the input container to the output container:
Example:
<work-in-progress>
This section of the forum is for discussion of file manipulation in general, not specific to any particular Humax (or other) recorder. Naturally, being on this forum, by and large the source of the video/audio files will have been a Humax recorder.
For a recording originating from a PVR of some sort, the first issue is to ensure the recording file (probably a .TS) is not encrypted. If you don't know whether it is, the easy way to check is to try playing the file using VLC. I recommend VLC because it is a free download available for most operating systems and hardware, and is able to handle just about any media file thrown at it. If VLC won't play a PVR file, chances are the file is encrypted (ie locked to the recorder which recorded it), or damaged in some other way.
Check the relevant forum section for details how to ensure recordings exported from your particular hardware is not encrypted. In some cases, this is only possible for StDef recordings (not HiDef), and in some instances is not available at all. Encryption can be disabled entirely on Foxsat-HDR by application of a firmware patch; HDR-FOX can export StDef recordings decrypted as standard, and modified to decrypt HiDef recordings; HD-FOX can be modified to decrypt all recordings.
Usually, somebody will complain that some software or other that they want to use to edit some video (or whatever) won't take .TS as input. There could be several reasons for that, not necessarily because the software in question doesn't literally take .TS:
- The input file is encrypted. See above.
- The ".TS" files from Humax PVRs are not, actually, TS. They are correctly described as M2TS. You could try renaming the file to have the .m2ts extension rather than just .ts, and try it again. By the same token, if you are trying to prepare a file to put on the PVR and have it play, you will need to output an M2TS format file, and then rename it .ts.
- Media files such as PVR recordings are what we call "containers" within which are at least one video stream and one audio stream. This sounds more complicated than it needs to be, but actually it provides an overall mechanism for synchronising (potentially) video from multiple points-of-view, multiple sound tracks (including surround sound), foreign language dubs, subtitles, whatever. Not infrequently, if a media player shows the video but no sound, it's because there is another audio stream in the file and the player has picked up the wrong one.
Practically all the media files you might have heard of: .TS, .MPG, .MP4, .MKV... are actually the containers, and their specification describes the technicalities of how the streams within them get accessed.
- Within the TS (or any other) container, the video and audio streams have their own separate codecs. Not only does the target software have to understand the container, it also has to understand the video and audio codecs. It is entirely possible that the software does read TS, but does not (for example) understand the H.265 video codec. So you must ensure the content as well as the container is compatible with your software.
- A TS recorded from broadcast may contain multiple streams which confuse the software.
HOWEVER: not all codecs are compatible with all containers. You could not, for example, re-mux a .MP4 with the H.264/AVC video codec into a .MPG container.
The process of changing codec is called re-encoding. You should always try to avoid re-encoding, because a) it loses quality (ie it's "lossy"), and b) it is slow depending on hardware. Re-encoding audio isn't too bad from either point of view, and can be done on (eg) HDR-FOX hardware, but you really want to avoid re-encoding video if at all possible (and definitely not on an HDR-FOX, which simply doesn't have sufficient RAM let alone processing power).
All that said, suppose you've made sure the recording is not encrypted, and changing the file extension to .m2ts hasn't solved the problem, what to do?
You could go googling for a fancy package which might or might not do what you want, or you could do what the geeks do and reach for FFMPEG. It's free, it does everything you are ever likely to want, it is in active development so even if it doesn't do it now you can put in a request to get it done, and it is available for practically every hardware platform and operating system. The minor downside traded for this flexibility is that FFMPEG is a command-line tool (DON'T BAULK!).
All that means is you have to open a command console in Windows, Linux, or whatever, and type your commands in like we always used to. So what? You really ought to be able to do that anyway, and you don't have to know what you're doing so long as you can copy-and-paste. Once you have a command or series of commands which you often use to achieve some particular repetitive task, it's easy enough to capture those commands in a .bat (Windows) or shell script (Linux) to run automatically.
<work-in-progress> Compatibility Table of Containers and Codecs </work-in-progress>
Identifying File Contents
There are various ways of detecting the contents of media files. VLC has a Properties menu tool for inspecting files, or there is the popular Mediainfo extension for the Windows (and Linux?) file explorer. However, along with FFMPEG comes FFPROBE and FFPLAY. FFPLAY is a media player, and I won't discuss it further – have a toy with it if you like and/or need a media player you can launch from the command line, but it obviously won't work on the HDR-FOX/HD-FOX command console.
FFPROBE provides the means to inspect media files on the command line, and if...
ffprobe <input.ext> -hide_banner...produces no output (other than an end-of-input notification), you can be sure the file is either not a media file or is encrypted.
What you get out of FFPROBE for a decrypted recording from HDR-FOX/HD-FOX is a catalogue of all the (many) streams within the TS (M2TS) including broadcast baggage, so much of it can be ignored.
To run any of these commands, the executable (ffmpeg.exe, ffprobe.exe) must be on the command search path. For Windows, the easy way to do this is to have the executable in the same directory as the working files. This is less straightforward in Linux, because the current directory is not automatically on the command search path. Either way, it would be ideal to install ffmpeg.exe in the system directories so that it is available on the command line everywhere. Google it for your particular OS. FFMPEG and FFPROBE are already available on the command path in the WebIF command console.
The remainder of this 101 is a list of FFMPEG commands to achieve a variety of tasks.
FFMPEG Cook-Book
In the examples below, strings contained in angle brackets "<...>" are place-holders representing user input which will alter according to circumstances. Instead of typing that string explicitly, the user must substitute their own text, eg the filename of the video data they are trying to process:
<input> – place-holder for the input filename (without extension)
<input.ext> – place-holder for the output filename including the extension
<output> – place-holder for the output filename (without extension)
<output.ext> – place-holder for the output filename including the extension
Often, the TAB key provides auto-completion on the command line (which saves typing errors). For example: if there is an input file "this is my video input file.ts", then typing just "t" followed by TAB will step through all the files which begin with "t", and include any quoting required (because of the spaces). You can even press TAB on its own to step through all the files in the current directory. The HDR-FOX/HD-FOX WebIF command line requires enough characters to identify a set of files, and then TAB auto-completes only the characters the files have in common and then you might have to enter some more (and try TAB again).Some command switches for FFMPEG are ubiquitous, and described here rather than frequently in the command examples:
-i – Tells FFMPEG that the next string is the input. There may be several inputs, in which case a -i must prefix each one.1. Change the Container Format Without Re-Encoding
FFMPEG auto-detects its input and doesn't have to be told what it is (except by file extension). It also assumes which output format to use from the output file extension. The only remaining element required is to tell it to copy the streams in the input container to the output container:
ffmpeg -i <input.ext> -codec copy <output.ext>-codec copy tells FFMPEG to copy the streams from the input to the outputExample:
ffmpeg -i "my video file.ts" -codec copy output.mp4
This command converts "my video file.ts" to "output.mp4". The input file name is in quotes because it contains spaces. No re-encoding of the streams. Only the first video and audio streams are included in the output, so all the broadcast dross from a recording is stripped.
<work-in-progress>
Last edited: