Transcoding with GraphStudioNext

A solution to the V264 Codec saga was kindly suggested by a regular contributor and involves using a Filter Graph application to encode the video.

The first introduction to the V264 Codec was detailed here.

It was then identified as belonging to Verint, as detailed here.

Processing these files was proving tricky so attempts were made to deal with the date/time overlay and transcode, detailed here.

It was as a result of the last article that the suggestion of using the filter graph application to transcode the file flew my way. Here I am using GraphStudioNext.

In the image below, I have dragged my Verint encoded .avi file into the graph window and pressed play. It displays the graph of filters being used to decode the data and output it to the renderer. I am doing this inside a virtual PC with the codec installed. (I never install proprietary codecs into my main OS). The trick here is to change the graph from being a display graph to one offering transcode functionality.

The first thing we need to do is remove the Video renderer from the filter chain. (Right click, delete selected).

The next task is to add in an encoder, a muxer and then finally a file writer.

All of these are available from the Graph menu. (Insert Filter, Insert File Writer). The graph should then look something like this:

I chose the FFdshow encoder and then configured this for Uncompressed Video.

The result is an uncompressed AVI file with the date and time overlay hard encoded into the footage. Seen below in Virtualdub.

It’s worth remembering a couple of things. The LrX Text overlay filter has a number of settings to change the position. This may be useful if there are points of interest underneath. Just right click that filter icon in the graph and select properties.

Also, and most importantly, remember that we are getting an uncompressed version of the Verint decoders output. The stream itself is 704×288 but the decoder adds in the resize. How its doing this is unknown. In order to identify issues at a pixel depth, it would be necessary to deal with the raw H264 stream first, as was detailed in my original post.

Thanks again to Compn for suggesting this route and directing me to here where the puzzle pieces all began to fall into place!

Jan 2016 Update: A regular reader has informed me that using this method in Windows 8.1 failed. When he used a virtual Windows XP environment it worked. Something to consider.

Also – read the comments about timing lag – there is a possible solution surrounding changing the timing clock of the renderer.