I don't know how current this is, but I read in http://www.mplayerhq.hu/DOCS/tech/wishlist that you're interested in "continuing the MEncoder tutorial." I would like to contribute some case studies in the same style/depth as http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-enc-libavcodec.html#menc-feat... (the Harry Potter example). You already have an "encoding to PSP" guide, but little else on targeting specific output devices. I've used mencoder in a variety of ways, including - interlaced camcorder DV output to 320x240 iPod 5G-compatible H.264/AAC .mp4 files (remuxing with mp4creator) - widescreen DVD movies to QuickTime 7-compatible H.264/AAC .mp4 files (again, remuxing with mp4creator) - 4x3 TV shows to XVID/MP3 .avi files to be played back on a Philips 5960 DVD/set-top box (with its own interesting quirks and limitations on max bitrate and MPEG 4 options) I've spent quite some time digging through the latest CVS docs and various mailing lists to get high-quality results in all cases. I was wondering if these sorts of case studies would be welcome in the MEncoder docs. -- Cheers, -Mark
Hi, On 10/19/06, Mark Pilgrim <pilgrim@gmail.com> wrote:
I don't know how current this is, but I read in http://www.mplayerhq.hu/DOCS/tech/wishlist that you're interested in "continuing the MEncoder tutorial." I would like to contribute some case studies in the same style/depth as http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-enc-libavcodec.html#menc-feat... (the Harry Potter example). You already have an "encoding to PSP" guide, but little else on targeting specific output devices.
I've used mencoder in a variety of ways, including
- interlaced camcorder DV output to 320x240 iPod 5G-compatible H.264/AAC .mp4 files (remuxing with mp4creator) - widescreen DVD movies to QuickTime 7-compatible H.264/AAC .mp4 files (again, remuxing with mp4creator) - 4x3 TV shows to XVID/MP3 .avi files to be played back on a Philips 5960 DVD/set-top box (with its own interesting quirks and limitations on max bitrate and MPEG 4 options)
We frequently receive questions about these on our user mailing list. Having doc on how to create such files would be more that welcome.
I've spent quite some time digging through the latest CVS docs and various mailing lists to get high-quality results in all cases. I was wondering if these sorts of case studies would be welcome in the MEncoder docs.
They would certainly be. I'm the person responsible for MEncoder docs. I guarantee that I will do my best to merge your knowledge/work into our doc. Guillaume -- With DADVSI (http://en.wikipedia.org/wiki/DADVSI), France finally has a lead on USA on selling out individuals right to corporations! Vive la France!
On 10/19/06, Guillaume POIRIER <poirierg@gmail.com> wrote:
We frequently receive questions about these on our user mailing list. Having doc on how to create such files would be more that welcome.
Attached is a first draft of "Using MEncoder to create QuickTime-compatible files". I inserted it before the VCD/SVCD/DVD section, but I have no objection to moving it. There are two TODOs where I don't know whether my knowledge is NTSC-specific (it probably is). Please critique it and let me know if I've made any mistakes. -- Cheers, -Mark
On Fri, Oct 20, 2006 at 01:37:00PM -0400, Mark Pilgrim wrote:
On 10/19/06, Guillaume POIRIER <poirierg@gmail.com> wrote:
We frequently receive questions about these on our user mailing list. Having doc on how to create such files would be more that welcome.
Attached is a first draft of "Using MEncoder to create QuickTime-compatible files". I inserted it before the VCD/SVCD/DVD section, but I have no objection to moving it. There are two TODOs where I don't know whether my knowledge is NTSC-specific (it probably is). Please critique it and let me know if I've made any mistakes.
Thanks for this, but I do wish you could put text attachments inline so they're easier to reply to.
+<para> + <application>QuickTime</application> 7 supports H.264 video and AAC audio, + but it does not support the AVI container format. However, you can use + <application>MEncoder</application> to encode the video and audio, and then + use an external program such as <application>mp4creator</application> (part + of the <ulink url="http://mpeg4ip.sourceforge.net/">MPEG4IP suite</ulink>) + to remux the video and audio tracks into an MP4 container. +</para>
Seems to me like gpac's MP4Box is more widely used.
+<listitem><para> + <emphasis role="bold">B-frames</emphasis>: + <application>QuickTime</application> 7 supports a maximum of 1 B-frame, i.e. + <option>-x264encopts bframes=1</option>. This also implies that you can not + use <option>b_pyramid</option> and <option>weight_b</option>, since they + require <option>bframes</option> to be greater than 1. +</para></listitem> +<listitem><para>
Call me pedantic, but your statement here is not literally true. You CAN use b_pyramid and weight_b, but they will have no effect when bframes is 0 or 1. Which, I think, is what you should say instead.
+ <emphasis role="bold">Macroblocks</emphasis>: + <application>QuickTime</application> 7 does not support 8x8 DCT macroblocks, + so you must specify <option>-x264encopts no8x8dct</option>. This also + implies that you can not use <option>i8x8</option>, since it requires + <option>8x8dct</option>.
You can use i8x8 (indeed most will since it's default), but it has no effect without 8x8dct.
+ <emphasis role="bold">Mixed reference frames</emphasis>: in + <application>QuickTime</application> 7, each whole macroblock must use the + same reference, so you must specify + <option>-x264encopts nomixed_refs</option>.
Just curious, how did you find this out?
+ <emphasis role="bold">Motion vectors</emphasis>: + <application>QuickTime</application> 7 does not support the + <option>bime</option> option that allows <application>MEncoder</application> + to refine the two motion vectors used in bidirectional macroblocks. You + must specify <option>-x264encopts nobime</option>.
Um, extraordinary claims require extraordinary proof. Please prove that this is actually true before including it in the guide.
+<para> + The next step is truly heartbreaking. <application>QuickTime</application> + does not support the <option>autoaspect</option> option, so you will + need to scale the video yourself. This wastes a lot of disk space, but it + simply can not be avoided. Of course you want a full-resolution + video, so you will not be scaling vertically. To scale horizontally, + you first need to know what aspect ratio the source DVD uses. + <application>MPlayer</application> can tell you this:
[snip] I really have no idea what you are talking about here - first we have a bunch of x264 treatment, then you jump into autoaspect, which is not an x264 option. Also, are you saying Quicktime 7 doesn't support SAR/DAR?
+ As always, the selection of bitrate is a matter of taste. This movie + has a fair bit of action and lots of detail, but H.264 video looks + good at much lower bitrates than XviD or other MPEG-4 codecs. After + much experimentation, I chose to encode this movie at 900kbs. Yes, + you read that correctly: 900kbs. My wife thought the result looked + phenomenal on her PowerBook's screen. Your wife may have different + standards; adjust your bitrate accordingly.
s/kbs/kbps
+ You are now ready to do encode the video. Of course you will be + doing a two-pass encode. For the first pass, + you can reduce <option>subq</option> and <option>frameref</option> + to save some time. The options that are required for + <application>QuickTime</application> compatibility are displayed + in bold.
1. What's the point in telling the user to specify a bunch of options (no8x8dct, nomixed_refs, nobime,..) that are DEFAULT anyway? IMO this just confuses people about what the defaults are, and what you do/don't have to specify. Also, bframes=1 should be recommended but it is not actually required for quicktime compatibility since bframes=0 (default) would also work. 2. Why don't you just use turbo=n on the first pass?
+ If you have a multi-processor machine, you can add + <option>threads=2</option> to the end of <option>-x264encopts</option>.
More pedantry: anyone CAN add threads=2. Only some people will want to. (those with 2+ cpus, who compiled with pthreads support, and who care a lot about the speed gain,...)
+ The second pass is the same, except that you specify + <option>pass=2</option> and bump <option>subq</option> and + <option>frameref</option> up to 5.
(again, this is why you should probably use turbo, would make the guide simpler)
+ Unfortunately, <application>mp4creator</application> does not support + declaring the bitrate as a fraction (24000/1001), so you will need to + specify the rate as a decimal.
s/bitrate/framerate Also I think the limitation is actually in the .mov/.mp4 container (hopefully someone who knows will comment)
Hello, On Fri, Oct 20, 2006 at 01:13:56PM -0500, Jeff Clagg wrote:
Thanks for this, but I do wish you could put text attachments inline so they're easier to reply to.
They usually don't apply then, or at least are a pain. But setting the type to text/plain combines the advantages of both for many mail clients. Greetings, Reimar Döffinger
On 10/20/06, Jeff Clagg <snacky@ikaruga.co.uk> wrote:
Seems to me like gpac's MP4Box is more widely used.
I've used that, and it works just as well. Is there any reason to prefer one over the other?
Call me pedantic, but your statement here is not literally true. You CAN use b_pyramid and weight_b, but they will have no effect when bframes is 0 or 1. Which, I think, is what you should say instead.
OK, you're pedantic. And I've fixed it.
You can use i8x8 (indeed most will since it's default), but it has no effect without 8x8dct.
Noted and fixed.
+ <emphasis role="bold">Mixed reference frames</emphasis>: in + <application>QuickTime</application> 7, each whole macroblock must use the + same reference, so you must specify + <option>-x264encopts nomixed_refs</option>. ... + must specify <option>-x264encopts nobime</option>.
Um, extraordinary claims require extraordinary proof. Please prove that this is actually true before including it in the guide.
Thank you for calling me on this. Further testing confirms that neither statement is true, and I have removed them from the latest draft. However, the b-frames and 8x8dct claims *are* correct. Test cases: http://diveintomark.org/tmp/bframes1.mp4 http://diveintomark.org/tmp/bframes2.mp4 http://diveintomark.org/tmp/no8x8dct.mp4 http://diveintomark.org/tmp/8x8dct.mp4
I really have no idea what you are talking about here - first we have a bunch of x264 treatment, then you jump into autoaspect, which is not an x264 option.
Also, are you saying Quicktime 7 doesn't support SAR/DAR?
Sorry, that is what I was talking about. And no, QuickTime 7 does not support a display AR different from the sample AR. It just assumes they're the same and plays the video stretched or squooshed. I'll rephrase the paragraph to make this more clear.
1. What's the point in telling the user to specify a bunch of options (no8x8dct, nomixed_refs, nobime,..) that are DEFAULT anyway? IMO this just confuses people about what the defaults are, and what you do/don't have to specify. Also, bframes=1 should be recommended but it is not actually required for quicktime compatibility since bframes=0 (default) would also work.
2. Why don't you just use turbo=n on the first pass?
+ If you have a multi-processor machine, you can add + <option>threads=2</option> to the end of <option>-x264encopts</option>.
More pedantry: anyone CAN add threads=2. Only some people will want to. (those with 2+ cpus, who compiled with pthreads support, and who care a lot about the speed gain,...)
Points taken and incorporated. New draft coming soon, after I put the kids to bed. -- Cheers, -Mark
On 10/20/06, Mark Pilgrim <pilgrim@gmail.com> wrote:
Points taken and incorporated. New draft coming soon, after I put the kids to bed.
Draft 2 attached. Incorporated all of Jeff's feedback -- corrected factual inaccuracies, added turbo, removed default options, rephrased text on scaling and multithreading, etc. Feel free to critique further. Did we come to a decision on mp4creator vs. MP4Box? -- Cheers, -Mark
On Fri, Oct 20, 2006 at 11:26:03PM -0400, Mark Pilgrim wrote:
Did we come to a decision on mp4creator vs. MP4Box?
I don't see any reason why it's harmful to use mp4creator in this example. But my own tiny sample suggests that all Windows users are using MP4Box, and most Linux users are too. Not necessarily a huge deal either way, I think.
+ <application>QuickTime</application> 7 does not support 8x8 DCT macroblocks, + so you must specify <option>-x264encopts no8x8dct</option>. This + means that <option>i8x8</option> will have no effect, since it + requires <option>8x8dct</option>.
You don't have to specify no8x8dct since it's default. This is something I feel fairly strongly about since history shows that canned command lines often get copy+pasted by literally thousands of people and this WILL confuse people about what the defaults are. Just tell the user not to put 8x8dct in their options.
+ You are now ready to encode the video. Since you care about + quality, of course you will be doing a two-pass encode. To shave off + some encoding time, you can specify the <option>turbo</option> option + on the first pass; this reduces <option>subq</option> and + <option>frameref</option> to 1. To save some disk space, you can + use the <option>ss</option> option to strip off the first few seconds + of the video. (I found that this particular movie has 32 seconds of + credits and logos.) The <option>no8x8dct</option> option + is required for <application>QuickTime</application> 7 compatibility, + and <option>bframes</option> can be 0 or 1. The other options are + documented in <link
(another no8x8dct mention)
+ linkend="menc-feat-x264-encoding-options-speedvquality">Encoding with + the <systemitem class="library">x264</systemitem> codec</link> and + the man page. + + <screen>mencoder dvd://1 -o /dev/null -ss 32 -ovc x264 \ +-x264encopts pass=1:turbo:bitrate=900:no8x8dct:bframes=1:\
(another)
+ +<para> + The second pass is the same, except that you specify + <option>pass=2</option> and remove the <option>turbo</option> option. + + <screen>mencoder dvd://1 -o narnia.avi -ss 32 -ovc x264 \ +-x264encopts pass=2:bitrate=900:frameref=5:no8x8dct:bframes=1:\
(another)
On Fri, 20 Oct 2006, Mark Pilgrim wrote:
Draft 2 attached. Incorporated all of Jeff's feedback -- corrected factual inaccuracies, added turbo, removed default options, rephrased text on scaling and multithreading, etc. Feel free to critique
+ The next step is truly heartbreaking. + <application>QuickTime</application> 7 does not support MPEG-4 videos + with a display aspect ratio different from the sample aspect ratio, + so you will need to scale the video to square pixels. This wastes a + lot of disk space, but it simply can not be avoided if you want your + video to be playable by <application>QuickTime</application>.
"...does not support MPEG-4 videos with a sample aspect ratio other than 1." Your statement meant instead that the whole video must be square.
+ Of course you want a full-resolution video, so you will not be scaling + vertically. To scale horizontally, you first need to know what aspect + ratio the source DVD uses. <application>MPlayer</application> can tell + you this:
You don't actually need to know that. "-vf scale=-10:-1" will pick the right width for the current height, rounded to a multiple of 16 for optimal compression.
+ The second pass is the same, except that you specify + <option>pass=2</option> and remove the <option>turbo</option> option.
You don't have to remove turbo, it automatically disables itself on the 2nd pass.
+ I have a dual-processor machine, so I usually add + <option>threads=2</option>. This can result in slightly larger files, + but it increases encoding speed by 20-30%. Real multithreaded support + requires that <systemitem>libx264</systemitem> be compiled with + <option>--enable-pthreads</option>.
"Real multithreaded support" as opposed to what, fake multithread? Imo, --enable-pthreads doesn't need to be mentioned anymore, since x264 has had autodetection for such libraries for a long time. Yes, it's possible to compile x264 without multithread support, but only by adding --disable-pthreads or by using some os other than linux, windows, and bsd. --Loren Merritt
On 10/21/06, Loren Merritt <lorenm@u.washington.edu> wrote:
"...does not support MPEG-4 videos with a sample aspect ratio other than 1." Your statement meant instead that the whole video must be square.
Fixed. As you may have guessed from the first few drafts, I am relatively new to this field, and self-taught. Which means I know how to fix the problem, but not necessarily how to explain it.
You don't actually need to know that. "-vf scale=-10:-1" will pick the right width for the current height, rounded to a multiple of 16 for optimal compression.
Wow, that's amazing. Now that you say it, I can see how the man page sort of explains that, but I have never seen that technique in any tutorial or discussion. Incorporated everywhere.
You don't have to remove turbo, it automatically disables itself on the 2nd pass.
Fixed.
"Real multithreaded support" as opposed to what, fake multithread? Imo, --enable-pthreads doesn't need to be mentioned anymore, since x264 has had autodetection for such libraries for a long time. Yes, it's
Removed. Thanks for all the feedback. Draft 3 is attached. -- Cheers, -Mark
Hi, On Oct 23, 2006, at 7:35 , Mark Pilgrim wrote:
On 10/21/06, Loren Merritt <lorenm@u.washington.edu> wrote:
"...does not support MPEG-4 videos with a sample aspect ratio other than 1." Your statement meant instead that the whole video must be square.
Fixed. As you may have guessed from the first few drafts, I am relatively new to this field, and self-taught. Which means I know how to fix the problem, but not necessarily how to explain it.
Same for me, welcome on board! ;-)
Thanks for all the feedback. Draft 3 is attached.
+ <emphasis role="bold">Aspect ratio</emphasis>: + <application>QuickTime</application> 7 does not support SAR (sample + aspect ratio) information in MPEG-4 files; it assumes that SAR=1. Read + <link linkend="menc-feat-quicktime-7-scale">the section on scaling</link> + for a workaround. +</para></listitem> +</itemizedlist> I'm a bit surprised. I'm quite confident that Quicktime supports anamorphic videos in some way. If it doesn't support SAR, maybe it supports Pixel Aspect Ratio or Display Aspect Ration? The doc here: http://developer.apple.com/documentation/QuickTime/Conceptual/ QT7-1_Update_Guide/Content/2NewFeaturesChangesa.html Seem to indicate that QT7.1 supports pixel aspect ratio (pasp) Upscaling a video so make sure that it's correctly displayed should be avoided as much as possible IMHO because it wastes bits. Please someone confirm if QT really needs this. +<sect2 id="menc-feat-quicktime-7-crop"> +<title>Cropping</title> +<para> + Suppose you want to rip your freshly bought copy of "The Chronicles of + Narnia" and add it to your local video collection, hosted on your local + web server running Gallery2. Unfortunately, your wife is still using an + Apple PowerBook, so your rip will need to be + <application>QuickTime</application>-compatible. IMHO, the doc should be a little bit more "impersonal"... well, at least, it's the way it we have tried to maintain it. (plus, I don't see why a wife who has a powerbook is unfortunate. I'd prefer a Mac-use rather than a Windows-user wife if I was given the choice ;-P ) I'd be happier if this paragraph would read smth similar to this: Suppose you want to rip your freshly bought copy of "The Chronicles of Narnia" and add it to your local video collection, and want to be able to watch it natively on all major plateforms such as Unices, Windows, OSX, ... Therefore, your rip should be <application>QuickTime</application>- compatible. My English is terrible, so don't just copy and paste me ;-) +<para> + Next, you need to crop out the black bars from the top and bottom of the + video, so you use the <option>cropdetect</option> filter: + + <screen>mplayer dvd://1 -vf cropdetect</screen> + + Make sure you seek to a fully filled frame (past the opening credits and + logos), and you will see the crop rectangle in + <application>MPlayer</application>'s console output: + + <screen>crop area: X: 0..719 Y: 61..413 (-vf crop=720:352:0:62)</ screen> + + Play the movie back with this filter to make sure it looks good: + + <screen>mplayer dvd://1 -vf crop=720:352:0:62</screen> +</para> I'd be happier if you could replace this duplicated entry with a link to the relevant section of the existing doc. That would mean less work for the translators. Maybe the previous paragraph (the one about DVD region and telecine) too, though this doesn't seem so important to me right now. +</sect2> + +<sect2 id="menc-feat-quicktime-7-scale"> +<title>Scaling</title> + +<para> + The next step is truly heartbreaking. + <application>QuickTime</application> 7 does not support MPEG-4 videos + with a sample aspect ratio other than 1, so you will need to scale + the video to square pixels. This wastes a lot of disk space, but it + simply can not be avoided if you want your video to be playable by + <application>QuickTime</application> 7. + <application>MEncoder</application> can apply the appropriate scaling + by specifying <option>-vf scale=-10:-1</option>. This will scale your + video to the correct width for the cropped height, rounded to a multiple + of 16 for optimal compression. Remember that if you are cropping, you + should crop first, then scale: + + <screen>-vf crop=720:352:0:62,scale=-10:-1</screen> +</para> Like I said, I'd really like if you could make _dead sure_ that QT doesn't support any kind of aspect ration information. Apple ships high quality and well thought out software, so I'd be _really_ surprised if they had forget to implement such a basic feature (though I understand embedded players don't support custom aspect ratio for cpu consumption reasons). +</sect2> + +<sect2 id="menc-feat-quicktime-7-avsync"> +<title>A/V sync</title> + +<para> + Because you will be remuxing into a different container, you should + always use the <option>harddup</option> option to ensure that duplicated + frames are actually duplicated in the video output. Without this option, + <application>MEncoder</application> will simply put a marker in the video + stream that a frame was duplicated, and rely on the client software to + show the same frame twice. Unfortunately, this "soft duplication" does + not survive remuxing, so the audio will slowly lose sync with the video. +</para> Please add a link the section "Improving muxing and A/V sync reliability" here too. Though you are slightly duplicating that existing entry, your working is quite clearer and less technical, which is quite good. +<para> + The final filter chain looks like this: + + <screen>-vf crop=720:352:0:62,scale=-10:-1,harddup</screen> +</para> + +</sect2> + +<sect2 id="menc-feat-quicktime-7-bitrate"> +<title>Bitrate</title> + +<para> + As always, the selection of bitrate is a matter of taste. This movie + has a fair bit of action and lots of detail, but H.264 video looks + good at much lower bitrates than XviD or other MPEG-4 codecs. After + much experimentation, I chose to encode this movie at 900kbps. Yes, + you read that correctly: 900kbps. My wife thought the result looked + phenomenal on her PowerBook's screen. Your wife may have different + standards; adjust your bitrate accordingly. Please add a link to the different bitrate computation techniques that exist in existing doc; that way, the user will see that it's not just a made up figure. Also, like I said, I don't quite like "too personal" style, so I'd prefer smth along the lines of: After much experimentation, and after computing bitrate with the techniques exposed <here/> in the doc you can try to encode this movie at 900kbps. This may seem quite low but experience show that for people who aren't after every details, it's yields a very decent picture quality. Other people may have different standards; adjust your bitrate accordingly. +<sect2 id="menc-feat-quicktime-7-example"> +<title>Encoding example</title> + +<para> + You are now ready to encode the video. Since you care about + quality, of course you will be doing a two-pass encode. To shave off + some encoding time, you can specify the <option>turbo</option> option + on the first pass; this reduces <option>subq</option> and + <option>frameref</option> to 1. To save some disk space, you can + use the <option>ss</option> option to strip off the first few seconds + of the video. (I found that this particular movie has 32 seconds of + credits and logos.) <option>bframes</option> can be 0 or 1. + The other options are documented in <link + linkend="menc-feat-x264-encoding-options-speedvquality">Encoding with + the <systemitem class="library">x264</systemitem> codec</link> and + the man page. + + <screen>mencoder dvd://1 -o /dev/null -ss 32 -ovc x264 \ +-x264encopts pass=1:turbo:bitrate=900:bframes=1:\ +me=umh:4x4mv:trellis=1:qp_step=4:qcomp=0.7:direct_pred=3:keyint=300 \ +-vf crop=720:352:0:62,scale=-10:-1,harddup \ +-oac faac -faacopts br=192:mpeg=4:object=1 -channels 2 -srate 48000 \ +-ofps 24000/1001</screen> + + I have a dual-processor machine, so I usually add + <option>threads=2</option>. This increases encoding speed by 20-30%, + but it can result in slightly larger files. My own un-scientific experiments with x264's multi-threaded encoding allowed me to enjoy speed-ups larger than 30%, I didn't measure precisely, but I think it was quite close to 40% at fairly high quality encoding settings. +<para> + This <systemitem>narnia.mp4</systemitem> file should now be playable + with any <application>QuickTime</application> 7 application, such as + <application>QuickTime Player</application> or + <application>iTunes</application>. If you are planning to view the + video in a web browser with the <application>QuickTime</application> + plugin, you should also hint the movie so that the + <application>QuickTime</application> plugin can start playing it + while it is still downloading. Our of curiosity, do you have an idea what there "hints" result in in the MP4 stream? Are they some sort of special indexes? Do adding hints make the video file grow bigger? Thanks a lot for the work, it's highly appreciated. Guillaume
On 10/23/06, Guillaume Poirier <gpoirier@mplayerhq.hu> wrote:
I'm a bit surprised. I'm quite confident that Quicktime supports anamorphic videos in some way. If it doesn't support SAR, maybe it supports Pixel Aspect Ratio or Display Aspect Ration?
I made a 30-second sample video using my mencoder recipe in draft 3, but omitting the scale filter. http://diveintomark.org/tmp/foo.mp4 Here's a screenshot of two video players interpreting the file. VLC is on the top, and QuickTime Player on the bottom. I have QuickTime 7.1.3 installed. http://diveintomark.org/public/2006/10/quicktime-vs-vlc.jpg For the benefit of those who don't wish to download the sample movie, or if the screenshot disappears in the future, VLC is playing the video at the correct aspect ratio, having scaled it to 854x352. QuickTime Player is playing it at 720x352, and the QuickTime Player "movie info" dialog confirms that QuickTime sees nothing wrong with that.
The doc here: http://developer.apple.com/documentation/QuickTime/Conceptual/ QT7-1_Update_Guide/Content/2NewFeaturesChangesa.html
I'm sorry, those docs are way over my head. Is it describing some QuickTime-specific way of embedding the correct aspect ratio? If so, perhaps it would be possible to automate that with MP4Box or some other tool that can manipulate raw atoms.
Also, like I said, I don't quite like "too personal" style, so I'd prefer smth along the lines of:
I'm happy to make the other stylistic changes after we come to a consensus on the aspect ratio problem. -- Cheers, -Mark
Hi, On 10/26/06, Mark Pilgrim <pilgrim@gmail.com> wrote:
On 10/23/06, Guillaume Poirier <gpoirier@mplayerhq.hu> wrote:
I'm a bit surprised. I'm quite confident that Quicktime supports anamorphic videos in some way. If it doesn't support SAR, maybe it supports Pixel Aspect Ratio or Display Aspect Ration?
I made a 30-second sample video using my mencoder recipe in draft 3, but omitting the scale filter.
http://diveintomark.org/tmp/foo.mp4
Here's a screenshot of two video players interpreting the file. VLC is on the top, and QuickTime Player on the bottom. I have QuickTime 7.1.3 installed.
http://diveintomark.org/public/2006/10/quicktime-vs-vlc.jpg
For the benefit of those who don't wish to download the sample movie, or if the screenshot disappears in the future, VLC is playing the video at the correct aspect ratio, having scaled it to 854x352. QuickTime Player is playing it at 720x352, and the QuickTime Player "movie info" dialog confirms that QuickTime sees nothing wrong with that.
At least, it's good to see that QuickTime does not refuse to play the file if you set an aspect ratio that VLC understands.
The doc here: http://developer.apple.com/documentation/QuickTime/Conceptual/ QT7-1_Update_Guide/Content/2NewFeaturesChangesa.html
I'm sorry, those docs are way over my head. Is it describing some QuickTime-specific way of embedding the correct aspect ratio?
Maybe, but I'm no expert on that field. To put it in a nutshell: - The doc does seem to say that QT supports aspect ratio - There are just too many different kinds of aspect ratio out there, so I wouldn't be surprised that QT only supports one of them. I hope what what I'm saying make some sense. I'm gonna google around and hopefully find the missing information we need.
If so, perhaps it would be possible to automate that with MP4Box or some other tool that can manipulate raw atoms.
Yeah, I guess so.
Also, like I said, I don't quite like "too personal" style, so I'd prefer smth along the lines of:
I'm happy to make the other stylistic changes after we come to a consensus on the aspect ratio problem.
Ok, great! Guillaume -- With DADVSI (http://en.wikipedia.org/wiki/DADVSI), France finally has a lead on USA on selling out individuals right to corporations! Vive la France!
Hi, On Oct 26, 2006, at 6:10 , Mark Pilgrim wrote:
On 10/23/06, Guillaume Poirier <gpoirier@mplayerhq.hu> wrote:
The doc here: http://developer.apple.com/documentation/QuickTime/Conceptual/ QT7-1_Update_Guide/Content/2NewFeaturesChangesa.html
I'm sorry, those docs are way over my head. Is it describing some QuickTime-specific way of embedding the correct aspect ratio?
I don't know. I have googled a bit, and had a look at doom9 forum, I found this post: http://forum.doom9.org/showthread.php? p=381369#post381369 which is from someone who is supposed to be quite reliable given the quality of this remarks in both doom9 and FFmpeg ML. I haven't found information on mp4box or mp4creator as to whether or not they support "composition matrix".
If so, perhaps it would be possible to automate that with MP4Box or some other tool that can manipulate raw atoms.
Also, like I said, I don't quite like "too personal" style, so I'd prefer smth along the lines of:
I'm happy to make the other stylistic changes after we come to a consensus on the aspect ratio problem.
If you manage to find a way to set "composition matrix" with one of the 2 mp4 muxing tools, then I'd happily drop the section about upscaling, otherwise, I'd put a note that says that it's workaround needed until the above mentioned tools support QuickTime aspect ratio. Guillaume
Hi, On Oct 21, 2006, at 5:26 , Mark Pilgrim wrote:
On 10/20/06, Mark Pilgrim <pilgrim@gmail.com> wrote:
Points taken and incorporated. New draft coming soon, after I put the kids to bed.
Draft 2 attached. Incorporated all of Jeff's feedback -- corrected factual inaccuracies, added turbo, removed default options, rephrased text on scaling and multithreading, etc. Feel free to critique further.
Did we come to a decision on mp4creator vs. MP4Box?
As far as I'm concerned, I don't have any preference over any of these. Are there any fundamental differences between the two BTW? If you want, it's also possible to document both, though this is a bit overkill. Guillaume
Hi, On 10/28/06, Guillaume Poirier <gpoirier@mplayerhq.hu> wrote:
Hi, On Oct 21, 2006, at 5:26 , Mark Pilgrim wrote:
On 10/20/06, Mark Pilgrim <pilgrim@gmail.com> wrote:
Points taken and incorporated. New draft coming soon, after I put the kids to bed.
Draft 2 attached. Incorporated all of Jeff's feedback -- corrected factual inaccuracies, added turbo, removed default options, rephrased text on scaling and multithreading, etc. Feel free to critique further.
Here's a further improved version of your patch. I factorized some of the things that were already covered elsewhere. There's still some work left to be done, but I'm posting this patch for grammar/wording review, and to somewhat show that I haven't forgotten about this patch. Nite, Guillaume -- An association of men who will not quarrel with one another is a thing which has never yet existed, from the greatest confederacy of nations down to a town meeting or a vestry. -- Thomas Jefferson (when interviewed about MPlayer ML flamewars) http://www.brainyquote.com/quotes/quotes/t/thomasjeff157207.html
Hi, On 1/5/07, Guillaume POIRIER <poirierg@gmail.com> wrote:
Hi,
On 10/28/06, Guillaume Poirier <gpoirier@mplayerhq.hu> wrote:
Hi, On Oct 21, 2006, at 5:26 , Mark Pilgrim wrote:
On 10/20/06, Mark Pilgrim <pilgrim@gmail.com> wrote:
Points taken and incorporated. New draft coming soon, after I put the kids to bed.
Draft 2 attached. Incorporated all of Jeff's feedback -- corrected factual inaccuracies, added turbo, removed default options, rephrased text on scaling and multithreading, etc. Feel free to critique further.
Here's a further improved version of your patch. I factorized some of the things that were already covered elsewhere. There's still some work left to be done, but I'm posting this patch for grammar/wording review, and to somewhat show that I haven't forgotten about this patch.
Ok, attached patch is the patch that will be comitted to MPlayer svn once the eventual wording/grammar problems are fixed. Please review and comment, I'll apply this patch soon. Guillaume -- An association of men who will not quarrel with one another is a thing which has never yet existed, from the greatest confederacy of nations down to a town meeting or a vestry. -- Thomas Jefferson (when interviewed about MPlayer ML flamewars) http://www.brainyquote.com/quotes/quotes/t/thomasjeff157207.html
On 1/8/07, Guillaume POIRIER <poirierg@gmail.com> wrote:
Ok, attached patch is the patch that will be comitted to MPlayer svn once the eventual wording/grammar problems are fixed.
+ <application>QuickTime</application> 7 supports H.264 video and AAC audio, + but it does not support the AVI container format. However, you can use This is not entirely correct (and it's my fault because I originally wrote it this way). QuickTime does support the AVI container format, but it does not support H.264 video (nor AAC audio) within the AVI container format. It does support other codecs within an AVI, just not modern ones. + (which wastes a lot of disk space) or downscale (which looses some + details of the source) the video to square pixels. s/looses/loses/ + show the same frame twice. Unfortunately, this "soft duplication" does + not survive remuxing, so the audio will slowly lose sync with the video. s/will/would/ + After much experimentation, the author of this guide chose to encode + this movie at 900kbps, and though that it looked very good. s/though/thought/ + The resulting AVI should play perfectly in + <application>MPlayer</application>, but of course + <application>QuickTime</application> can not play it because it does + not support AVI files. So the next step is to remux the video into + an MP4 container. Again, QuickTime supports the AVI container but does not support H.264 within AVI. Otherwise looks great. Thanks for picking this up again. I can write up a similar case study for H.264 encoding for 5G iPods. I've been doing quite a bit of that lately, and I think I've identified the minimal set of required options. Of course, Apple just released the 6G iPod today, which may have different capabilities. -- Cheers, -Mark
Mark Pilgrim wrote:
Otherwise looks great. Thanks for picking this up again. I can write up a similar case study for H.264 encoding for 5G iPods.
Yes, please.
I've been doing quite a bit of that lately, and I think I've identified the minimal set of required options. Of course, Apple just released the 6G iPod today, which may have different capabilities.
There will be a 480x320 screen on the iPhone, which is interesting. It's neither 16x9 nor 4x3. Does anyone know (or can find out, if you're at Macworld) if the video player's CPU can handle H.264 at 480x270 (for 16x9) and 426x320 (for 4x3)? There's the appleTV, too. It supports up to 1080i/720p output, apparently. Here's a bit from the specs at http://www.apple.com/appletv/specs.html Video formats supported: H.264 and protected H.264 (from iTunes Store): 640 by 480, 30 fps, LC version of Baseline Profile; 320 by 240, 30 fps, Baseline profile up to Level 1.3; 1280 by 720, 24 fps, Progressive Main Profile. MPEG-4: 640 by 480, 30 fps, Simple Profile TV compatibility * Enhanced-definition or high-definition widescreen TVs capable of 1080i 60/50Hz, 720p 60/50Hz, 576p 50Hz (PAL format), or 480p 60Hz That sounds very much like the decoding profiles of a 5.5G iPod, plus a better upscaler. The CPU, however, ought to blow the doors off of an iPod so I wonder if "appleTV-only" content could be higher quality. Thx Thomas
Hi, On 1/9/07, Mark Pilgrim <pilgrim@gmail.com> wrote:
On 1/8/07, Guillaume POIRIER <poirierg@gmail.com> wrote:
Ok, attached patch is the patch that will be comitted to MPlayer svn once the eventual wording/grammar problems are fixed.
+ <application>QuickTime</application> 7 supports H.264 video and AAC audio, + but it does not support the AVI container format. However, you can use
This is not entirely correct (and it's my fault because I originally wrote it this way). QuickTime does support the AVI container format, but it does not support H.264 video (nor AAC audio) within the AVI container format. It does support other codecs within an AVI, just not modern ones.
[...] Thanks for the review. I'll fix the issues your noticed, and commit this patch.
Otherwise looks great. Thanks for picking this up again. I can write up a similar case study for H.264 encoding for 5G iPods. I've been doing quite a bit of that lately, and I think I've identified the minimal set of required options. Of course, Apple just released the 6G iPod today, which may have different capabilities.
Good. An Ipod encoding guide would be a nice addition to the docs. Don't forget to reuse/complete existing sections as much as possible to prevent doc duplication as much as possible. Guillaume -- An association of men who will not quarrel with one another is a thing which has never yet existed, from the greatest confederacy of nations down to a town meeting or a vestry. -- Thomas Jefferson (when interviewed about MPlayer ML flamewars) http://www.brainyquote.com/quotes/quotes/t/thomasjeff157207.html
participants (7)
-
Guillaume POIRIER -
Guillaume Poirier -
Jeff Clagg -
Loren Merritt -
Mark Pilgrim -
Reimar Döffinger -
Thomas Lunde