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.

uc-playing in vdub

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.

By Spreadys Posted in EEPIP

13 comments on “Transcoding with GraphStudioNext

  1. Pingback: Using Avisynth and GraphEdit |

  2. Pingback: Pelco PLV1 Codec |

  3. Thank you for insight; I’ve got a few verint files(.avi) and have taken them through Graphstudio, but unfortunately the time stamp overlay lags significantly behind the original file.

    • Sorry for not responding sooner. Is that after transcoding? That looks like a rather worrying issue if that’s the case. If you research the issue and find any solution, please post back for the benefit of the community. Thanks again.

      • No problem Spready; Appreciate the work you do here and over at DME. Yes that’s after transcoding; I’ve tried fiddling around with the ffdshow settings, using different encoders, but to no avail. It’s very strange because the timestamp plays back fine with the Video Render node, however any encoding done to it will cause it to slow down(by approx. 20 seconds!).

      • I’ll continue to look into this; I should note, however, my video files have the SN40 codec, which is from Verint. I’m not sure whether this is playing a factor in why I’m having issues with the time stamp overlay. With the SN40 codec installed, the video and time stamp can only be viewed in Windows Media Player.

  4. You have identified a big issue – thanks for letting the community know. Its little things like this that can cause all sorts of problems. Please keep me in the loop on your research. It definitely sounds like an issue with the rendering through the codec. Verint and Lorinix have caused me all sorts of headaches over the years so its not surprising you have come across a codec doing weird stuff!

  5. OK, I have now experienced this ‘lag’ for myself. This time it is a V264 4CC that appears the same as the one detailed in my post but suffers with time overlay lag when transcoding using GSN. I believe, at this point, that its caused by a poorly written filter. The video file I am examining reports 6.25 FPS. It may be that the time overlay filter cannot adjust itself properly on the output. I will do some more testing and if I get anywhere, I will report back!!

  6. SOLVED:
    Under the Play option of GSN you will see a Use Clock option.
    This should normally be ticked.
    By removing the renderers ability to use the timing clock (by un-ticking this option), the output keeps the correct frame rate and this time the overlay is correct.

    • Not sure to be honest! It uses the same framework so in theory it should. Give it a go and if you are still running into issues, mail me at david(at)

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s