0

I have a collection of videos stored in various multimedia containers such as AVI, MP4, MKV, etc. and would like to determine what container I could store them in without re-encoding (to avoid quality loss). I would like to use avconv to rapidly copy the streams directly to the new container format, as in avconv -i <input-file> -c:a copy -c:v copy <output file>. Has anyone done any testing to determine container efficiency?

For clarity I'm talking about multimedia containers such as AVI, Matroska, etc. and not codecs as I would prefer not to re-encode.

Edit: To further clarify by "container efficiency" I mean a container with a minimum of overhead (wasted bytes used by the container framework).

muru
  • 197,895
  • 55
  • 485
  • 740
Elder Geek
  • 36,023
  • 25
  • 98
  • 183

1 Answers1

0

For a test case I downloaded a copyright free video via torrent(Destroy All Planets) from The Internet Archive. As it contained a number of files in different multimedia containers at different bitrates I chose the highest quality version which was Destroy_All_Planets.mpeg which was 720x480 at 30 fps and a MPEG2 video stream with a variable video bitrate of ~3000 kbps (6000 kbps max per mediainfo and a AC-3 audio stream sampled at 48000 Hz with bitrate of 192 kbps. I attempted conversion to all the multimedia container types I could find. using the command avconv infile -c:a copy -c:v copy outfile The AVI attempt appears to have defaulted to uncompressed and was clearly re-encoded (or unpacked) as there was a substantial increase in size and an adjustment to 90fps with a bitrate of 15.9 Mbps. Several other containers failed to accept the data input and can be seen in the results with a 0 file size. According to the results of this test MP4 and MOV containers appear to be the most efficient (tied for 1st place) with the Matroska container a solid 3rd place finish. All other multimedia containers tested resulted in an actual increase in size over the source material.

11036656 Destroy_All_Planets.avi

 2287920 Destroy_All_Planets.ts

 2140308 Destroy_All_Planets.asf

 2140308 Destroy_All_Planets.wmv

 2106300 Destroy_All_Planets.mpeg

 2103940 Destroy_All_Planets.mkv

 2103404 Destroy_All_Planets.mov

 2103404 Destroy_All_Planets.mp4

       0 Destroy_All_Planets.3g2

       0 Destroy_All_Planets.3gp

       0 Destroy_All_Planets.flv

       0 Destroy_All_Planets.mxf

       0 Destroy_All_Planets.ogg

       0 Destroy_All_Planets.webm

In the interests of full disclosure it should be noted that in this case conversion to mkv also failed and I got the error Can't write packet with unknown timestamp I resolved this problem before on other files by adding -fflags +genpts before the input file which is the workaround outlined here. In this instance it resulted in a playable file which no player I tried was able to determine the duration of. Converting the previously converted mp4 to mkv worked fine in this instance. Another test resulted in the following results:

3129112 disorder_in_the_court.avi
 623632 disorder_in_the_court.ts
 583424 disorder_in_the_court.mpeg
 575288 disorder_in_the_court.mov
 575288 disorder_in_the_court.mp4
 575224 disorder_in_the_court.mkv

The previous test included an mpeg with subtitles, this one did not have embedded subtitles and the Matroska container came out with the smallest file size. It also has the benefit of being the most flexible of the containers tested allowing for virtually any video, audio, or subtitle format currently available.

Community
  • 1
Elder Geek
  • 36,023
  • 25
  • 98
  • 183
  • https://archive.org/details/DestroyAllPlanets_208 or https://archive.org/details/Destroy_All_Planets? – muru Nov 18 '15 at 01:45
  • @muru the latter – Elder Geek Nov 18 '15 at 01:55
  • When you get the time, do go through the revision history of your post. – muru Nov 18 '15 at 02:01
  • the two edits I made, I suppose. – muru Nov 18 '15 at 02:07
  • what for? You overwrote both of them. – muru Nov 18 '15 at 02:08
  • Let us continue this discussion in chat. – Elder Geek Nov 18 '15 at 02:10
  • So, basically all containers are quite close in size except avi and ts. Well, avi is Microsoft, so what do you expect (just kidding, have no idea what's going on). But ts is MPEG Transport Stream and contains additional error correction and stream synchronization features to maintain transmission integrity when the signal is degraded. – Germar Nov 18 '15 at 03:19
  • @Germar Indeed they are close, at least with avconv. whether that's significant or not depends on the quantity of files being considered. It does seem clear that the error prevention technique used by .ts would add significantly to the overhead. There's an interesting graphics depicting AVI structure here: http://yaai.sourceforge.net/yaai/fileformat.html but it doesn't appear to explain why the AVI files generated by avconv are so large. – Elder Geek Nov 18 '15 at 13:40