Encoding questions and ffmpeg advices

[Claude.Rivet]

Hello fellow watchout programmers!

 

Disregard my previous post with same title I inadvertently sent it and it was not finished

 

I started learning ffmpeg and now I have a few questions regarding encoding and how Watchout uses various options.

 

1- encoding for multiple thread (x264lib flag ans other codecs also):

basically encode in a way that when the file is read it is decoded by as many core as there are specified thread. So encoding for 8 thread would make sure my 8 cores are used when reading the file. 

I noticed Watchout very rarely use 8 core on my system, 4 is common and most often it's two. even when reading 24HD files concurently.

Would encoding for 8 threads solve that?

What would be the effects: 

-If I play back a 40Mbps file will it basically be the equivalent as far as load time and fluidity and possible concurent files as playing a 5Mbps file encoded for 1 thread?

-Does Watchout support multiple thread decoding?

-lets pretend my file is encoded for 8 thread and I read it on a system that has 2 cores and no hyperthread, will the file read? Will it be the equivalent of playing back the same file but encoded for one thread or will it be more demanding for the system?

 

2- As far as watchout goes I once was told mpeg2 was the holy grail of Watchout format as it was very easy to read and of high quality. In my experience it is true, I can play more mpeg2 files than mpeg4 files and quality-wise it fits my needs quite well. However this was a few years ago, how about now? Still the prefered format? Since I have access to ffmpeg and can now turn on or off pretty much any flag is there some settings you guys know are optimal?

 

3- I need to encode files in 1920x1200, it is not an ideal resolution and even though I am sure it will encode in mpeg4 I doubt it will without issues in mpeg2. I will need to play at least 8 concurent files at that resolution and it needs to be very fluid, no stutter or hiccups. A possible solution would be to encode the file in anamorphic 16:9 and strecth it back to 16:10 in Watchout but if I could avoid that it would be awesome. I need the file to play back near instantly so heavy codecs like photo jpeg or animation and to be avoided. Keep in mind I can play 12 HD files in mpeg2 and mix them in 12 other HD files encoded in mpeg2 with no issue on my system for as long as there is no live input on screen, 40Mbps files.

 

Sorry for the long post but I need to access our collective minds on these issues

 

thanks for the help

regards

 

For reference, my system:

Windows7, heavilly customized and stripped-down, basically Watchout only system

8core i7

16GB Ram

V9100 Firepros

VisionRGB SDIpro2

M.2 XP941 SSD drive

[jfk]

Nice rig Claude.
I am not going to try and answer your MPEG questions,
but one of your comments surprised me.

 

... Keep in mind I can play 12 HD files in mpeg2 and mix them in 12 other HD files encoded in mpeg2 with no issue on my system for as long as there is no live input on screen, 40Mbps files. ...

 

Live input affects your movie decoding capacity? Is the live input interlaced or progressive?

 

I ask, because as I understand it, assuming the Live Video media object is correctly set for the input signal type,

interlaced live video will de-interlace in the cpu,

 which I would expect would take some resources away from movie decoding.

 

Progressive, on the hand, should bypass the CPU and DMA direct to the GPU,

which should have no impact on movie decoding. 

 

When selecting your live video rig, this may be worth consideration.

[screenshaper]

Claude, I'm afraid you have been misled by the ffmpeg documentation, often confusing, unclear and outdated.
Ffmpeg thread options adjust how ffmpeg itself use multithreading decoding input files and encoding output files.
This doesn't have any effect on the way a decoder will handle the resulting video.

[dnmeid]

1- encoding for multiple thread (x264lib flag ans other codecs also):

basically encode in a way that when the file is read it is decoded by as many core as there are specified thread.

...

Would encoding for 8 threads solve that?

No, the -threads option of ffmpeg only specifies how many threads are used by ffmpeg itself, it is not written to the file. A few years ago ffmpeg used only one thread by default when omitting that option. At the moment it uses as many as possible, so you better use this option only to limit the use of threads.

 

-Does Watchout support multiple thread decoding?

Yes

 

2- As far as watchout goes I once was told mpeg2 was the holy grail of Watchout format as it was very easy to read and of high quality. In my experience it is true, I can play more mpeg2 files than mpeg4 files and quality-wise it fits my needs quite well. However this was a few years ago, how about now? Still the prefered format? Since I have access to ffmpeg and can now turn on or off pretty much any flag is there some settings you guys know are optimal?

MPEG2 (h262) is still the least resource intensive codec to use with Watchout. I use ffmpeg too for encoding and I usually use various options for finetuning, e.g. for 422 colorimetry instead of standard 420 and I use quality based compression strategy with a q-factor of 2 since I'm usually not concerned about bitrate.

When you encode MPEG4 (h264) there is one major trick for making the files easier for watchout to decode, use the "-tune fastdecode" option. This disables a few features like CABAC, which are CPU heavy. For h264 I usually use 444 colorimetry and also use a quality based bitrate strategy with CRF of 15, this results in close to lossless image quality.

Depending on your show and it's needed synchronity, linearity and responsiveness I also suggest to use I-frames only. This is done with "-g 1" (setting the GOP length to 1), but requires more bitrate for the same visual result.

 

3- I need to encode files in 1920x1200, it is not an ideal resolution and even though I am sure it will encode in mpeg4 I doubt it will without issues in mpeg2. I will need to play at least 8 concurent files at that resolution and it needs to be very fluid, no stutter or hiccups. A possible solution would be to encode the file in anamorphic 16:9 and strecth it back to 16:10 in Watchout but if I could avoid that it would be awesome. I need the file to play back near instantly so heavy codecs like photo jpeg or animation and to be avoided. Keep in mind I can play 12 HD files in mpeg2 and mix them in 12 other HD files encoded in mpeg2 with no issue on my system for as long as there is no live input on screen, 40Mbps files.

1920x1200 is no problem neither with MPEG2 nor with MPEG4, but it will break the limits of MPEG2 high level, that means decoders only specified for high level may not be able to decode it. Watchout can.

 

 

Dorian

[Mike Fahl]

Excellent notes and suggestions, Dorian.  I learned a lot. Many thanks!

 

Mike

[Claude.Rivet]

Thank you so much! Will keep you informed if I ever manage to fine-tune it even more.

 

JFK:

The amount of files that can mix will affect the live input frame rate and to a certain extent vice-versa. I am blaming the 4GB ram limit after testing with intel XTU. Indeed when I have a live feed on screen no more than 3 files can be mixed into 3 other files, else the live feed stutters or freezes for a second or so. On a large amount of files the mix fluidity is affected but not very much, nonetheless it is noticeable. Progressive is worse than interleaced but progressive does take more bandwith hence me leaning on the ram bottleneck rather than CPU which never goes above 35-40% 2-4cores out of 8. But yeah de-interlacing does take more CPU ressource but not enough to choke it it seems.

[David Organ]

Dear dnmeid,

Please can you (or anyone esle) recommend a FFmpeg GUI to use as reading this post makes me wan't to try again with FFMPEG however the command line option was too difficult (too lazy) to proceed.

Many thanks,

David

[screenshaper]

I dare say Handbrake