[FFmpeg-user] Video Standards for the Net

[Reuben Martin]

On Tuesday, August 30, 2016 7:16:47 AM CDT Mettavihari D wrote:
> Greetings,
> 
> Thank you for your notes.
> 
> On Mon, Aug 29, 2016 at 9:01 AM, Reuben Martin <reuben.m at gmail.com> wrote:
> > On Monday, August 29, 2016 5:40:41 AM CDT Mettavihari D wrote:
> > > We have recently installed clipbucket as a video site
> > > I find that the compression they use is as below.
> > > My question is whether those standards are good or they should be
> > 
> > increased
> > 
> > > in quality.
> > 
> > “Good” is context specific. You can get speed, quality, and low-bitrate,
> > but
> > you only get two... which two depends on your use case.
> 
> My problem is if I go by these standards now then they may be too low for
> the market in 2 years and I would have to re-encode 30.000 files by then.

The only thing you need to worry about is how it is to be delivered. From the 
settings you gave it appears this is just for static video set up for play-on-
demand or direct download. But the trend is moving towards segmented (chunked) 
video, which implies some constraints beyond what is in the settings you 
posted. So like I said, it depends on what you intend to do with the video. Is 
it just for direct download, old-school RTMP streaming, maybe MPEG-TS, or 
something modern like HLS or MPEG-DASH. Different purposes require different 
constraints. “Good” can mean different things in each of those contexts. I 
suggest reading on how HLS and MPEG-DASH works since that is probably what you 
will most likely have to deal with in the future.

> 
> > Not sure why they re-interleave the files. Perhaps it’s a means to also
> > make
> > the file “web optimized”, but they could do that directly with ffmpeg.
> 
> I would appreciate a hint on how to achieve that with ffmpeg.

-movflags +faststart

> 
> > Taking the vertical scan resolution and appending 3 zeros to use as the
> > bitrate is kinda lame and doesn’t well reflect the rate the bitrate
> > generally
> > changes as the frame size increases with the x264 encoder.
> 
> Your recommendations are very much appreciated.

I wouldn’t worry too much about bitrate. Use a constant quality setting and 
let x264 work out the bitrate. Instread of using the -vb option, try using the 
-crf option. The range is from 1.0 (highest quality) to 50.0 (crap). Generally 
stick to something between 16 and 26. Anything higher starts to look gross, 
anything lower is generally not perceivable by the viewer. If you are worried 
about rate, you can still cap it with a maxium bitrate or minimum bitrate. But 
unless there are constraints you have to meet, it’s generally not an issue.

> 
> > Also, the resolution “480” (at least in the context of broadcasting)
> > generally
> > implies an animorphic resolution, which is not what is happening in this
> > instance. But that’s being nitpicky.
> 
> I appreciate a good advice and a ling to possible standards in the world.

480 is usually in reference to NTSC which is 720x480 and can have a display 
aspect ration of either 4:3 or 16:9 depending on content. But honestly, unless 
this is to be played on a TV, don’t worry about it. The sooner anamorphic 
resolutions and interlacing dies in broadcast, the better.

> 
> with best regards
> Mettavihari
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".