Timecode out of order

[Nadav_Givoni]

Guys,

We have an FFMPEG process that is encoding a stream at 4K and we’re receiving a Timecode error (see log references below). We’re suspicious that the cause of this issue is one of the command in our encoding of the stream (and not a network/bandwidth issue).

Please let me know what you’re rates to review/resolve the issue and how soon you or your team is available to engage. We can provide further details as needed.

Thanks

Log:

LiveStreamPacketizerPacketHandler.handlePacket[cogo/definst/cogoStream_3000]: Timecode out of order [video]: 4294967285:4294991051

LiveStreamPacketizerSmoothStreaming.handlePacket[cogo/definst/cogoStream_3000]: Timecode out of order [audio]: 42949673180000:42949673383333

LiveStreamPacketizerPacketHandler.handlePacket[cogo/definst/cogoStream_9000]: Timecode out of order [audio]: 4294967317:4294967339

[Karel_Boek]

Hi @Nadav Givoni, encoding at 4K is a resource-intensive process; what are the specs of the machine that you’re using, and what’s the ffmpeg command you use?

You may have a look at this article: https://www.wowza.com/docs/how-to-fix-unaligned-video-and-audio-with-a-server-side-sort-buffer, but I’d first look into the encoder process.

[Nadav_Givoni]

Karel,

Thanks for the response. We’ve tried the fix that is suggested in the article you sent us and it had no noticable effect.

The server is a VM with the following specs:

1.Microsoft Windows Server 2012 R2 StandardVersion6.3.9600 Build 9600Other OS Description

2.Two AMD Opteron™ Processor 6134, 2300 Mhz, 16 Core(s), 16 Logical Processor(s)ProcessorAMD Opteron™ Processor 6134, 2300 Mhz

3.32.0 GB of RAM

4.VMware Virtual SVGA 3D Graphics Adapter, VMware, Inc

The process that we currently have set up is as follows:

1.A single 4K stream comes into the Wowza server

2.That stream is then restreamed to an FFMPEG process to encode it

3.Then the FFMPEG is then restreamed back to the Wowza server

Below is the encoding we’re using:

D:\Websites\ycWeb\trunk\ffmpeg\cogo\cogo -i rtmp://localhost:1935/live/cogoStream -acodec libfdk_aac -ab 96k -vcodec COGO_H264 -x264-params ‘nal-hrd=cbr’ -x264-params no-scenecut -vf scale=-1:2160 -b:v 9000k -maxrate 9000k -bufsize 9000k -profile:v high -me_method umh -subq 5 -g 100 -keyint_min 100 -sc_threshold 0 -trellis 0 -refs 3 -bf 0 -me_range 16 -pix_fmt yuv420p -f flv “rtmp://198.207.148.108:1935/cogo/cogoStream_9000 flashver=FMLE/3.0\20(compatible;\20FMSc/1.0) live=true”

[Nadav_Givoni]

Karel,

Thanks for the response. We’ve tried the fix that is suggested in the article you sent us and it had no noticable effect.

The server is a VM with the following specs:

1.Microsoft Windows Server 2012 R2 StandardVersion6.3.9600 Build 9600Other OS Description

2.Two AMD Opteron™ Processor 6134, 2300 Mhz, 16 Core(s), 16 Logical Processor(s)ProcessorAMD Opteron™ Processor 6134, 2300 Mhz

3.32.0 GB of RAM

4.VMware Virtual SVGA 3D Graphics Adapter, VMware, Inc

The process that we currently have set up is as follows:

1.A single 4K stream comes into the Wowza server

2.That stream is then restreamed to an FFMPEG process to encode it

3.Then the FFMPEG is then restreamed back to the Wowza server

Below is the encoding we’re using:

D:\Websites\ycWeb\trunk\ffmpeg\cogo\cogo -i rtmp://localhost:1935/live/cogoStream -acodec libfdk_aac -ab 96k -vcodec COGO_H264 -x264-params ‘nal-hrd=cbr’ -x264-params no-scenecut -vf scale=-1:2160 -b:v 9000k -maxrate 9000k -bufsize 9000k -profile:v high -me_method umh -subq 5 -g 100 -keyint_min 100 -sc_threshold 0 -trellis 0 -refs 3 -bf 0 -me_range 16 -pix_fmt yuv420p -f flv “rtmp://198.207.148.108:1935/cogo/cogoStream_9000 flashver=FMLE/3.0\20(compatible;\20FMSc/1.0) live=true”

[Karel_Boek]

@Nadav Givoni,

Have you compiled your own codec? I don’t know COGO_H264, is it based on libx264?

Maybe dependent on how many cores and threads ffmpeg may use, but I’d say an Opteron 6134 isn’t powerful enough. The input is presumably a higher bitrate, and so ffmpeg has to decode 4K @ ??Mbps, and re-encode to 4K @ 9Mbps.

You can check the CPU usage in Windows with the Resource Monitor. I recommend to look into a GPU, e.g. NVidia or QuickSync.

[Steven_Smith1]

Karel,

We’re using a third party codec, I believe it is libx264 based. The CPU is preforming within reasonable bounds, but yes a GPU would be a good idea.

That said do you see anything in the encoding definition that might be a red flag?

Also I want to know if you’re available to do parttime contract work? If so I’d like to know what your rates are and if you can send us your CV. There are essentially three areas we are looking for assistance with:

1. The Wowza Stream Engine configurations to make sure that they are optimized for a 4K stream
2. Reviewing the encoding to make sure it’s idea for the type of stream coming in
3. Reviewing the hardware/server to give us recommendations as to what is needed.

Please let me know if this is something you’re interested in and we can get on a Skype call and review further.

Thanks,
Nadav

[Karel_Boek]

Hi @Steven Smith and @Nadav Givoni,

In order to investigate the issue further, I’d have to set up some simulation myself, and probably also check your server. There’s a lot of parameters in your ffmpeg command, and without further testing, I can’t tell if the combination is optimal.

Yes, I’m (or we’re) for hire: Raskenlund is a consultancy firm where we help you with your streaming challenges; all the way from the idea to an operational environment. For further details, rates, etc. contact me at karel.boek@raskenlund.com, or Skype me at karelboek.