Batch encoding with a frame quality parameter instead of bitrate ?

[ronpub]

I'm writing batches to encode videos from different sources (digital camera, HD camcorder, VHS converted to MPEF2, ...). Those videos has different aspect ratios and fps. The output file should be 800 pixels large. Then for a given quality, depending on the sources, the bitrate should be different.

I use mencoder in my batch to encode the files. How to encode with an approximate frame quality (eg 0.3) as given in Gspot: (video bitrate in bits/second) / (horizontal res * vertical res * framerate)

The tip I thought about was to calculate it in an avs script as I use one before encoding and pass it to the command line but I can't find in forums if it is possible to pass value. Or launch the command mencoder within the avs script.

But perhaps I missed something and it is possible to give the frame quality as a parameter instead of the bitrate in mencoder.

[Ethlred]

Encode to what? What codec? If you mean x264 then do a CRF encode.

I think by quality you are referring to the Qf box bits/pixel-frame. This is more a measure of compression than quality. A talking head could look great at very low bit rates while a far higher bit rate could look bad with action. Since the bits/pixel is dependent on both the source and encoder and the choices made by the person making the encode its at best a very rough and often misleading measure of the quality of the compression.

How to make it a fixed number for all encodes? Figure out the size of the frames in pixels and the number of frames of any videos you wish to do this to then choose a fixed file size to meet the desired bits/pixel and do a two pass encode. Why the heck you would want to do this is another thing since your resulting REAL quality would vary all over the place depending on the source. If you are doing a x264 and don't care about the size just pick out a CRF setting that fits your desires and make one pass encodes. I find CRF=20 works pretty well for me but I am watching on my massively huge 17inch CRT. Its just a tad old. Many like CRF=18 for their conspicuous consumption giganto-humungous flat panel laser emitting death-ray screens.

No I am not jealous. Not, not not.

[ronpub]

Encode to what? What codec?

mpeg1

I think by quality you are referring to the Qf box bits/pixel-frame. This is more a measure of compression than quality.

To talk about Qf is the same for me to talk about bitrate. The relation is mathematical. I would like to give a Qf parameter instead of specifying bitrate.

How to make it a fixed number for all encodes? Figure out the size of the frames in pixels and the number of frames of any videos you wish to do this to then choose a fixed file size to meet the desired bits/pixel and do a two pass encode. Why the heck you would want to do this is another thing since your resulting REAL quality would vary all over the place depending on the source.

There are hundreds of clips to convert (demos of machine working). I want to automate all the process.
Moreover I want in the future every people in the company being able to do the job without any knowledge. Video is a huge area.

If you are doing a x264 and don't care about the size just pick out a CRF setting that fits your desires and make one pass encodes. I find CRF=20 works pretty well for me but I am watching on my massively huge 17inch CRT. Its just a tad old. Many like CRF=18 for their conspicuous consumption giganto-humungous flat panel laser emitting death-ray screens.

Thank you for the tip I will investigate. That is the kind if tip I need. But I won't choose x264.

[Ethlred]

To talk about Qf is the same for me to talk about bitrate. The relation is mathematical. I would like to give a Qf parameter instead of specifying bitrate.

That is what I was showing. There is however no way to predict QF except to set the bitrate. Which is the other thing I was pointing out.

Now if you want to create your own front end you certainly could achieve a specific bit rate which by basing it on the original video size in frame count and pixel count you would get what you are trying for. This called putting the cart before the horse. Possibly desirable but impractical. If all the videos are taken with the same camera with the same settings this would be fairly easy. Just use the length of the video to figure out the target file size or do one calculation to figure out what bit rate you need to get your target QF. Then set up the program to use the same bit rate all the time.

Moreover I want in the future every people in the company being able to do the job without any knowledge.

I want to be a billionaire without working at it. The average person at most companies won't even be able to use the camera without training. Try some realism. To even remotely approach your goal you will have to standardize everything. The camera. The programs and the computer. One computer or a set of them all set up exactly alike. Possibly custom software as your requirement for using QF as the prime parameter instead of bitrate is simply backasswards and completely unnecessary.

If you really want to flog this dead dolphin and are willing to spend the bucks for the custom software that will be required maybe you can even sell the resulting software. It will be the first to do it that way. The program will have to do it exactly the way I laid out. The programmer will just lie to you by sticking a fake setting that masquerades as a QF setting but it will just do what I suggested. Much of programming is hiding the real methods behind a pretty facade.

But I won't choose x264.

I can understand that. However you haven't said what you DID want to use. Not even a hint. I mentioned it because its the one codec I know that does use a quality setting that is based on human vision instead of a fixed quantisizer or bit rate. None have a fixed QF that I am aware of but there is lot that I am unaware of. However I suspect I am pretty much spot on here since no one else has responded.

EDIT:

I see you did say what codec. How did I miss it? Brain rot. OK Mpeg 1 which is I think 352x240 for pal. Oh and oops about some of the American slang. Forgot you were French.

Why Mpg1? Its old has poor compression even in comparison to mpeg2 and the color gamut is poor. Has minimal usage outside of Asia these days.

[AlanHK]

HCEnc (MPEG2 encoder) has a "Constant Quantization" single pass mode.
This seems to give a result similar to constant quality, though technically it isn't.

I use it for making quick DVDRWs I can watch once and delete.
The size of the file is unpredictable exactly, though you can estimate.

You can use the GUI, or a command line like:

P:\HCenc\HCenc_023 -i video.avs -o video.m2v -aspectratio 16:9 -pulldown -profile best -matrix qlb -frames all -cq_maxbitrate 4.5 -maxbitrate 8000

Input via AVS file.

[ronpub]

That is what I was showing. There is however no way to predict QF except to set the bitrate. Which is the other thing I was pointing out.

The relation between bitrate and Qf as done in my previous post is equivalent (http://en.wikipedia.org/wiki/Equivalence_relation). Then giving bitrate or Qf is the SAME. I will reformulate my problem with bitrate:
I have different videos with different fps and aspect ratios. I want outpout files with bitrate proportional to those two parameters. How to give a calculated bitrate to the command line and not a fixed one.

Now if you want to create your own front end you certainly could achieve a specific bit rate which by basing it on the original video size in frame count and pixel count you would get what you are trying for. This called putting the cart before the horse. Possibly desirable but impractical. If all the videos are taken with the same camera with the same settings this would be fairly easy. Just use the length of the video to figure out the target file size or do one calculation to figure out what bit rate you need to get your target QF. Then set up the program to use the same bit rate all the time.

I want to be a billionaire without working at it. The average person at most companies won't even be able to use the camera without training. Try some realism. To even remotely approach your goal you will have to standardize everything. The camera. The programs and the computer. One computer or a set of them all set up exactly alike. Possibly custom software as your requirement for using QF as the prime parameter instead of bitrate is simply backasswards and completely unnecessary.

If you really want to flog this dead dolphin and are willing to spend the bucks for the custom software that will be required maybe you can even sell the resulting software. It will be the first to do it that way. The program will have to do it exactly the way I laid out. The programmer will just lie to you by sticking a fake setting that masquerades as a QF setting but it will just do what I suggested. Much of programming is hiding the real methods behind a pretty facade.

I know already that. I want a simple batch file. We are not video professionals nor programmers. We do mechanical machines. But that exactly what I would do if I wanted professional results. Perhaps there is no solution with today tools as programs are oriented for purposes that are not mine.

I see you did say what codec. How did I miss it? Brain rot. OK Mpeg 1 which is I think 352x240 for pal. Oh and oops about some of the American slang. Forgot you were French.Why Mpg1? Its old has poor compression even in comparison to mpeg2 and the color gamut is poor. Has minimal usage outside of Asia these days.

For some technical and practical reasons. You may decide the size of the output, you are not restricted to 352x240. The output is not for medias like CD, DVD, BluRay... We don't write on medias anymore.

Forgot you were French.

My location is France. But is my mother tongue french?

[ronpub]

HCEnc (MPEG2 encoder) has a "Constant Quantization" single pass mode.
This seems to give a result similar to constant quality, though technically it isn't.

I use it for making quick DVDRWs I can watch once and delete.
The size of the file is unpredictable exactly, though you can estimate.

You can use the GUI, or a command line like:

P:\HCenc\HCenc_023 -i video.avs -o video.m2v -aspectratio 16:9 -pulldown -profile best -matrix qlb -frames all -cq_maxbitrate 4.5 -maxbitrate 8000

Input via AVS file.

Thank you, I will give it a look. Perhaps it does the same with mpeg1. Else it is possible I reconsider my position concerning mpeg1.

[45tripp]

it doesn't
mpeg2 only

ffmpeg will do mpeg1,
you can batch it,
and you can use a gui with batch job control, like
Avanti (look in a thread around the top of this section)


tripp

[AlanHK]

HCEnc (MPEG2 encoder) has a "Constant Quantization" single pass mode.
This seems to give a result similar to const

Thank you, I will give it a look. Perhaps it does the same with mpeg1. Else it is possible I reconsider my position concerning mpeg1.

No, HC is just MPEG2.

[Midzuki]

Good news! The Wikipedia article about "MPEG-1"
has been improved --- *much*.

Copy it while you can!

http://en.wikipedia.org/wiki/MPEG-1

[jagabo]

The free version of TMPGEnc has constant quality MPEG1 encoding. And some kind of batch processing (I've never used its batch processing so I don't know how flexible it is.)

I rarely do any kind of bitrate based encoding any more. I usually use constant quality or constant quantizer based encoding. That way I know what the quality will be regardless of frame size, frame rate, and nature of the video.

[vhelp]

@ Midzuki, the mpeg-1 source code has been around since nearly time begain

The mpeg2enc (include c source code) has always been one of my favorite resources, I even made a front end to it because it creates excellent videos, though very slow, prob much slower than TMPGenc
In one session with it, I even did my Laserdisc "Showgirls" and it was well worth it for the excercise I put it through a few years ago or so. But I still use TMPGenc as my prime encoder, bar none. Anyway.

. . .

Regarding MPEG-2 format encodings..

With the advent of HD and its resptective sub formats, there really is no more need to VBR a video, unless you are trying to squeeze more video onto one medium. In fact, it is in your favor to encode your videos with a CBR type function (unless your encoder was designed for VBR only or other reason) for the benefit of producing highest quality videos which are ultimately going to be HD archived one way or another.

(Note, when I say, "highest quality videos" I mean to say encoded near lossless or with less detail lost)

If you produce high bitrate encodes, you stand a better chance at retaining your INPUT source -to-new-format-source as your true master copy for future intermediate processing.

Ok. Look at it another way.. how many of you have taken a DVD and ripped it to your HDD and re encoded it to another (though lessor) codec format ?? That's right. We've all been there, done it. And the main reason why we always got very good transfer copies from these sources was because of the already high quality (high bitrate) they were instilled with. Its basically the same way when you encode your videos with a very high bitrate using the CBR form factor.

Everybody has a favorte MPEG encoder. Some prefer HC, and other MainConcept, while yet even others, like myself, LOVE TMPGenc. I'll go with tmpgenc because I have tried-n-true it ta death and I know exactly what I'll get out of it when I'm done. I guess its the same for you and your prefered mpeg encoder

-vhelp 4764

[Midzuki]

vhelp wrote:

@ Midzuki, the mpeg-1 source code has been around since nearly time begain

You don't say! And it was you yourself who wrote it, right? :P

But it's always good-news when someone manages to decrappify this or that
article @ wikipedia.org (MNSHO anyway).

P.S.: I still don't know which is worse ---
--- people who really don't understand what they read,
or people who like to pretend they didn't understand what they've just read.

[AlanHK]

Good news! The Wikipedia article about "MPEG-1"
has been improved --- *much*.

Copy it while you can!

http://en.wikipedia.org/wiki/MPEG-1

Why copy it?
Wiki articles are permanent. If someone vandalises one, you can always click on the "history" link to see previous versions, and restore it if you are sure.

[Midzuki]

Wiki articles are permanent.

My free e-mail accounts @ altavista.net were "permanent" too.

[AlanHK]

Wiki articles are permanent.

My free e-mail accounts @ altavista.net were "permanent" too.

And I got burnt with a "free for life iname.com address".

The difference is that Wikipedia is freely distributable. There are many, many clones online already (many with advertising added, still the data is the same). If Jimbo gets bored with it someone else can and will immediately replace it.
You can download the whole thing if you feel like it, but it would take a pretty serious disaster to make it disappear. After which you would probably not be very interested in video encoding afterwards (except perhaps Jericho reruns).

[Midzuki]

Wiki articles are permanent.

My free e-mail accounts @ altavista.net were "permanent" too.

And I got burnt with a "free for life iname.com address".

The difference is that Wikipedia is freely distributable. There are many, many clones online already (many with advertising added, still the data is the same). If Jimbo gets bored with it someone else can and will immediately replace it.
You can download the whole thing if you feel like it, but it would take a pretty serious disaster to make it disappear. After which you would probably not be very interested in video encoding afterwards (except perhaps Jericho reruns).

Long answer:

[ TO BE WRITTEN ]

Short answer:

Your blind confidence in certain aspects of the "modern" world is really pathetic.

[AlanHK]

Long answer:

[ TO BE WRITTEN ]

Short answer:

Your blind confidence in certain aspects of the "modern" world is really pathetic.

Your rudeness is even more so.

No hurry with your "long answer". I won't bother to read it.

[Midzuki]

Truth hurts only while you don't want to say good-bye to illusion.

No hurry with your "long answer". I won't bother to read it.

I was not going to write it anyway.

[AlanHK]

Truth hurts only while you don't want to say good-bye to illusion.

No hurry with your "long answer". I won't bother to read it.

I was not going to write it anyway.

So you're a liar as well as an *******.

[45tripp]

Wiki articles are permanent.

My free e-mail accounts @ altavista.net were "permanent" too.

that was funny

I was not going to write it anyway.

So you're a liar as well as an *******.

that was funnier


i wonder how ronpub is getting along with the initial problem

[ronpub]

i wonder how ronpub is getting along with the initial problem

Bah
My time is now over to solve this issue. I will get time free for that in September.
For sure now, its more long to find info in this thread.

[Ethlred]

i wonder how ronpub is getting along with the initial problem

Nice to see that someone remembers what the thread is about.

Ronpub seems competent. The main difficulty I see is trying to get all the different sources to work without a huge amount of work. It depends on if he wants all the sources to remain as they were except converted to Mpeg1. Simplest thing to do would be to convert them all to a single width while using the hight to maintain aspect ration. Resize them all, although that would lose quality on those that don't need it sure would simplify.

Mediacoder might do the whole thing, given the concept above, assuming it didn't crash. Might as well assume the weather won't change though.

[45tripp]

Mediacoder might do the whole thing, given the concept above, assuming it didn't crash. Might as well assume the weather won't change though.

that's pretty funny too,
but i find it hard to laugh at crashes.

My time is now over to solve this issue. I will get time free for that in September.
For sure now, its more long to find info in this thread.

there've been some recommendations.
of encoders,
of bitrate setting, use constant quant
you could resize all input to a single output resolution, that's easy.
you could output the same framerate for all too, again easy,
but depending on input it may not always be smooth.

in other cases you'll have to set out your own conditions
to a batch of your own.


tripp

[Midzuki]

To whom this may concern,
to remain "on-topic" is not a good excuse for not correcting blatant misinformation
about "obsolete" video compression methods.

[45tripp]

i resent to term 'obsolete'.

if you're saying mpeg1 has no uses,
you're wrong!

but, ronpub hasn't said enough to help determine codec selection.

[Midzuki]

45tripp wrote:

i resent to term 'obsolete'.

if you're saying mpeg1 has no uses,
you're wrong!

I don't think MPEG-1 is obsolete, but other people do.
That's the reason why I enclosed that word with quotation marks.

AlanHK wrote:

So you're a liar

That's just your "enlightened" opinion of course.

[Ethlred]

To whom this may concern,
to remain "on-topic" is not a good excuse for not correcting blatant misinformation
about "obsolete" video compression methods.

If that was all you and AlanHK were doing no one would be off topic. However you and he had a tomato tossing contest instead. You were the primary driver in the off topic direction. He didn't help.

Copying the Wikepedia page does make some sense. Wikipedia has some strange politics and just plain idiotic behavior. Turning that into a general rant is different. Much of Wikipedia is done by people that actually know what they are talking about but the whole thing could disappear in a fairly short period of time, after all this the internet we are talking about. However some things do last on the net and it wouldn't surprise me if Wikipedia outlasted the usefulness of Mpeg1.

I found the comparison of mpeg1 layer 2 versus layer 3 interesting. I do suspect the main contributor has religion though. Maybe not as he could be spot on. The lack of applause in the AAC test is a bit telling.