.264 files and FFmpeg

Back to FFmpeg again!

If you have arrived here regarding V264 – Click HERE

I have recently begun to notice a few mp4 / h264 / AVC stream files that don’t want to play nicely within FFmpeg or the other small GUI’s designed to rewrap the raw streams into a container file. The need to do this is also becoming more regular due to the increasing amount of streams arriving with no other player or information file packaged with them.

So, a folder on a disk named RecordFile. Within this are a number of .264 files with a long naming convention consisting of channel number, date and time. Although there are numorous h264 players out there, my usual route is to stick a file first into MediaInfo and see what it reports.

If it is, as suspected an AVC/h264 file, then its dropped into FFplay to assess how FFmpeg handles it. If all goes smoothly then it’s either FFmpeg to rewrap or AVC2AVI.

The four files here though crashed AVC2AVI and would not initially play in FFplay.

Taking a closer look at the files in HXD, reveals a useful piece of text within the initial data. Its always worth keeping these so if you obtain data or even drives where this appears, you have a head start with your research.

Start of Data in HXD

The video data itself started at offset 10000 and there was nothing else within the data stream that looked out of place.

Data Start

It is not usually necessary to tell FFmpeg what file it is reading but with these files, as it turns out, that’s exactly what the problem is. Once I forced FFmpeg to treat the input file as a h264 video, the rewrap started.

I have also begun to document the entire FFmpeg procedure for inclusion in reports.

The workflow and FFprobe / FFmpeg commands are below:

ffprobe -show_streams -count_frames -pretty originalfile.264 > ffprobeREPORT.txt

ffprobe -show_frames -pretty > allframesREPORT.txt

I then use Windows Powershell to strip this down to just the Coded Picture Numbers and Frame Type

Now that I know the details on amount of frames and the FPS I can use FFmpeg to rewrap my stream, create an index within it to enable scrubbing back and forth and also compile a report on the process.

ffmpeg -f h264 -i originalfile.264 -f avi -r 25 -vcodec copy -vsync drop -debug_ts -loglevel verbose -report originalfile-rewrap.avi

We now have a fully scrubbable and editable file that plays great inside Virtualdub along with the ffmpeg input library.

Virtualdub Info

So, in conclusion… if files don’t want to do something within FFmpeg and you think that they should it may be worthwhile ‘forcing’ the issue and actually telling FFmpeg what the input file is by placing the -f flag before the -i input file.

On a connected note – pay particular attention to the frame numbering and counting between Mediainfo, Virtualdub and FFprobe etc. Be prepared to justify why the numbers may be different. I am finding that some rewrapped avi’s do have frames missing. When the original .264 file and the report compiled during the process are analyzed, it reveals that they are missing, damaged or out of the correct decoding order. This seems more common on files from the lower end of the market where dropping a frame every now and then is not immediatly noticeable.

Just keep your fingers crossed its not right in the middle of something important!

Advertisement