Roughly when will MF 0.8.0b2 be released, and will it fix...

[Leo]

Hi

Roughly when will MF 0.8.0b2 be released, and will it fix:

A) The big bug of MF ignoring the -l (height) value when you set the -w value (e.g. for anamorphic encoding, or when the aspect ratio is set wrongly)

B) The big bug of MF not being able to encode a director's commentary (or any second audio track) as well as the main audio track.

I now have dozens of DVDs ripped on my PC and I'm waiting to encode them, but I "can't" until the above bugs are fixed. The first bug I would image would be very easy to fix (and then I could encode movies that don't have a secondary soundrack).
- I could also also encode "Withnail and I", which retardedly is a 16:9 movie with bars to make it fit in 4:3 ratio, but MF detects the ratio as 16:9 and squashes i further to 64:27, and because it ignores my request to use -w 672 -l 384 is forces it out at something like 672x288.

I have PAL DVDs (720x576) which I normally encode anamorphically at 720x480 (or 720x364 for 2.35:1) if they're sharp modern movies.

*** Would it please be possible to release a version that has this simple bug fixed (I read that it's already been fixed but just not released yet)?

Also could there be an option ofr me to set the pixel ratio in the output file, e.g. --pr 1.2 (or 0.8, whichever it would be if I encode with 20% extra lines). Again this should be very easy to implement -- I wish I coudl porgramme in MF's language! (Or MF could automatically set it based on the output dimensions and the aspect ratio it should be.)
- actually an "anamorphic" setting would be good -- e.g. I could set --anamorphic 1.2 (or --am 1.2) which would add 20% extra lines!

Thanks!

PS - thanks to all whole got MF released. CRF is great to have, also ta for x264b30.
PPS - I know I could just use HB but there's no CRF and the video quality's inferior.
PPPS - The "trac" thing doesn't appear to list the ignoring -l when -w is set problem!

[rhester]

Roughly when will MF 0.8.0b2 be released

Based on my scanning of the IRC logs this morning, probably within the next couple of weeks (but this is not a guarantee).

and will it fix:

A) The big bug of MF ignoring the -l (height) value when you set the -w value (e.g. for anamorphic encoding, or when the aspect ratio is set wrongly)

Yes. This is already fixed in svn.

B) The big bug of MF not being able to encode a director's commentary (or any second audio track) as well as the main audio track.

Based on readings so far, probably not. The issue here is that the source-code behavior for this changed sometime after 0.7.1 but before we began our work, so we're still having trouble understanding exactly where the problem was introduced.

Also could there be an option ofr me to set the pixel ratio in the output file, e.g. --pr 1.2 (or 0.8, whichever it would be if I encode with 20% extra lines). Again this should be very easy to implement -- I wish I coudl porgramme in MF's language! (Or MF could automatically set it based on the output dimensions and the aspect ratio it should be.)
- actually an "anamorphic" setting would be good -- e.g. I could set --anamorphic 1.2 (or --am 1.2) which would add 20% extra lines!

This sounds reasonable and fairly straightforward to implement. I'll allow jbrjake to comment on it further.

Rodney

[Leo]

the source-code behavior for this changed sometime after 0.7.1 but before we began our work

you can't just use the code that worked fine in HB 0.7.1? (I found the sound quality fine (I use 160 or 192), although I didn't test it thoroughly, so I'm not bothererd if the audio codes are updated.) I presume I couldn't encode the audio in HB (e.g with no or minimal video) and the video in MF and then join the two together? lol, it'd be a funny workaround!

nyargh, I was hoping for the new version to come out in a few days. Is it simply a case of compiling the updated code?

ps - ta for your super-fast (6 mins!) response!

[rhester]

the source-code behavior for this changed sometime after 0.7.1 but before we began our work

you can't just use the code that worked fine in HB 0.7.1?

No - it was part of interlinked and very extensive core changes right after 0.7.1 was released (that introduced quite a few defects, some of which we've worked around in the manner you described, others that can't be like this one).

I presume I couldn't encode the audio in HB (e.g with no or minimal video) and the video in MF and then join the two together?

Technically...yes. I don't know which MacOS tools would be appropriate, but on Windows, I'd use MP4Box to rip the AAC track out of the "throwaway" rip and add it to the one with the first video track (therefore remuxing that rip) and producing a single MP4 with one H.264 (in my case) and two AAC audio tracks.

It's a huge PITA, but it can be done.

Rodney

[jbrjake]

A) The big bug of MF ignoring the -l (height) value when you set the -w value (e.g. for anamorphic encoding, or when the aspect ratio is set wrongly)

This is fixed, but on its own is not worth a release. If it's that important to you, compile from the source.

Also, I think you have a misunderstanding of the anamorphic setting. When it's in play it's supposed to ignore user-set width or height.

B) The big bug of MF not being able to encode a director's commentary (or any second audio track) as well as the main audio track.

We know it happened in rev34. That is all we know. If this is important to you, I suggest you use HB just to encode video and mux to your output container with audio using other tools.

- I could also also encode "Withnail and I", which retardedly is a 16:9 movie with bars to make it fit in 4:3 ratio, but MF detects the ratio as 16:9 and squashes i further to 64:27, and because it ignores my request to use -w 672 -l 384 is forces it out at something like 672x288.

Clee was looking into getting the anamorphic setting to work better with non-anamorphic widescreen. I dunno if he's gotten anywhere with that.

I have PAL DVDs (720x576) which I normally encode anamorphically at 720x480 (or 720x364 for 2.35:1) if they're sharp modern movies.

Then you're doing it wrong. An anamorphic PAL movie at 2.35:1 would be around 720*436 and a 1.78:1 anamorphic PAL film would be 720*576. Unless you're talking display dimensions, in which case the values you gave are even more off.

*** Would it please be possible to release a version that has this simple bug fixed (I read that it's already been fixed but just not released yet)?

dynaflash and I discussed this last night. I wish we could start sharing these new features with everyone, or maintain a public nightly svn snapshot. There are problems, though.

We've got quite a few bugs to fix, and several of them are regressions from HB 0.7.1. That is to say, we've added a bunch of features, but haven't increased stability much yet. There are maybe 5 bugs fixed so far, 6 tops. We have fewer active developers now than we did before release, and one of them is on vacation for the next week and a half. Many of the bugs that remain do not fall under the expertise of any of us who are around. Furthermore, several of the new features (5.1 aac, mp4-to-mov droplet, x264 options) require significant documentation that has yet to be done. Releasing a 2nd beta now would be irresponsible because it would imply we've made serious progress, when all we've added is more toys.

Users are always welcome to check code out from the svn and compile themselves. But as we've learned from any number of obnoxious posts (not yours!) since our public release, no one pays attention to "beta" anymore. They figure a public release means something is stable, and even if we say we guarantee no level of stability or functionality, they ignore it. When it's not stable or functional, they take it out on us. We're getting enough grief on a daily basis as it is. Another public binary will happen when we feel somewhat confident that support issues will go down and not up.

Also could there be an option ofr me to set the pixel ratio in the output file, e.g. --pr 1.2 (or 0.8, whichever it would be if I encode with 20% extra lines). Again this should be very easy to implement -- I wish I coudl porgramme in MF's language! (Or MF could automatically set it based on the output dimensions and the aspect ratio it should be.)
- actually an "anamorphic" setting would be good -- e.g. I could set --anamorphic 1.2 (or --am 1.2) which would add 20% extra lines!

? The pixel ratio for anamorphic widescreen content is always the same, and the picture ratio for 4:3 is always the same. The application figures these out on its own. It adds no lines, merely preserves the ones on the DVD. Are you saying you want to downsize anamorphic content?

As far as MF's language, the core is just plain ol' C...

PPPS - The "trac" thing doesn't appear to list either of these two problems!

The dual audio bug is definitely on the Trac and assigned to maurj. The ignores-user-set-height values thing isn't on the Trac because I fixed it and I haven't added any post-release bugs yet anyway.

[Leo]

? The pixel ratio for anamorphic widescreen content is always the same, and the picture ratio for 4:3 is always the same. The application figures these out on its own. It adds no lines, merely preserves the ones on the DVD. Are you saying you want to downsize anamorphic content?

Yeah, that's right. Encoding is of course all about sacrifices, mainly to reduce the file size – otherwise most people would just keep if as an uncompressed DVD on their hard drive (if they had almost unlimited space) (except for iPod/handheld which is not what I'm talking about). The resolution and bitrate must be balanced. What I'm saying is that although 720x576 is great for on a DVD when there's plenty of space, when it comes to encoding with x264 I'm trying to keep the filesize down (by slightly reducing the number of lines) whilst keeping great quality. At the moment I believe CRF is the way to go in producing a consistent quality. So for a rough output bitrate (I know it'll vary a lot for different movies) I have to balance the -q value and the resolution.

*** The conclusion I have come to is that encoding at 720x480 with a higher -q value is better than encoding at 720x576 with the -q value lowered to keep the same filesize. (Especially if the movie isn't quite pin-sharp, but still sharper than 720x400.)

Therefore I want to encode at 720x480 – which is still anamorphic video – "anamorphic" just means the pixels aren't square!

It doesn't seem to make sense to jump from 720x400 to 720x576 when considering output resolutions – most movies need the 720 pixels wide but not many need the full 576 lines. 720x480 feels sensible. (Don't get me wrong I think 720x576 is superior to 720x480 when you have plenty of space.)

Basically, to me keeping the full 720x576 only produces the best output quality when I'm using a CRF -q value greater than about -q 0.65 or maybe even 0.7. From the tests I'v done, I'd like to use CRF -q 0.63 (or maybe 0.64 / 0.65) at 720x480, because to use 720x576 without bloating the filesize I'd have to reduce this to something like -q 0.6 or -q 0.59 which produced annoying artefacts when I tried it. It's also effectively taking quality from horizontally and putting it vertically, isn't it?

Or, to put it another way, (for a given -q value) I figure I can knock about 20% off the filesize without affecting the quality significantly, so I really want to!!

On a related note, my thinking goes that there should be an optimim CRF -q value, because at high -q values I would be better off increasing the resolution instead (until we get into anamorphic stuff), and at lower -q value I would be better off reducing the resolution to maintain a decent q value. e.g. encoding at 512x288 CRF -q 0.7 is daft (unless it's a very low quality movie), and encoding at 720x400 CRF -q 0.5 is also daft (because res and -q aren't balanced). Or at least there should be an optimimum curve of resultion against CRF q value.

On another related note, is the perfect pixel square? (For video viewing with human eyes.) e.g. a PAL DVD is 720x576 = 414720 pixels. What would be the optimum width and height (hypothetically) for this number of pixels? e.g. are horizontal lines or vertical lines slightly more important, or exactly as important as each other? (I know that for a pixel ratio of 1:1 it would be 858x483 for 16:9, the question is is a pixel ratio of 1:1 optimum?) (Note that I'm not considering PAL 720x576 as the imaginary input source here – you could imagine is as HD 1920x1080p.)

[dynaflash]

nyargh, I was hoping for the new version to come out in a few days. Is it simply a case of compiling the updated code?

Well, to create the binary, yes. But, as jbrjake said, to even come close to having any remote sense of security stablity wise, we need more time to fix bugs and internally test before we publicly release a 15,000 download a day program only to find out there is some fatal flaw in it that no one saw because we were in a rush to release something. Resulting in a forum overrun by support requests for flaws we didnt take the time to address.

[jbrjake]

Yeah, that's right. Encoding is of course all about sacrifices, mainly to reduce the file size -- otherwise most people would just keep if as an uncompressed DVD on their hard drive (if they had almost unlimited space) (except for iPod/handheld which is not what I'm talking about). The resolution and bitrate must be balanced.

Yes, but with h.264, you can keep the resolution and still end up with something smaller than an uncompressed DVD. As long as my output is not DVD9 sized, I am happy. IMO, dot-by-dot anamorphic rips are so much higher quality than scaled down ones that I will always, gladly, accept the higher bitrates they incur.

Something else to keep in mind is that not scaling is part of why clee added the feature in the first place. He wanted to avoid the cpu-intensive rescaling to encode faster.

*** The conclusion I have come to is that encoding at 720x480 with a higher -q value is better than encoding at 720x576 with the -q value lowered to keep the same filesize.

Yes, but better still is encoding at 720*576 and leaving the q value the same...really, if I had easy access to PAL DVDs, I'd never shrink them down to NTSC size. An anamorphic PAL dvd is almost indistinguishable, for me, from 720p HD. Hell, that's what the pirates do these days...take high-def material and resize it to PAL size. Almost impossible to tell the difference.

Therefore I want to encode at 720x480 which is still anamorphic video -- "anamorphic" just means the pixels aren't square!

Yes I know what anamorphic means.

It doesn't seem to make sense to jump from 720x400 to 720x576

The whole point of the anamorphic function MediaFork currently provides is to not have any jumps at all....it preserves the visible DVD frame dot-for-dot. If you don't think this makes sense, take it up with clee. But I don't think he'll take very kindly to the notion.

Making anamorphic work with reduced resolutions is certainly possible, but it's not something I would *ever* use, so I'm not going to implement it. The only change I'm thinking about is an option to adjust the dimensions to mod16 values for better compression.

most movies need the 720 pixels wide but not many need the full 576 lines.

...

720x480 feels sensible.

...

It's also effectively taking quality from horizontally and putting it vertically, isn't it?

...

I really don't know what to say in reply to any of those three comments...except that they seem wrong in fundamental ways.

Or, to put it another way, (for a given -q value) I figure I can knock about 20% off the filesize without affecting the quality significantly, so I really want to!!

withOUT significantly affecting the quality?!

PAL full anamorphic (not from a DVD but the right dimensions):

NTSC full anamorphic:

The higher-resolution picture is always going to win. Just dedicate more bitrate.

You keep on saying things like

at high -q values I would be better off increasing the resolution

and

Basically, to me keeping the full 720x576 only produces the best output quality when I'm using a CRF -q value greater than about -q 0.65 or maybe even 0.7. From the tests I'v done, I'd like to use CRF -q 0.63 (or maybe 0.64 / 0.65) at 720x480

...but CRF/CQP works without regard to resolution. CRF only produces the best quality as you get to around 70% or higher. This is true regardless of resolution. Only the bitrate needed to reach it changes. The only thing I can think of is that your sources are low quality, and when you preserve each pixel you're preserving more artifacts that exist on the DVD, and at the lower resolution they get averaged away. In which case, rather than downscaling your encodes, you should be patiently awaiting the cross-platform release of AviSynth 3 like the rest of us. Once that's out, us Mac and Linux users will be able to preprocess our sources to remove such things like Windows users do.

Or at least there should be an optimimum curve of resultion against CRF q value.

All I can suggest is looking at these somewhat-related derived bitrate curves for CRF:
http://forum.doom9.org/showthread.php?t=116773

On another related note, is the perfect pixel square? (For video viewing with human eyes.)

Does it matter? It's not like you can adjust your display to use different pixel aspects, and as far as I know all operating systems deal solely with square pixels.

e.g. are horizontal lines or vertical lines slightly more important, or exactly as important as each other?

Vertical lines are more important, in my opinion. And not just slightly.

Oh yeah..and HD material is usually 1:1 par. Blu-Ray and HD-DVD, afaik, do not use anamorphic at all. Display width is 1920.

[Leo]

We seem to be arguing cross-points a bit, and you seem to often think I'm saying something different to what I am saying. If I comment on all your comments we'll just keep arguing about them, but I'll comment on a few.

Quote
It doesn't seem to make sense to jump from 720x400 to 720x576

The whole point of the anamorphic function MediaFork currently provides is to not have any jumps at all....it preserves the visible DVD frame dot-for-dot. If you don't think this makes sense, take it up with clee. But I don't think he'll take very kindly to the notion.

I think the anamorphic function is a good idea; I just think it should let you also do whatever anamorphic you like. My point was that the current version of MF forces you to jump from 720x400 to 720x576 because it won't let you do e.g. 720x480.

Yes, but better still is encoding at 720*576 and leaving the q value the same

I agreed with this before; but as I explained I want to save roughly 20% file size, and most films aren't as sharp as 720x576 -- they often have a lot of graininess to them which I think of as OK but not actual quality. And yes, a lot of DVDs have artefacts -- even well known recent ones, like The Island has artefacts that look quite like XviD, so I figure it's not bad to reduce them in the re-encoding.

[Me] It's also effectively taking quality from horizontally and putting it vertically, isn't it?

[your reply] I really don't know what to say in reply to any of those three comments...except that they seem wrong in fundamental ways.

No, think about it, if you're going ot only use 1500kbps for a frame, if it's 720x576 then more of those bits will go towards detail vertically (and therefore less horizontally) than at 720x400. Surely you agree that 720x400 looks better than 720x576 at lower bitrates? Therefore 720x480 also should. Othewise why would anyone ever use less than 720x576 except for iPods etc.

I think the q value thing confused things a bit -- it would have been more useful to imagine 2 pass encoding for a set bitrate.

heh, your example pics are extremely biased; try taking a frame from a 720x576 line movie and resize it to 1024x576 like a PC does. Then take the original frame and resize it to 720x480 and then to 1024x576; I think you'll find it looks less grainy but not much lower quality. (It may depend on the resize algorithm.) Lots of movies aren't crystal clear, and most have encoding artefacts anyway. You can prove this by looking at movies and noticing some aren't as clear/sharp as others. This particularly applies for older movies -- I recently encoded the film "The Ladykillers", the 1955 version, at 656x400, which isn't anamorphic because the movie has vertical bars at each side, and it came out great. Now I could have used the anamorphic feature to encode it at roughly 656x576 but I don't think I'd have gained much true quality because the movie just isn't that sharp and is quite grainy. (It would mainly have bloated the file size.) In fact, had I used 2 pass for the same file size the quality would definitely have gone down!

(Also, e.g. for series 1 of Friends, going from 720x576 to 640x480 loses hardly any quality, but ditches a lot of file size. Unless I were using something like q 0.7 on the 720x576 it would make sense to drop to 640x480 and increase the q value to match the size (or do two pass the get the same size, but better quality.)

*** I suspect that even encoding at 720x576 CRF q 0.65, whixch I think is too big, it would probably usually look better to use 720x480 with an appropriately higher q value to match the size! (At least I certainly think this would be the case for 720x576 q 0.6.)

The higher-resolution picture is always going to win. Just dedicate more bitrate.

I agreed with the first part, but I said I wanted to keep filesize down -- it's just like telling someone not to encode at 720x400 becasue it's not as good quality as 720x576 and dedicating more bitrate. Hey, you might as well do 1440x1144 crf q value 0.8 and it'd look awesome! lol, I am being slightly sarcastic.

Let's imagine that a movie is perfectly balanced in terms of q value and resolution at 720x400. To go to 720x576 and keep the same q value it'd have to be about 40% bigger, and it would be daft ot go up to 720x576 without increasing the file size. I only want to spend 20% extra and therefore 720x480 would be about right. Sure it's "only" an extra 20%, but when your movie isd 1600MB at 720x400 and just not quite sharp enough jumping to 2000MB 720x480 and getting most of that sharpness seems a lot more reasonable than jumping to 2400MB 720x576 and mainly getting the graininess in addition to 720x480.

Once that's out, us Mac and Linux users will be able to preprocess our sources to remove such things like Windows users do.

I only use windows; should I be pre-processing before using MediaFork?

Vertical lines are more important, in my opinion. And not just slightly.

In that case why isn't HD anamorphic? Also, would it not therefore be better fo rpeople to also use anamorphic at lower resolutions too -- e.g. using 576x400 for 16:9 content rather than 640x368?

Strictly just by the way, Microsoft's online sample 1080p WMV HD files are 1440x1080 (according to WMP). This I think is why my PC can just cope with playing them back, he he.

Oh yeah..and HD material is usually 1:1 par. Blu-Ray and HD-DVD, afaik, do not use anamorphic at all. Display width is 1920.

So what happens with 4:3 content?

Something else to keep in mind is that not scaling is part of why clee added the feature in the first place. He wanted to avoid the cpu-intensive rescaling to encode faster.

Yeah, but I think rescaling to 720x480 is still faster than 720x576 because 576 has about 20% more macro blocks!

Bottom line is that I might be willing to use 576 lines if the video is really clear with only minor artefacts, but I find it annoying that I'm forced to drop down to 720x400 otherwise, and what I was saying didn't make sense was that for 16:9 movies I was effectively having to choose between 400 and 576 lines.

take it up with clee. But I don't think he'll take very kindly to the notion.

I'd be interested to know what clee thinks of our discussion.

[clee]

Leo:

I understand where you're coming from. I also think that you're very silly and that the idea is flawed.

Here's why.

http://c133.org/par/

If you look at that page, it'll show you what your proposed idea will do to the quality of the image from the DVD.

Zoom in on some of the images there... I can do it and take screenshots and show you what the issue is. The original pattern is basically the worst-case scenario for any kind of scaling, but even without zooming in you should be able to see that it means serious quality loss.

But, fundamentally, the problem is that you're talking about scaling an already-scaled image, and that will always lead to more quality loss. The only acceptable things, in my opinion, to do with the video frames we're getting from the DVD are:
* crop out black areas (for really braindead letterboxed widescreen features)
* preserve original size, including aspect ratio

Any further scaling, either up or down, is going to result in more quality loss (and longer encode times!) which I'm against on principle.

That said... if you really really want this feature that badly, contact me (I'm on IRC as 'clee' on the Freenode network, on AIM as 'slashclee', and via email as clee@kde.org) and we can discuss it more.

-clee

[Leo]

Hi Clee, thanks for taking the time to make the sample images. They were pretty similar to what I imagined happening. I have to say that I think it would be a lot less of a problem in "real life" with a typical frame from a DVD that isn't crystal clear and has grain and DVD artefacts, but anyway:

I wasn't sure fully how much you were disagreeing with. Obviously 720x576 is the best choice when you've got plenty of bitrate, and your -p feature is great for that. However, if you were going to encode a 2 hour movie at 700MB or even 1400MB, would you still use 720x576? I'd probably use 576x320 and 720x400 respectively.

When filesize is limited, what would be the minumum crf q value you'd use with 720x576? Presumably for something as low as crf q 0.5 you'd think it was better to use 720x400 and an appropriately higher q value?

For old movies that aren't sharp do you think it's worth keeping the full 720x576?

Can I ask what settings you use to encode a DVD? (I'm asking out of interest rather than to be critical.)

[Leo]

No reply...??

[dynaflash]

Leo: obviously not.