haggisbingo wrote:Buzzard1999 wrote:I used to use roksbox and loved it. Then WillDD seemed to abandon it completely.
I for one would love an alternative to the Roku Media Player. I don't need uber-fancy - just something that works and looks good. If you could replicate roksbox and have it work with my WDMyCloud, I'd pay for the channel.
I PM'd WillDD and he's fixing the problem on the Ultra.
PLEX is a big letdown. We literally had to adjust the video setting for each movie... just ridiculous.
Roksbox handled ALL of those same videos (MP4s) with no problem, playing immediately and no buffering. Furthermore, a 15 year old Windows 2000 computer running IIS is handling all of this - with no problem! The PLEX server is running on my personal computer (which has 8 processors) and it's giving PLEX everything. But it's still BUFFERING......
A) Turn off transcoding on PLEX and it will lower your CPU usage to almost zero. I have Plex installed as a plugin on my FreeNAS box that has a very underpowered CPU for video encoding. I never get buffering or low quality playback. The CPU is effectively idle when watching a movie.
B) Plex uses the TvDB format for episodes and the TmDB format for movies. I had to change the names of all of my Loony Tunes mp4 files as well as the directory structure to accommodate that.
C) If you had to adjust the video settings for each movie then there may be a problem with your content. I've been in the streaming media industry since 2008 and improperly encoded content is one of the biggest problems I see.
When you are encoding content for streaming, which is what both Roksbox and Plex deliver, it is vital that you do a few things.
1) Make sure that your keyframes are aligned as this helps with segmented content having equally sized segments. This also helps to switch renditions when using Adaptive Bitrate (ABR) content. Keyframe distance is also known as a Group of Pictures or GOP. A small portion of ancient content that I have does not have keyframes properly aligned and they still play back.
2) Make sure that you are converting your content to the proper color space for streaming media.
3) Make sure that your content is encoded to either a constant bitrate or average bitrate. Encoding content using a variable bitrate or Constant Rate Factor (CRF) is anathema for streaming media. VBR and CRF will create unpredictable segment sizes and the bitrate variance will be unpredictable on your network. Please note that delivering CRF content or VBR content via either Plex or Roksbox works.
4) Make sure that your framerate is constant. Having a variable frame rate come out of your encoder will break most forms of segmented content delivery as well as ABR delivery. The x264 implementation of the H.264 video codec will by default create keyframes when it detects a scene change.
I use
FFmpeg on Windows for converting my content and drive it with a heavily documented 1,600 line bash shell script I wrote that runs under Cygwin. You will need to adjust your frame rate and bitrate accordingly in the sample two pass command lines below. You should also check for soft telecine if you convert DVD VOB files to MP4. If you do not do that then you may experience judder.
ffmpeg -i inputfile.mp4 -pix_fmt yuv420p -vsync 1 -vcodec libx264 -r 23.976 -threads 0 -b:v: 1024k -bufsize 1024k -maxrate 1024k -minrate 1024k -preset medium -profile:v high -tune film -g 48 -x264opts no-scenecut:ratetol=0.01 -acodec aac -b:a 192k -ac 2 -ar 48000 -af "aresample=async=1:min_hard_comp=0.100000:first_pts=0" -pass 1 -f mp4 -y outputfile.mp4
ffmpeg -i inputfile.mp4 -pix_fmt yuv420p -vsync 1 -vcodec libx264 -r 23.976 -threads 0 -b:v: 1024k -bufsize 1024k -maxrate 1024k -minrate 1024k -preset medium -profile:v high -tune film -g 48 -x264opts no-scenecut:ratetol=0.01 -acodec aac -b:a 192k -ac 2 -ar 48000 -af "aresample=async=1:min_hard_comp=0.100000:first_pts=0" -pass 2 -f mp4 -y outputfile.mp4
-g 48 will define a GOP of 48 frames to create a two second GOP for that 23.976fps content. This works in conjunction with the no-scenecut option below.
-x264opts no-scenecut will force keyframes to be created per the GOP value that FFmpeg uses. The default for libx264 is to create a keyframe when it detects a scene change. If you inspect an output file with MediaInfo you will see "scenecut=40". When done properly that will be zero "scenecut=0". If this option is not used then keyframes will be misaligned for ABR content and segment sizes will be unpredictable.
The libx264 option "ratetol=0.01" will force a very strict constant bitrate, so much so that libx264 will complain and adjust accordingly. This is optional.
-af "aresample=async=1:min_hard_comp=0.100000:first_pts=0" helps to keep your audio lined up with the beginning of your video. It is common for a container to have the beginning of the video and the beginning of the audio start at different points. By using this your container should have little to no audio drift or offset.
Now why two pass encoding? Perform a test CRF 21 encode of your content using the veryfast preset and the baseline profile then do the same with the medium preset and the high profile. Both files will be the same quality but the file encoded using the medium preset and the high profile will be smaller due to the higher levels of compression.
Use the bitrate (or BPP or bit per pixel density) of the baseline profile output file and then do a two pass encode using the medium preset and high profile. This will create a file that is within one percent of the size as your baseline CRF 21, have the same BPP as the baseline file, but have an effective CRF quality value around 19.54. My script does a CRF 21 baseline encode, grabs the BPP value, and then performs a two pass encode using those settings. You can also find a deeper explanation of that process I perform on my video blog
here. There is also an article from the
Streaming Learning Center where Jan Ozer references multiple methods of calculating a better bitrate, including the method I mention on my blog.