Corrupted .264

An interesting little problem!

The video file had a common naming convention of channel number, date and time. Followed by the .264 extension.

All appeared pretty normal upon dropping it into MediaInfo, but the pixel measurements were quite uncommon 464 x 240. Lets deal with that later!

My next usual port of call is ffplay.

It played as I would expect for the first few seconds and then just turned grey. The command line output was just a stream of errors. To try and figure out what the errors were I output a report by placing -report after the input file.

ffplay inputfile.264 -report

The report will go inside the ffmpeg folder. The biggest issue seemed to be an issue with the NAL – The Network Abstraction Layer.

NAL on Wikipedia

There were some other issues and errors so, after the obligatory Google search on the various messages, I began to form the opinion that at the point the video went grey, a coding error has meant that any images after this are unable to be viewed.

After testing with (nearly) all the usual players and tools – nothing could get passed the error.

What I have not mentioned so far is that I had been informed that Adobe Premiere Pro CS6 could read it. Upon starting a new project and importing – It played!

The question was how?… and how could I deal with the error so analysis could be conducted on the file in its native form?

A new testing tool for me is GStreamer

Although there are Windows builds, I am just getting to grips with the Linux build. Running and testing commands and ‘pipelines’ seems a little easier in linux. My reason for attempting GStreamer was that I wanted to play the footage as if it was a video stream rather than a file.

So, after ensuring that Gstreamer and all the dependencies were updated, the command line in Linux Mint

$ gst-launch playbin2 uri=file’inputfile.264′

It played!

There are a fair few weblinks for basic Gstreamer commands and guides for use, but this is definitely a new tool to get some basic knowledge on.

I ended up conducting a test transcode with Transmageddon.

After all of that I could establish that all the video data was there, it was just getting stuck. My understanding of this is that GStreamer is constantly reviewing the input stream and as such is able to continue playing the file after the error.

Back to Windows and ffmpeg and I conducted a rewrap but skipped the first 1500000 bytes.

ffmpeg -skip_initial_bytes 1500000 -f h264 -i inputfile.264 -vcodec copy outputfile.mp4

I now had a direct, playable copy of the corrupted file without the damaged start. So, the video was now OK – what about the size?

I have mentioned a few times about a new surveillance resolution of 960H. The pixel dimensions of this are a mixture, depending on the manufacturer.

Its either 960 x 480 or928 x 480 (or 576-PAL).

The 464×240 size is from a camera that’s obviously designed for 960H, but the DVR is set to record at half size. Similar to how 352×240(288-PAL) is commonly used.

What have we learned?

  • How to output an ffmpeg report to identify and study the error messages
  • The use of Gstreamer to stream a video and if required, transcode it
  • How to skip a certain portion of the start of a file within ffmpeg
  • That a company has installed a camera and DVR capable of recording at a higher than SD resolution – but then they have halved it, resulting in footage less than SD resolution – when will they learn?

Hope it helps,

And if you really want to know a bit more on the H264 NAL


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s