Remuxing mpegts results in 5% bigger file size than original file

[DavJames]

Summary of the bug: Muxing results in bigger file size than original file

How to reproduce: Created a Mux.bat file as below and put it in the Windows Send To folder. Right-clicked a TS file and selected Send To "Mux.bat" file.

The resulting file created is larger than the original. That shouldn't happen. I once had a 22.4GB file and after Muxing it was 1GB larger!

"X:\Portable Installations\ffmpeg-2014 May 14-git-72dcd48-win64-static\bin\ffmpeg.exe" -i %1 -vcodec copy -acodec copy "%~d1%~p1%~n1.copy.ts"

FFmpeg version: 2014-05-13 git-72dcd48

[Carl Eugen Hoyos]

Please provide your command line, the complete, uncut console output and a small sample to make this a valid ticket.

[DavJames]

Don't know what you mean by command line - what's the difference between that and the console output?

Sample is here: ​https://www.dropbox.com/s/mdpacs3iqnz9ztl/FFmpeg%20Sample.ts

Here's the cmd output:

E:\2 = New>"X:\Portable Installations\ffmpeg-2014 May 14-git-72dcd48-win64-stati
c\bin\ffmpeg.exe" -i "E:\2 = New\FFmpeg Sample.ts" -vcodec copy -acodec copy "E:
\2 = New\FFmpeg Sample.copy.ts"
ffmpeg version N-63113-g72dcd48 Copyright (c) 2000-2014 the FFmpeg developers

built on May 12 2014 22:10:08 with gcc 4.8.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av

isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetyp
e --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --ena
ble-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-l
ibopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libsp
eex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aa
cenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavp
ack --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable
-decklink --enable-zlib

libavutil 52. 83.100 / 52. 83.100
libavcodec 55. 61.100 / 55. 61.100
libavformat 55. 37.102 / 55. 37.102
libavdevice 55. 13.101 / 55. 13.101
libavfilter 4. 5.100 / 4. 5.100
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 18.100 / 0. 18.100
libpostproc 52. 3.100 / 52. 3.100

Input #0, mpegts, from 'E:\2 = New\FFmpeg Sample.ts':

Duration: 00:02:26.39, start: 0.200000, bitrate: 16292 kb/s
Program 1

Stream #0:0[0x201]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv,

bt709), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc

Stream #0:1[0x202]: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, f

ltp, 229 kb/s
Output #0, mpegts, to 'E:\2 = New\FFmpeg Sample.copy.ts':

Metadata:

encoder : Lavf55.37.102
Stream #0:0: Video: h264 ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1

:1 DAR 16:9], q=2-31, 25 fps, 90k tbn, 25 tbc

Stream #0:1: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, 229 kb/s

Stream mapping:

Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)

Press [q] to stop, ? for help
frame= 5945 fps=0.0 q=-1.0 size= 255805kB time=00:01:58.72 bitrate=17651.3kbits
[mpegts @ 0000000005d34020] Non-monotonous DTS in output stream 0:0; previous: 1
3154401, current: 13154401; changing to 13154402. This may result in incorrect t
imestamps in the output file.
frame= 7320 fps=0.0 q=-1.0 Lsize= 306281kB time=00:02:26.41 bitrate=17137.1kbit
s/s
video:279097kB audio:4005kB subtitle:0kB other streams:0kB global headers:0kB mu
xing overhead: 8.187808%

E:\2 = New>"X:\Daves Folder\Sounds\VideoRedo Completed Sound Short.WAV"

E:\2 = New>pause
Press any key to continue . . .

[Carl Eugen Hoyos]

$ ffmpeg -i FFmpeg\ Sample_cut.ts -acodec copy -vcodec copy out.ts
ffmpeg version N-63896-g27b8ef5 Copyright (c) 2000-2014 the FFmpeg developers
  built on Jun 11 2014 18:34:12 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      52. 89.100 / 52. 89.100
  libavcodec     55. 66.100 / 55. 66.100
  libavformat    55. 43.100 / 55. 43.100
  libavdevice    55. 13.101 / 55. 13.101
  libavfilter     4.  7.100 /  4.  7.100
  libswscale      2.  6.100 /  2.  6.100
  libswresample   0. 19.100 /  0. 19.100
  libpostproc    52.  3.100 / 52.  3.100
[mpegts @ 0x1cc5c20] PES packet size mismatch
Input #0, mpegts, from 'FFmpeg Sample_cut.ts':
  Duration: 00:00:00.96, start: 0.200000, bitrate: 21333 kb/s
  Program 1
    Stream #0:0[0x201]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x202]: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 229 kb/s
Output #0, mpegts, to 'out.ts':
  Metadata:
    encoder         : Lavf55.43.100
    Stream #0:0: Video: h264 ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 25 fps, 90k tbn, 25 tbc
    Stream #0:1: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, 229 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[mpegts @ 0x1cc5c20] PES packet size mismatch
frame=   45 fps=0.0 q=-1.0 Lsize=    2637kB time=00:00:00.72 bitrate=29998.1kbits/s
video:2431kB audio:9kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 8.043469%

The output file is 5% larger than the input file.

[DavJames]

MPG and MKV don't have this problem. Only TS.

[Andy Furniss]

You may find that the software that recorded the sample has heavily reduced the PAT/PMT packets.

They do seem a lot lower than recordings I have and ISTR the recorder I use reduced them in the past, possibly a bit now, but not by as much, if at all, due to issues that arose from heavy reduction.

There are slight differences between the sample and the remux in the vid and audio streams, but most of the extra size is more PAT/PMT packets and it seems that one is duplicated with a different PID - I don't know if that is intentional for eg. compatibility, or is an issue.

Below is some output from a (rubbish) ts analyser I cobbled together ages ago. Apart from the dup the output from ffmpeg looks more like what I am user to seeing than the sample.

Sample -

Total packets = 1585830   Errored packets = 0

   PID      Total      RAI     PUSI      PCR   PMD(ms)   CFail    Cut1      Cut2   Flags

0x0000       1384        0     1384        0        0       0        0         0 
0x0100       1384        0     1384        0        0       0        0         0 
0x0201    1555747        6     3660     3653       56       0   481150    642662  AE PD EP DI
0x0202      27314        1     6863        2        0       0   571861         0  AE PD EP DI
0x1fff          1        0        0        0        0       0        0         0

remux -

Total packets = 1668255   Errored packets = 0

   PID      Total      RAI     PUSI      PCR   PMD(ms)   CFail    Cut1      Cut2   Flags

0x0000      39671        0    39671        0        0       0        0         0 
0x0011       7906        0     7906        0        0       0        0         0 
0x0100    1557595      325     7320     3688       40       0        3      6095  AE PD EP DI
0x0101      23412     1706     1697       13        0       0     4877      4889  AE PD EP DI
0x1000      39671        0    39671        0        0       0        0         0

[Andy Furniss]

Looking again at some different recordings and whole mux samples it does seem that the 0x0000 and 0x1000 are abnormally high - perhaps 10x. The original sample does still look quite low.

[Carl Eugen Hoyos]

Fixed by Marton Balint in 2fb550893f7564118ca59765ee5fd1acab819581