'Which' video bitrate should be reported for a file?

azntimm · Post by **azntimm** » Fri May 28, 2004 11:02 am

I had just gotten a cReq granted where I changed the video bitrate (among other things) for a file as based off the AOM client and I got this message back:

nwa wrote:granted
but you should use other clients than AOM for codec checking for now since that feature is far from being complete, use GSpot or something similar.
Both videobitrates are correct, just AOM doesn`t take overhead into account so it`s smaller

I used to use Gspot for my codec stuff and finding bitrates for files I'd add to AniDB, but I kept getting my entries changed to other values, which I came to realize were the values produced by AOM. From then I just assumed people wanted the AOM bitrates, so I used AOM to check file bitrates from there on out.

If AOM doesn't take into account overhead, maybe that would be the best bitrate to report on AniDB? I suppose people are using the videobitrate stuff as an arbitrary measure of video quality (despite there being many other factors), so I'd assume they'd want the value that reflected the bitrate of the actual video information and not any overhead type data incurred because of whatever container is used or whatever.

In short:
What is the 'preferred' method of finding a video bitrate for a file to be added to AniDB?

wahaha · Post by **wahaha** » Fri May 28, 2004 12:36 pm

I wouldn't care one bit (pun intended) about the neglectable difference between AoM and GSpot. IMO, you should use what you like as long as the value is not too far off (e.g. +/- 1%).

Of course, AoM's bitrate-detection for avi files is known to have failed in few occasions*, but since it's correct most of the time, I wouldn't disencouarge using these values.

*) A human sanity-check should quickly rule these values out, though... e.g. "(video_bitrate + audio_bitrate) * 7.5 * ep-length-in-minutes =~= filesize"

Skywalka · Post by **Skywalka** » Fri May 28, 2004 12:47 pm

I object.

audio bitrates should be a multiple of 2 (or better

if the file is NOT a VBR MP3. Usually you'd have 128 or 96 kbit MP3 audio. This goes for AVI files.

OGM files differ from that but to get the information about the bitrate of the OGM audio part you'd have to use VirtualDubMod anyway...

Post by **nwa** » Fri May 28, 2004 10:06 pm

well you see
AOM often doesn't give any information for the .avi file not to speak of .ogm
For instance WMV9 is not handled by AOM, no audio no, video info.
GSpot has no problems with them and can give you some info with .ogm and .mkv files as well, it can't give the bitrate for video but can for audio.

I agree, the difference between gspot and AOM is often like 6 kbits or so...
If the file is avi with XviD or with any DivX codec then no problem, you'll have a problem when AOM doesn't give you any info at all... then you'd need to use something else

Now that I think about it... my comment was unnecessary

The audio bitrates are mostly the same for both, on some occasions I've seen AOM have different bitrate by 1 kbit than Gspot tho...

Post by **PetriW** » Fri May 28, 2004 10:44 pm

Just fyi the bitrates change between GSpot versions too so don't assume GSpot is always right.

(Gotta defend BennieB!!)

Skywalka · Post by **Skywalka** » Sat May 29, 2004 2:19 am

yeah sure but not when it comes to MP3 bitrates if the bitrate is constant while info from BennieB tended to make some errors there too (for instance 127 more than once when the bitrate was MP3 constant 128).

On a second note I have to admit my GSpot always shuts down when I try to open OGM files so I guess it is better to use VirtualDubMod

Post by **PetriW** » Sat May 29, 2004 5:03 am

Didn't VirtualDubMod give lower bitrates than GSpot too?

wahaha · Post by **wahaha** » Sat May 29, 2004 10:51 am

Vdub(mod) doesn't take the overhead into account while gspot does, which is why gspot's bitrates are higher... the last time I tested it, AoM's bitrates were around those displayed in Vdub(mod).

nwa wrote:For instance WMV9 is not handled by AOM, no audio no, video info.

That's not exactly true. AoM can handle standard Open DML avi files, regardless of their codec... it just can't cope with the way certain wmv-using groups encode their avis

Post by **PetriW** » Sat Jun 12, 2004 5:23 pm

AOM 0.6 will give same bitrates as GSpot! (Well, at least it did give the same for these 20 files I checked.)

Skywalka · Post by **Skywalka** » Sat Jun 12, 2004 9:11 pm

first of all: w00t!

Second I have to say that the bitrates for video differ from every application to the next... beeeeeeeecause:

All video codecs are variable, meaning they are all varying the bitrate from frame to frame.

Therefor the bitrate number given is wrong anyway. The only thing you can calculate is the Filesize / Video length. That's all.

Now the differences occor because some of the programs don't calculate the header information to be part of the whole file, some do, same applies to audio bitrate and those two factors influence each other which results in 4 possible values in the end if all programs get the same size for the header for both audio and video. If they don't, then there are more possible values.

Anyway, I only demand even values for fixed bitrate MP3s, everything else I don't correct as long as the video bitrate is within 1 to 10 kbit/s. More than that get's corrected by me -> creqed.

Although I don't do that anymore. I am fine with using AoM and as soon as 0.6 is out there won't be any more reason not to let AoM do ALL the work.

YEAH! PetriW rules

No more manual creqs, everything automatically. I love you dude

(well except for the release dates and the "crc checked" value which count the most in my humble opinion).