Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Newbies

Reply
 
Thread Tools Search this Thread Display Modes
Old 21st June 2017, 01:04   #1  |  Link
Moppelkotze
Registered User
 
Join Date: Jul 2012
Posts: 42
Avidemux ok for concatenating mts snipets to one big file? If so, *ts or *ps?

Hello,

some time ago I was told that I could use Avidemux to "glue together" my *mts files from my PVR.

It records episodes/movies in chunks of 10min. or 536,7MB. When I then put them on my computer, I put the parts together with Avidemux to have one big file and usually there is no video/audio being out of sync.

Lately I wondered, what would be better to use as target format. *ts or *mpeg (*ps), Avidemux doesn't offer *mts/*mps. Also I don't want to convert them, I just want to have the snipets as one file.

I know that *ts is for sending movies via broadcasting and *ps is for playback on e.g. DVDs.

I wonder, if I should save the files as *ts to have sort of the original file or save them as *ps to make them moe "common", but maybe loose some additional info.

I notice that the resulting files are of different size. I'd like to know, if I can go wrong one way or the other.

Someone told me Avidemux was no solution, it couldn't do it right anyway and I needed something like the app VideoRedo.

Any input on?
- if I can go on using Avidemux to concatenate the snipets
- if TS or PS should be preferred


Btw. some of the sources are h.264 (HD satelite streams) and some are mpeg2 (SD satelite streams). I was also thinking of using a rewrapper and wrap them as .mov to make them more "universal/common". I am not sure though, if I can concatenate files whit a rewrapper at the same time.
Moppelkotze is offline   Reply With Quote
Old 21st June 2017, 01:57   #2  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 182
You can use MKVToolNix to remux them to Matroska. It's free and very stable. You can get it from here. To do this, just add the first file of every set of files that belong together, then right click on that source file (in MKVToolNix's list of source files) and click on "Add as additional parts" (do not use the "append" function; the difference between these two is explained here). Then add the the other files (in the correct order). Then you can remux the file. You can also deselect some tracks so that they won't be muxed (often broadcasts contain e.g. an ac-3 stream and an mp2 stream with the same sound (just in lower quality) for backward-compability; and sometimes there is an audio track explaining what happens for the visually impaired) and you save space.
Broadcasts sometimes include filler bytes which will be stripped away by MKVToolNix during remuxing. If your recordings contain them, the remuxed files can be significantly smaller than the source files. Even if they don't, they will be smaller because Matroska has way less overhead than m2ts with its small packet size. You can also cut your recordings, but only keyframe-accurately.
During this process you loose the teletext (if your source files contained them). I don't know if you care about this.
mkver is offline   Reply With Quote
Old 23rd June 2017, 15:22   #3  |  Link
Moppelkotze
Registered User
 
Join Date: Jul 2012
Posts: 42
Thank you!

Just, so I understand you correctly, that method would leave me with a file, that is not altered in quality (no compression or re-encoding like from mpeg2 to x264-mp4).

I will learn to use the recommended tool, however, since I have Avidemux already, can I assume that Avidemux is not able to do the task as properly? (It is also not able to leave out the filler bytes and extra audio tracks, as far as I know, or have I overlooked something?).

PS: what purpose do filler bytes have in broadcasting? I found something about "zero byte stuffing", but didn't get far via a first google search. However I read earlier (in another forum) that such bytes exist in TV streams and one could omit them, but hadn't looked into it back then.

Last edited by Moppelkotze; 23rd June 2017 at 15:26.
Moppelkotze is offline   Reply With Quote
Old 23rd June 2017, 21:36   #4  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 182
Yes, MKVToolNix doesn't do reencoding. It is simply a muxer.
I usually don't use Avidemux, but I just tried it out: After I split a transport stream with a non-video tool (a tool (7-zip) that doesn't cut right at keyframes, but just cuts somewhere (possibly in the middle of a frame)), Avidemux created a file that is damaged at the split point. So it's not safe to use Avidemux to join these files.
Some ways of distribution (satellite TV in particular) need to maintain a constant bitrate; I don't know the exact technical reasons for this, but that's the way it is. (Think of it another way: These filler bytes are just a burden for someone who wants to recode, not for the broadcaster (from the point of view of the broadcaster, bitrate not used would be bitrate wasted, because you can't save the space/bitrate at all). The broadcasters might have an incentive to use all available bitrate (to increase quality), but they have no incentive to send a variable bitrate signal (instead of a signal that has a constant bitrate because of filler bytes) when they don't use all the available bitrate.) And if your encoder produces streams with a too low bitrate, you fill it up with filler bytes. (Actually, it's the transponders (usually several channels share a transponder) that need to maintain a constant bitrate; the distribution of said bitrate to the individual channels can change over time to improve the quality. As your nickname suggests that your streams might come from German TV, I will share some experience with you: The HD-ARD-channels (not only Das Erste, but also HR, BR, NDR, RBB...) use filler bytes in their satellite broadcasts; ZDF HD (and ZDF Neo HD) and KIKA HD does not. I don't know about the non-public broadcasters. Neither MKVToolNix nor Avidemux can work with encrypted files anyway.)
By the way, it might be that your PVR has already stripped these filler bytes out. In this case the filesize savings from remuxing is not so big, but still substantial.
mkver is offline   Reply With Quote
Old 26th June 2017, 21:55   #5  |  Link
Moppelkotze
Registered User
 
Join Date: Jul 2012
Posts: 42
Thank you! Also for sharing your experience with German public TV streams.

I got the impression that the audio of those is almost always 192kbps mp2 and something arround 400kbps for AC3. Which audio tracks do you usually keep from ARD, ZDF, Die Dritten, arte etc.? I plan to keep the *mts files as muxed mkv files first and maybe sometime later encode it with Handbrake to an even smaller file. Since Handbrake won't let one keep mp2 audio, I can either convert mp2 audio to mp3/AAC/etc. or passthrough the AC3 audio. The question is also what (mp2 or AC3) is offering more source when one plans to re-encode it to e.g. AAC. Maybe I just keep both: one mp2 and one AC3 track in the mkv file and decide later when I convert with Handbrake sometime in the future.

Btw. as a container, are both .mkv and .mp4 as universallly compatible as the other with different devices? I know I can only produce mkv with MKVToolNix, but nevertheless I am curious.

PS: regarding Avidemux, you wouldn't need to cut with 7-zip first. Avidemux cuts at the nearest i-frame, to where you set the A- and B- marker. You then can choose copy for the video and audio output and choose the container output format, TS (SD and HD) or PS (only SD) and of course others, but those where not in question right. I would be interested to know, if you get a damaged file then, too. It works for public TV content, I had mixed experiences with private TV content.
Moppelkotze is offline   Reply With Quote
Old 27th June 2017, 02:55   #6  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 182
The ac-3 stream is usually the stream with the highest quality. If the broadcast comes with 5.1 audio, only the ac3-stream is 5.1, the others are still stereo. Besides the size and quality of the stream there are two more things to consider: The ac-3 stream is usually stereo and only 5.1 when the broadcast is actually 5.1 (exception: ARTE HD (the German version) is always 5.1 (upconverted if it's not originally 5.1)). The switch from stereo to 5.1 usually happens during the first second or so of the show, but during the show. So during reencoding the stream might be wrongly detected as stereo. I don't know what happens then. (does it mix all the channels to stereo and encodes this? Does it just use the front channels? Does it abort?) Furthermore, some shows (modern ones more often than older ones) feature audio description for the visually impaired. In order to inform the audience of this option, the ARD broadcasters include a sound at the beginning in their normal audio tracks; only the audio description track doesn't feature it, because those who use this track already use the said audio description. If you are very thorough, you could therefore try to replace the sound at the beginning with the audio description track. But if you do this, you would have to do it manually; and Handbrake wouldn't need to be enough. IMO, it's not worth it and I would retain the ac-3 track.
By the way, it might be that Handbrake will soon get the ability to do mp2 passthrough.
Today, compability with mkv and mp4 is good. If you want to know the behaviour of a specific device, you should explicitly test it.
Matroska is an open standard. It is not a proprietary format that only MKVToolNix can produce. ffmpeg and its derivatives (Handbrake and Avidemux are among them) can produce these files, too. (ffmpeg has a "concat"-option to treat multiple files as one big file, too.)
If one wants to test Avidemux' behaviour regarding files which have been arbitrarily split, one needs to feed such files to it; so I needed to split it first. Testing how it behaves with ordinary split/marker points doesn't help here.
mkver is offline   Reply With Quote
Old 5th July 2017, 01:54   #7  |  Link
Moppelkotze
Registered User
 
Join Date: Jul 2012
Posts: 42
Thanks again for your answers.

I stumbled upon a post in a thread that said .mkv had the disadvantage of "Lack of hw accelerated playback, so it's a big drain on battery, on my 2012ish MBP [MacBook Pro]".

Should I better wrap the mpeg2 transport stream in a mp4 container?


Regarding Avidemux: ok, I understand you would do that to see, if it can "heal" broken files, but if the PVR created the snipets, shouldn't they be OK anyway and the question would more be, if Avidemux can create one "healthy" BIG file out of the snipets, when oneself only cut out commercials in Avidemux at i-frames? Sorry, I know this question is academic now.
Moppelkotze is offline   Reply With Quote
Old 5th July 2017, 08:07   #8  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 182
1. Of course one can use HW accelereated playback with videos inside a Matroska container! After all, it's the same video, just in a different container. But after a little Googling I found that Apple's QuickTime player (the default player on a Mac) can't handle Matroska natively (there seems to be a plugin (Perian) for that, but it's no longer supported); so most people on a Mac who play Matroska files play them with VLC which does not seem to be as good as QuickTime in making use of hardware acceleration on a Mac. This is a limitation of QuickTime and VLC, not of Matroska itself. If you don't use a Mac, you can ignore it.
2. You could use an mp4 container; but you should know that ffmpeg (which has a concat feature which allows it to read multiple files as if it were one) does not strip filler bytes out. I would stick with MKVToolNix/Matroska.
3. The files actually aren't broken in the sense of defective (well, hopefully not -- you can always have transmission errors which end up in your recording). The files created by the PVR are (hopefully) ok, but they would be mishandled by Avidemux. The files created by Avidemux would not be OK anyway precisely because Avidemux does not create one healthy big file out of the snippets.
4. Have you actually tried it yet?
mkver is offline   Reply With Quote
Old 18th July 2017, 23:03   #9  |  Link
Moppelkotze
Registered User
 
Join Date: Jul 2012
Posts: 42
Sorry, dass ich immer noch nicht geantwortet habe, die letzte Zeit ist am Ende vom Tag so wenig Zeit übrig. Aber, um mich wenigstens zu melden: nein, ich habe es noch nich ausprobiert, weil ich dass soweit ich bei einem ersten Blick sehen konnte für Mac kompilieren müsste und da muss ich erst mal in Ruhe draufgucken.
Moppelkotze is offline   Reply With Quote
Old 19th July 2017, 17:58   #10  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 182
What's wrong with the Mac binaries provided by the author? Or haven't you checked them?
mkver is offline   Reply With Quote
Old 21st July 2017, 15:48   #11  |  Link
Moppelkotze
Registered User
 
Join Date: Jul 2012
Posts: 42
I saw that there are three Mac OS options in yor very first link to MKVToolNix that you posted above in this thread, but I thought, before I start this and just download it, install it and take a quick look and then see, that I have to do it in a quiet moment, I better start doing this concentrated from the beginning and do it later.
So I somehow expected, it could take more time and didn't want to try it, yet only to fail and get frustrated.

I promise, I will do somewhen in the next two weeks. There is just so much other things to do.
Moppelkotze is offline   Reply With Quote
Old 21st July 2017, 23:22   #12  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 182
Ok. If you test it, you should do it with the very latest version; currently, this is a pre-build available here.
mkver is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:37.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.