How do I fix the "PES packet size mismatch" error in FFmpeg?

Question

How to fix the error PES packet size mismatch in FFmpeg -

I'm going to answer my own question, because the phrase PES packet size mismatch comes up regularly in posts relating to ffmpeg, but I've nowhere seen a satisfactory solution to it.

It usually figures in a problem involving .TS transport stream files: either in relation to concatenating such files, or relating to re-muxing them (from .ts to .mp4). Somewhere in the output from ffmpeg, the deadly phrase packet size mismatch will suddenly start repeating.

A solution is to concatenate them as .ts files (i.e. in their original format), then take the output .ts file, split it into a video file (.ts) and an audio file (.ts), then remux them (to either .ts or .mp4) using the "itsoffset" option. Even if stream copy is used, outputting to .mp4 will often give worse picture quality than retaining the .ts format.

The following code does that, outputting either .mp4 video or .ts video (copy the code into a simple .bat batch file, then run that file) -

.

:: Program Location
SET ffmpeg="C:\Program Files\FFmpeg\ffmpeg.exe" -hide_banner  


::  STEP 1 -

::  Create File List
IF EXIST mylist.txt DEL mylist.txt
FOR %%i IN (*.ts) DO ECHO file '%%i'>> mylist.txt

::  Concatenate Files : TS
%ffmpeg%  -f concat  -safe 0  -i mylist.txt  -c copy  -threads 1  out.ts


::  STEP 2 -

::  Extract Video stream
%ffmpeg%  -i out.ts  -vcodec copy  -an  -sn  -threads 1  video.ts

::  Extract Audio stream
%ffmpeg%  -i out.ts  -acodec copy  -vn  -sn  -threads 1  audio.ts


::  STEP 3 -

::  Combine Video and Audio streams (with .MP4 options)
SET mapping=-i video.ts -itsoffset -0  -i audio.ts   -map 0:v -map 1:a
SET options=-flags global_header  -movflags faststart  -threads 1
%ffmpeg%  %mapping%  -c:v copy -c:a copy  %options%  output.mp4

::  Combine Video and Audio streams (with .TS options)
SET mapping=-i video.ts -itsoffset -0  -i audio.ts  -map 0:v -map 1:a
SET options=-threads 1
%ffmpeg%  %mapping%  -c:v copy -c:a copy  %options%  output.ts

.

Addendum :

There seems to be some dispute about my suggested solution, as detailed in the Comments below. It seems to be being said that my solution is ignoring the fact that data is missing in the source files.

I think the least I can do is admit that since ffmpeg is reporting an error in the source files, with its 'packet size mismatch' warning, the objection raised in the Comments might be valid.

However, even if data is missing, my suggested routine will at least give you a file which will play in most media players. In many cases, there will not even be an audible or visual fault at the join point specified in the reported error.

It's difficult to see how the missing data might be restored, but do please chip in with suggestions. There must be scope for improving my script, because so little attention has been paid to this type of fault previously.

Happily, it seems that this type of error will NOT cause the sound to lose synchronisation with the picture. So the audio after the join-point will not go out-of-sync, even if some data is missing at the join.

Solution

PES packet size mismatch

Error message (Video files):

PES packet size mismatch

.

Analysis of Error:

A single PES packet can only contain ONE of the three possible types of frame, namely I, B or P. A single PES packet stores one DTS/PTS pair.

What the muxer does is take the frame (be it I, B or P) and package it into a PES packet, then add a DTS and a PTS timestamp to that packet, and that's all. The next frame will be packaged into a separate PES packet.

Sometimes, depending on the encoder and muxer, when a frame is very large (such as an I-frame in an HD video) it is packed into multiple PES packets which all have the same DTS/PTS timestamps.

Where the SPS and PPS of the h264 stream are packed, together with an I-frame, into a single PES packet, if that packet (containing the SPS and PPS) is lost, the decoder will have to wait until the next SPS and PPS are transmitted -- because without them it cannot decode the stream.

Frame types in MPEG-2 video:

• Frame type 001: intra-coded (I) - "i frame"

• Frame type 010: predictive-coded (P) - "p frame"

• Frame type 011: bidirectionally-predictive-coded (B) - "b frame"

In live streams, all tv stations set PES length to zero for H264 video streams, as the PES length is a 16 bit value, hence has a maximum size of 65,535 Bytes (the old standard for MPEG2 video). That is too small for most H264 PES packets, so it should be set to zero (i.e. "any length").

A problem can arise if the video stream has a non-zero PES length. FFMPEG does not seem to cope with that. It appears that FFMPEG requires the stream to be explicitly labelled "any length" (i.e. set to zero).

If I download a raw .ts file and run it through TS_Doctor, the analyser complains:

"PES length on video stream detected. This can be problematic! Patch PES length on video stream to a safe value - Yes/No."

If I click on "No", then run the output through FFMPEG, a problem is reported of the sound being out-of-sync. If I click "Yes", then run the output through FFMPEG, no problem is reported. This suggests the only difference between the output files is the PES-length fix.

A value of zero for the PES packet length can be added only when the PES packet payload is a video stream.

.

Workaround:

A possible solution is to concatenate the .ts files, then take the output .ts file, split this into a video file (.m4v) and an audio file (.m4a), and then remux them (still as .ts format) using the "itsoffset" option.

Then it should be possible to convert the resulting .ts file to .mp4 or .mkv without any error.

Not ideal, but it often works.

Comments

[szatmary]

It’s great that you answer your own question, but please put the question in the question box, and the answer in the answer box.

[Gyan]

By *output will look fine *, I mean that the packet fields will be in sync. If the actual media data is corrupted, it will be in the output file as well. If only the packet metadata is corrupted, that won't carry over to the output. But this is not related to concatenation.

[Валерий Заподовников]

This was actually a bug in ffmpeg: patchwork.ffmpeg.org/project/ffmpeg/patch/…

[Ed999]

Available for Windows 7 at gyan.dev/ffmpeg/builds

[Валерий Заподовников]

Even though the patches were applied it did not fix a lot of other PES packet size mismatch!