Is it better to encode at anamorphic (full) resolution ?

[exrty]

Hi,

Maybe some of yours have an idea on this subject..

If i have as many cdr to encode a movie. Is it better to encode at 720x576 (PAL) or 720x480 (NTSC) to keep max details of the movies and the player will correct the ratio lines/columns so the dvds do ?

Is the brain more sensitive to vertical resolution than horizontal res ?

Thank you for your advises..or observations

Regards

exrty

[Dams]

Hi exrty,

I personaly test some rip that I made, with anamorphic and no anamorphic format (with crop), and I don't distinguished any quality improvements. (on TV 16/9, 70cm)

But I think it will be interessant, for the future, in order to be look on HDTV, or now with overhead projector, because these are enabled for see movies on a larger view.

Regards

[Teegedeck]

It can look better on some movies that are very compressible (you don't really want to use more than 3 CDs for a movie do you?) when watched on a monitor with 1024x-resolution. Do a search. BTW, the topic is hardly XviD-related.

[exrty]

That's not very xvid related, you're right. But sorry i use xvid and there's no general divx forum for this on doom9's forum.

Thank for yours comments. I plan to get a DLP in the future and regarding the price of cdr, i don't want to lost any quality even if i have to use, 2,3 or more cdrs...

Regards

exrty

[ChristianHJW]

In terms of usable players for your movies you would screw compatibility with simple players that dont have a resizing function, like WMP 6.4 .

A much better way of doing it ( and here we are back on the subject, XviD, again ) would be to include a Aspect Ratio Flag into the codec header, just like MPEG2 does. I was told from Arpi, the main developer of mplayer, that this is included in the MPEG4 specs. suxendrol on the other hand had informed me that the new XviD internal API ( XviD API 3 ) will support writing an AR flag into codec header.

The only problem here is that current Dshow filters for playback dont read the flag. I guess Milan's FFDshow could be easily adapted to read and respect such a flag, as its coming with a resizing filter already ( not sure about XviD decoder here ), so every Dshow based player could correct AR on playback.

I wont discuss the purpose of using other ARs than 1:1 in XviD encodings here, its just some input about technical feasibility with XviD.

( No, i will not mention that MCF will have a separate AR flag for those codecs that cant support such natively ;) ... could be very useful, like for correcting movies with incorrect AR caused by wrong encoding setup )

[exrty]

Which is the minest modulo the size should be ?
8 modulo for horizontal and vertical ?

[ChristianHJW]

Sorry to bring this up again folks.

Any progress here ? I heard Linux people are already implementing the flag ? If they do so we would find ourselves in a situation where we cant view XviD videos created with mencoder in Windows, at least only with players that support manual resizing, and not in WMP 6.4 etc.

I dont think its a big issue to do ?

Milan, could you read the flag from codec header in ffdshow and resize accordingly ?

Anybody knows how exactly the flag is put into MPEG4 codec header for specs compliancy ?

[milan]

ffdshow needs to know output video size before receiving actual compressed stream. The only way would be to store global mpeg4 headers (I don't know whether they contain aspect ratio info) after VIDEOINFOHEADER in AVI. This header is passed to ffdshow in filter negotiation phase and can be used to compute output video resolution. Better solution (but I'm not sure if possible) would be to use the VIDEOINFOHEADER2 structure which contains fields to specify aspect ratio. MPEG2 video uses it.
I don't know how mencoder is doing this, I'm using just mplayer.

[cjv]

I have been playing around with this today..and managed to hack xvid so that you can choose the aspect ratio. I was able to encode 352x480 xvid avi files in windows/Vdub..and play them back in Linux/mplayer with it automatically detecting the aspect ratio and playing back at 640x480.

The aspect ratio appears to be stored in the VOL header, and it is part of the MPEG4 stream even in the AVI file, because when they are demuxed and remuxed into a valid mp4 container, mplayer still recognizes the aspect ratio.

I basically added this to bitstream.c:

BitstreamPutBits(bs, 0xF, 4); // custom aspect ratio
BitstreamPutBits(bs, 0x4, 8);
BitstreamPutBits(bs, 0x3, 8);

The MPEG4 specs appear to have predefined aspect flags, much like MPEG1/2..but mplayer doesn't appear to support this. By using the 0xf, I was able to define my own user-defined aspect ratio and keep compatibility with mplayer.

If I've gone about this the wrong way, I hope someone will correct me, but as far as I can tell from reading the MPEG4 specs, the bitstream appears valid and plays back correctly in all windows players, (but just ignoring the aspect flag of course)

cjv

[milan]

Is it possible to download this AVI? I would like to test it and perhaps modify ffdshow to handle aspect ratio info (if possible).

[milan]

I'm sorry, I forgot to mention that I'm behind the firewall and can't download files with AVI extension. Please rename or pack them.

[ChristianHJW]

milan, cjv,

i am happy we finally get this on the way, but please link to MPEG4 experts like -h here and maybe even drop mails to the xvid-devel and the mplayer-devel ML's about your implementation, we have to be absolutely sure we do this according to MPEG4 specs.

( Sidenote : The MCF container will store an additional AR flag in the track header, so that also those codecs without such a flag could use different pixel aspect ratio than 1 : 1 . This will only be possible with MCF 'native' streams, as only in this case the MCF parser will connect to the video renderer directly, while the decoder is called from the parser with UCI. It is still to be decided if the MCF track AR flag ( actually its a pixel size flag ) should give the final AR, or if the total AR should be the result of a calculation like

Total AR = codec AR x MCF AR

In first case MCF would have to know where the codec flag is and be able to read it, means we would have to support writing the MCF AR flag from the encoding apps, depending on the codec that was used used. This is not a problem for encoding apps, but a huge problem for simple Dshow based muxers, so i vote for 2nd option. This would also allow to use the MCF flag as a kind of 'correction factor' for old AVIs with screwed AR )

[cjv]

@milan:
http://members.shaw.ca/cjv99/XviD-16x9.zip
http://members.shaw.ca/cjv99/XviD-4x3.zip
(hope this works)

@ChristianHJW:
I actually started this for my own personal needs (encoding music videos), but saw this thread and thought it might apply. (I'm currently doing the VFW interface)

Yea, I really hope someone will look over this (all I did was add those 3 lines to bitstream.c). I did spend a _lot_ of time reviewing various MPEG4 sources on aspect ratios (and a _lot_ of hex editing)..so I am pretty confident. :)

cjv

[Koepi]

Hi,

cjv, take a look at this:

http://list.xvid.org/pipermail/xvid-devel/2002-October/001109.html

There you have the proper use of the DAR flags.

I read this thread and discussed it with suxen_drol a bit, and we're going to add proper support for it.

I hope this helps,

regards
Koepi

[ChristianHJW]

http://article.gmane.org/gmane.comp.video.xvid.devel/896
http://news.gmane.org/thread.php?group=gmane.comp.video.xvid.devel&first=251&last=300
http://news.gmane.org/thread.php?group=gmane.comp.video.xvid.devel&first=201&last=250

Topic was : 'aspect ratio'

[milan]

libavcodec returns aspect ratio (1.3 for XviD-16x9.avi and 1 for XviD-4x3.avi), but only after decoding first frame which is too late. All what I could do in that moment would be to change aspect ratio similar way as aspect ratio slider on resize&aspect page: keep original video resolution (352x480) and resize the picture within those boundaries - definitely bad solution.
I realy think XviD VFW should be modified to store global headers (or aspect info only) after VIDEOINFOHEADER. For example HuffYUV uses this to store huffman tables.

[cjv]

Thanks Koepi,

If you only knew how much source I looked through today..I found it difficult to find anything exact about MPEG4 on the web. This is _exactly_ what I was looking for (fortunately it appears my way was was correct..I just used the extended). I couldn't find how to search xvid mailing lists?

cjv

[ChristianHJW]

Originally posted by cjv
I couldn't find how to search xvid mailing lists?]

http://search.gmane.org/cgi-bin/search.cgi

Group name : gmane.comp.video.xvid.devel

Or better even : use your newsreader news://news.gmane.org

[ChristianHJW]

Originally posted by milan
[B]libavcodec returns aspect ratio (1.3 for XviD-16x9.avi and 1 for XviD-4x3.avi), but only after decoding first frame which is too late. All what I could do in that moment would be to change aspect ratio similar way as aspect ratio slider on resize&aspect page: keep original video resolution (352x480) and resize the picture within those boundaries - definitely bad solution.

Agree here Milan, this is in fact a solution that is not very nice.
Thanks for pointing this problem out to me, its very valuable input we have to consider for handling of the MCF AR flag. Big advantage for us is that the MCF Dshow parser will call the video renderer directly, and have the video stream decoded in an external decoder called via UCI. This way we should be able to read the AR flag from MCF track header before calling the video renderer, and set resolution accoridngly.

I really think XviD VFW should be modified to store global headers (or aspect info only) after VIDEOINFOHEADER. For example HuffYUV uses this to store huffman tables.

Maybe a small 'hack' , but definitely a good and necessary one without any major problems to expect, as only those Dshow decoder filters being compatible with XviD would need it, as long as nobody will change the FourCC to something stupid like 'dx50' . And Linux based players can read the original flag in the MPEG4 codec header instead, so they dont have to care about the extra field at all ( we just have to make sure both have the same content, that is ).

[cjv]

I have compiled XviD, using the simple aspect ratio flags in the header (from the thread Koepi posted above).
I tried both:
BitstreamPutBits(bs, 0x3, 4) // NTSC 4:3
and
BitstreamPutBits(bs, 0x5, 4) // NTSC 16:9

Unfortunately, mplayer does not recognize the simple flags, and still says "Aspect ratio undefined." It appears that mplayer checks for the extended flag, and determines user defined aspect ratio from that.

cjv

[ChristianHJW]

Originally posted by milan I really think XviD VFW should be modified to store global headers (or aspect info only) after VIDEOINFOHEADER. For example HuffYUV uses this to store huffman tables.

No coments from the XviD dev team here ?

milan, could we test some files with your filter somehow ?

[milan]

ffdshow doesn't fully support the aspect ratio information yet. Now it works only with Overlay Mixer enabled, where ffdshow just passes aspect ratio to that filter and let it do the scaling.
I'm now working on ffvfw again. I want to support more libavcodec's encoding algorithms (MPEG, MJPEG, HuffYV12) and of course I would like to add the handling of the aspect ratio information.

[trodas]

Hello, dudes (milan too :D )!

So, what happens with the DAR usage from december 2002? :)
I would like to see it working sometime, as facing necesary conversion of SVCD i see as definitively bad idea do the resize and then encode the resized data - since it will pressure much on the quality/bitrate... :rolleyes:
And one sure will agree with me, that its damn diference to encode 480x336 pixels, than encode 768x336 pixels :mad: :(

Any way how to set DAR flag will be handy. But using VDum mod 1.5.1.1a i don't see any way to set it there for the Xvid... :(

Any help, or the problem is not adressed yet? :confused:

[SeeMoreDigital]

So the original question is.................. Is it better to encode at anamorphic (full) resolution ?

My answer would be................. It depends on the input source and the output monitor you view your encodes on!

I now encode all my DVD backups in anamorphic (720w x 576h PAL and 720w x 480h NTSC) because.... 1, the encode is the same pixel size as the source and 2, I am able to view my encodes via a 16:9 (1.77:1) monitor.

More pixels = more resolution (good) = larger file sizes (shame).

[trodas]

Well, let me put it this way - how to set a DAR flag, when i need to tell BSplayer/ffdshow to enlarge the 480pixels to 768? :rolleyes:

[Sagittaire]

It seems me to have read some share which the human vision is more senssible with the vertical resolution than has the horizontal resolution. Thus to a number of pixel are equivalent a 480*480 resolution will give a better visual impression than a resolution in 720*320 for exemple ... ;)

[Assault]

@ trodas

You can set the AR in matroska. All you have to do is to mux your XviD/DivX avi with mkvmerge into a matroska file and set the right aspect ratio in that program. For playback you have to use ffdshow with overlay mixer enabled.
Hope that helps. ;)

Assault

[symonjfox]

Ok, we know that Matroska have this flag.

But, in the REAL MPEG4 format and MP4 container, how can we set it? As far as I read before, the AR is in the header of MPEG4 video stream, not in the container itself, so since Xvid dev3 supports it, it would be nice use it NOW for later MPEG4 DVD players that will use Anamorphic resolutions.

PS: I'm a DVB capturer and so it's very important feature for me, since most channels are 352*576 or 544*576 and so on, up to 720*576.
PS2: I have already asked for this, but everyone says that in AVI it will be an hack, in Matroska is supported and in MPEG4 Xvid dev3 already has it ... but will it be usable in Dev4?
PS3: read my signature :D

[bond]

me too likes it mpeg-4 spec compliant :p

[ChristianHJW]

Originally posted by symonjfox but everyone says that in AVI it will be an hack

Not true, you may use the flag fine in AVI .... but then you cant play your file with DShow decoder filters, as discussed here many times.... mplayer cygwin port and VLC win32 binaries may work fine, but for Dshow some hackery was required, unless somebody will code a new AVI parser filter ...

[trodas]

Sagittaire - im perfectly aware of this (that's why DVD are scaled into horizontal axis from 720 to 853 pixels), but its not relevant. So, no answer to my question at all. I just need it, because i feel that encoding 480x336 is easier, faster and should give better results, when then played at 768 pixels, that encoding 768x336 pixels - what push on bitrate too much, IMHO.
And im not invented the crappy only 480 pixels wide SVCD, so... Im not responsible for this situation :rolleyes:

Assault - all right, but the last thing i want is to use something new, what probably have own quirks and with what im not experienced. Futhermore, with no disrespect to matroska developers, the very last thing i want is a new standard. Let's fix old, but do NOT push on new one. There are already too much "standards"...
Anyway, your solution perhaps can work, but will it BSplayer play it? M$ crap is out of question, but will BSplayer work?

"Version 0.86 Build 497 released (16.6.2003)
- Fixed crash when MP3 was paused
- Support for Matroska format, you have to install Gabest Matroska source filter"

And this is working? Properly?

symonjfox - as i understand, it don't looks like a format, but a container problem. Like that AVI don't like the DAR flags much, or such... Tought, i read there how Milan, FFDshow autor, suggested to add it...

ChristianHJW - okay, so, how can i set the DAR flag and what player i need to get it working? :confused:

[ChristianHJW]

Originally posted by trodas ChristianHJW - okay, so, how can i set the DAR flag and what player i need to get it working? :confused:

trodas, it absolutely makes sense to encode SVCDs without resizing, and using AR flag. Short Guide :


1. Encoding

Encode your SVCD source into XviD/DivX AVI ( using whatever program ), dont resize, just crop away the black bars on top and bottom


2. Get mkvtoolnix win32 binaries

Get the latest win32 binaries of 'mkvtoolnix' from Mosu's matroska site (http://www.bunkus.org/videotools/mkvtoolnix/), the win32 build should be here (0.5.0) (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.5.0.zip)


3. Setting AR tag with mkvmerge

Extract the mkvtoolnix binaries into any folder and then run a command line like this

x:\\mkvtoolnix\mkvmerge.exe -o MyMovie-with-sound.mkv --aspect-ratio 16/9 source.avi audiosource.ogg

while audiosource.ogg can also be audiosource.mp3, audiosource.ac3, audiosource.dts or audiosource.aac, of course you can also add a couple of audio tracks. The AR tag '16/9' can be any combination of numbers you want, even a float will do ( like 2,35 for anamorphic DVDs )

A precise description of all the CLI options is here (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html)


4. Playback

For playback you have the following options :

a. TCMP (http://corecoded.com) with the matroska CDL plugin (http://corecodec.homeunix.org:8884/plugins/MatroskaCDL.exe) installed ( will work with any codec/decoder filter )

b. ffdshow-alpha from 23rd May, in conjunction with any DShow based player ( WMP 6.4/7/8/9 , Zoomplayer, BSplayer, etc. ) and either Gabest matroska splitter (http://sf.net/projects/guliverkli) filter or 'official' matroska parser filter mkxds.dll 0.4.3 (http://matroska.free.fr/downloads/dsf/mkxds-v0.4.3.zip), both will work ( for Win9x check the matroska download page (http://matroska.free.fr/downloads/downloads.html), which contains the convenient matroska download pack (http://matroska.free.fr/downloads/MatroskaPack%20v0.4.3.zip) also ).

You have to activate 'use overlay mixer' in the ffdshow 'codecs' setup page, and AR correction will work with every normal DShow based player, but only for those codecs that are supported by ffdshow ( dont know if there are any codecs that are NOT supported by ffdshow :D )

c. Gabest Mediaplayer Classic, also from the Guliverkli homepage (sf.net/projects/guliverkli) together with ffdshow alpha and his matroska splitter filter

d. VLC, Videolan' great player, will support AR correction from next release ( 0.6.1 ), win32 binaries are on http://www.videolan.org . Its working on Linux, Windows and MacOSX .

e. mplayer , the great Linux player from http://mplayerhq.hu works perfectly for matroska files already since almost 2 months ( thanks to Mosu ), including AR correction, win32 binaries work together with cygwin.dll, and its also avaialbel for MacOSX and BeOS

5. Subtitles

When muxing the source AVI into a MKV with Ogg/MP3/AC3/DTS/AAC audio you can also add any number of subtitles streams in .srt ( SubRip ) or .ssa ( SubStationAlpha ) format, in the same run, or add them afterwards. The precise CLI command of mkvmerge is available at the link i gave above.


Is that what you wanted ;) ... ?

[Assault]

@ ChristianHJW

Will it be possible to set the AR in VirtualDubMod in the future? I like VDM much more than mkvmerge for muxing because VDM produces less overhead.

Assault

[BoNz1]

I think you can set up mkvmerge so that it will have the same overhead as vdm but really this has nothing to do with xvid, first read the readme for mkvmerge and then go into vdm and go to options>preferences>matroska and then set it up to mux with these options only and the files should have the same or very close overhead, I think. But again sorry don't really see how this entire thread relates to xvid you can encode anything anamorphically and play it back with the proper tools. ;) I don't want to make anyone mad at me but this is the truth I think.

[Animaniac]

Originally posted by Assault
@ ChristianHJW

Will it be possible to set the AR in VirtualDubMod in the future? I like VDM much more than mkvmerge for muxing because VDM produces less overhead.

Assault

A way to do it through Gabest's DSF Muxer would be my choice. Right now I take the video AVI and transmux it with AR to Matroska using mkvtoolnix. Then I mux everything using the DSF, which passes the AR flag to the final MKV. I prefer GUI of CLI anyday...

[trodas]

ChristianHJW - thanks for the ultimate guide how to do it, but, unfortunately, its not what i wanted. Frankly - i can make it, easily, but i don't like installing new software, don't like new formats and the biggest problem so far is the poor support of the new format into players - and the need for aditional filters to be installed.
The truth is, that other users problably don't make it, so, doing it properly but just for me is a waste of time.
So, Xvid don't support DAR, nor the VirtualDubMOD, and that's the curent state.
A bit sad.

Assault - i vote for this too!!!

BoNz1 - but the problem is, that for most simple users these "proper tools" are entierly out of scope for real usage, so, either using and setting DAR will be possible for standard Xvid movies, or the solution is not ready for public usage.

Animaniac - i better stay of from troubles like that - i don't want to be the only one, who can play the result... :rolleyes: :mad:

[Wilbert]

BoNz1 - but the problem is, that for most simple users these "proper tools" are entierly out of scope for real usage, so, either using and setting DAR will be possible for standard Xvid movies, or the solution is not ready for public usage.
What are you talking about? XviD is a codec, doesn't care about dar's. And setting the DAR in an AVI won't be possible, while it is in MKV. You can set it with MKVmerge, and the newest ffdshow supports it. I have no doubt it will be possible in vdubmod one day.

[ChristianHJW]

Huh ? Installing a DirectShow filter for matroska is too much for them ? How do you make XviD working on their machines ?

Originally posted by trodas So, Xvid don't support DAR, nor the VirtualDubMOD, and that's the curent state. A bit sad.

You obviously didnt understand any of the things explained above ;) ... . For VirtualdubMod you are right, for XviD you are all wrong, it supports AR flag already fine, just use mencoder to make the AVIs and mplayer ( both Linux ) to play your XviD AVIs, works perfect. The problem that its not working on Windows with DirectShow is an imminent problem of the DShow architecture in combination with standard M$ AVI parser, and not an XviD problem. Again, it could be done fine ( using VIDEOINFOHEADER to store the DAR value ), but 95% of the AVI handling apps, including players, couldnt handle it correctly.

BoNz1 - but the problem is, that for most simple users these "proper tools" are entierly out of scope for real usage, so, either using and setting DAR will be possible for standard Xvid movies, or the solution is not ready for public usage.

This is where i agree with you, we have to make MKV creation for AR handling easier. Just give us some time, it will be done ...

Animaniac - i better stay of from troubles like that - i don't want to be the only one, who can play the result... :rolleyes: :mad:

What can i say, last time i checked half of the available MPEG2 DirectShow filters couldnt handle the AR flag in SVCD MPEG2 streams correctly, and were playing the movies with incorrect AR ;) .... for MKV files all you have to do is to use a special player ( TCMP with the CDL plugin ) or use ffdshow .... is that really that difficult ? After all, all matroska apps will be able to handle the AR correctly, thats guaranteed ;) ...

[ChristianHJW]

Originally posted by Wilbert XviD is a codec, doesn't care about dar's. .. sorry mate, thats not correct, the MPEG4 video header has a AR flad specified and setting it is supported by XviD since dev API 3, and fully MPEG4 spec compliant ...

[Animaniac]

Originally posted by ChristianHJW
What can i say, last time i checked half of the available MPEG2 DirectShow filters couldnt handle the AR flag in SVCD MPEG2 streams correctly, and were playing the movies with incorrect AR ;)

How are the (working) MPEG-2 DSF handing AR embedded in the video stream? As far as I understand, MPEG-4 streams with an embedded AR flag cannot be correctly played due to limitations of DirectShow. Does MPEG-2 have a flag in the container a la Matroska? If not, then why can't ffdshow adopt an AR handling similar to MPEG-2 filters.

P.S. Which MPEG-2 filters produced the correct results? Microsoft? MainConcept? Thanks.

[ChristianHJW]

Originally posted by Animaniac How are the (working) MPEG-2 DSF handing AR embedded in the video stream?
Easy. The MPEG parser filter will read the AR flags from the MPEG stream and pass it on to the decoder filters. Thats what AVI parser filter cant do, because AVI itself has no AR flag. And the AR flag from the MPEG4 header that is muxed into the AVI can only be read AFTER the graph is already built ..... thats the whole problem ....

[Animaniac]

Originally posted by ChristianHJW
Easy. The MPEG parser filter will read the AR flags from the MPEG stream and pass it on to the decoder filters. Thats what AVI parser filter cant do, because AVI itself has no AR flag. And the AR flag from the MPEG4 header that is muxed into the AVI can only be read AFTER the graph is already built ..... thats the whole problem ....

Ah, I see. Just another reason AVI is not the best choice. ;)

Does the 3vix MP4 parser read the AR flag correctly? I would assume it should...

[Sgt_Strider]

Originally posted by ChristianHJW
Huh ? Installing a DirectShow filter for matroska is too much for them ? How do you make XviD working on their machines ?



You obviously didnt understand any of the things explained above ;) ... . For VirtualdubMod you are right, for XviD you are all wrong, it supports AR flag already fine, just use mencoder to make the AVIs and mplayer ( both Linux ) to play your XviD AVIs, works perfect. The problem that its not working on Windows with DirectShow is an imminent problem of the DShow architecture in combination with standard M$ AVI parser, and not an XviD problem. Again, it could be done fine ( using VIDEOINFOHEADER to store the DAR value ), but 95% of the AVI handling apps, including players, couldnt handle it correctly.



This is where i agree with you, we have to make MKV creation for AR handling easier. Just give us some time, it will be done ...



What can i say, last time i checked half of the available MPEG2 DirectShow filters couldnt handle the AR flag in SVCD MPEG2 streams correctly, and were playing the movies with incorrect AR ;) .... for MKV files all you have to do is to use a special player ( TCMP with the CDL plugin ) or use ffdshow .... is that really that difficult ? After all, all matroska apps will be able to handle the AR correctly, thats guaranteed ;) ...

What's mencoder? If I am not mistaken, you're telling me that xvid currently have the ability to set the AR flag? If so how come I don't see that option in the Keopi's latest xvid build? Will xvid 1.0 be able to set the correct aspect ratio in its final form? Even if it does work, you're saying that with dshow filters have limitations and it won't display the whole image properly so only when played under linux is when it'll be done correctly? Thx

[ChristianHJW]

Originally posted by Sgt_Strider What's mencoder? If I am not mistaken, you're telling me that xvid currently have the ability to set the AR flag? If so how come I don't see that option in the Keopi's latest xvid build?

mencoder is a CLI based video encoder, working on Linux.

Will xvid 1.0 be able to set the correct aspect ratio in its final form?

:sigh: .... is it so hard to understand ? All that you guys see from Xvid if you configure it is the VfW GUI. But as xvid can be used on many different platfroms it has another, internal API called dev API ( there is ver 3 and ver 4 ) and there you can set the MPEG4 AR flag just fine, and mencoder does that ...

Even if it does work, you're saying that with dshow filters have limitations and it won't display the whole image properly so only when played under linux is when it'll be done correctly? Thx

Even on DirectShow you will see the full picture, but not in the corrct AR ....

[Stux]

Does the 3vix MP4 parser read the AR flag correctly? I would assume it should...

that's 3ivx btw ;)

It depends on a few things, The mp4 needs to be muxed correctly, and the decoding filter needs to read the DecoderConfig from the VIH (this way it gets the config before having to decompress a frame)

We were considering having the mp4 parser actually parse the AR and then set the AR in the outgoing VIH, but I think we'll do it in the video filter... maybe, whatever.

Point is, you probably don't want to be using AVI if you start playing with real MPEG-4 features.

The 3ivx MP4 Splitter currenty passes DecoderConfig at the end of the outgoing VIH

[Animaniac]

Originally posted by Stux
that's 3ivx btw ;)

It depends on a few things, The mp4 needs to be muxed correctly, and the decoding filter needs to read the DecoderConfig from the VIH (this way it gets the config before having to decompress a frame)

We were considering having the mp4 parser actually parse the AR and then set the AR in the outgoing VIH, but I think we'll do it in the video filter... maybe, whatever.

Point is, you probably don't want to be using AVI if you start playing with real MPEG-4 features.

The 3ivx MP4 Splitter currenty passes DecoderConfig at the end of the outgoing VIH

Sorry, I keep making that typo. -_-;

I don't know much about the data structure passed between filters, so could that be put in lamen's terms? >.< Does it work similar to Matroska, insofar as the AR is just passed to ffdshow and then down to VMR?

[Stux]

Filters pass two things two each other, when configuring the connection they pass a structure, the VideoInfoHeader (or perhaps VideoInfoHeader2) whatever it is, I forget the details :)

Now, that contains stuff like width, height, bitrate, fourcc, etc

And when actually processing the stream they pass the bitstream

MP4 has some metadata for every stream, which is where the needed codec configuration parameters are placed. Most MPEG-4 Video encoders which output to avi use a kludge where they store this in the actual bitstream.

If you only read that info from the bitstream then you can't get to it until after you've recieved the first frame.

The 3ivx MP4 splitter solves this by appending that crucial out-of-band information onto the end of the VIH so it passes around a larger than normal VIH, and at the end of the VIH is the codec config parameters...

This happens for both video and audio streams.

[symonjfox]

--------------------------------------------------------------------------------
Will xvid 1.0 be able to set the correct aspect ratio in its final form?
--------------------------------------------------------------------------------
:sigh: .... is it so hard to understand ? All that you guys see from Xvid if you configure it is the VfW GUI. But as xvid can be used on many different platfroms it has another, internal API called dev API ( there is ver 3 and ver 4 ) and there you can set the MPEG4 AR flag just fine, and mencoder does that ...
Well I think it wouldn't be a bad idea add the AR setting in the VFW interface. For example I could transcode a DVD 16:9 to Xvid 16:9 without resizing it, just manually setting the AR flag.
I know that on Linux it works, but me and most users, just have Windows and they are happy with it. Avi file is old. I think that using MPEG4 stream in AVI is a stupid thing. MPEG4 strams are made for MPEG4 container (or another advanced container such matroska).
The playback is not important ATM because I think that future MPEG4 DVD Players, will off course support AR flag.

I'm tired of 1:1 AR setting that drives me crazy while calculating the right resolution to use after cropping ...
:confused:

Cheers

[Flux]

Is it better to encode at anamorphic (full) resolution ?
When compressing PAL DVD-movie which aspect ratio is 2.35:1, you have 720x576 frame which has usually anamorphic 720x435 video data and the rest is black.

If you strech the frame to original 2.35:1 ratio with full vertical resolution, it means 1024x435 frame if you do crop. So which one will compress better, the anamorphic 720x435 frame or 1024x435 frame with correct aspect ratio? I assume that anamorphic is a lot better choice when looking how much pixels there is. You can always resize it via ffdshow using quality resize algoritm but it takes some CPU time.

[SeeMoreDigital]

Hi Flux, welcome to the forum.

Yes, this is true 435 is the exact 'image' pixel count. The rest being the black matte.

For all you people who maybe still be confused. this is how to calculate the correct quantity of image pixels within an PAL DVD's 720x576 "anamorphic pixel frame".

First you have to assume that you are going to convert to an "true 16:9 pixel frame".

To calculate this, multiply (16:9) 1.77 (recuring) by 576. Which means you would end up with a pixel frame size of 1024x576 pixels.

OK, now we've established that the true width of the frame should be 1024, we can move on to calculating the image pixel heights of the most common movies aspect ratios. Which are as follows: -

1024 divided by 1.77 = 576.0 - Which is no suprise
1024 divided by 1.85 = 553.5 - Or 560 to the nearest 16th pixel
1024 divided by 2.35 = 435.7 - Or 432 to the nearest 16th pixel
1024 divided by 2.40 = 426.6 - Or 432 to the nearest 16th pixel


Cheers

[Didée]

SMD:

I'm not that extraordinary familiar with all the according specifications, but wasn't there something about ITU BT.601, which - on balance - implies that the *active image area* (which should be 702~704 pixels) should be scaled to 1024? Then you would have to scale your not-cropped 720*576 frame to 1048*576, not 1024 ...

Another question is which specs (if any :rolleyes: ) were considered when the source was mastered ...
My general rule of thumb, unless my eyes tell me something other, is:
If the (apparent) active image area is less then ~708, then I'll calculate based on 1048. If it's >=710, then I'll use 1024 as base for scaling.

Not always true, but mostly.


- Didée

[SeeMoreDigital]

Yes, you are right Didée,

However, I feel such discussions are better left until the person/persons asking the initial questions (about anamorphic images/ anamorphic encoding) obtain a basic level of understanding!

If we roll straight into all the different specs straight away I feel this will (and does) confuse the hell out of people.

That said, have you noticed that when DVD was in it's infancy a typical 1.85:1 movie and some 2.35:1 movies were presented with vertical black 'over-scan' mattes to the left and right of the image. Nowadays however, this trend seems to have been abandoned.


Cheers

[Koepi]

Most likely due to the massive amounts of "full display size" displays like tft TVs, monitors and beamers sold in the last years.

Imagine you'd look at such a DVD with a nice 19" tft monitor. I prefer having "full horizontal resolution" there... :)

Regards
Koepi

[Splashdriver]

To calculate this, multiply (16:9) 1.77 (recuring) by 576. Which means you would end up with a pixel frame size of 1024x576 pixels.

Or to be even more accurate it's: 1.777778*576=1024.000128

Greetings,
Splashdriver

[SeeMoreDigital]

Originally posted by Koepi
Most likely due to the massive amounts of "full display size" displays like tft TVs, monitors and beamers sold in the last years.

Imagine you'd look at such a DVD with a nice 19" tft monitor. I prefer having "full horizontal resolution" there... :)

Yes, that's a bloody good point Koepi and is the most logical explanation.

This is one of the reasons why I find it unbearable to watch some of the early DVD's on my new 1366x768 plasma screen.

Imagine watching this badly presented DVD for any length of time.

http://img47.exs.cx/img47/3066/SMD_BladeRunner_crap_presentation.jpg

I like watching Blade Runner but hate this transfer as the vertical boarders wiggle about from left to right and even begin to slope during a couple of shots.... urgh!


Cheers