Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - yetanotherid

Pages: [1] 2
1
Software Players / Re: Adjust the frame rate of mp4 files?
« on: March 13, 2012, 06:28:58 PM »
Any software which will re-mux video (copying the video stream rather than re-encoding) should be able to change the frame rate in the process.

Yamb for MP4s
MKVMergeGUI for MKVs. It's part of MKVToolNix (MKVMergeGUI will also open other file types such as MP4 and AVI and re-mux them as MKVs)
Virtualdub for AVIs (you need to select "direct stream copy" from the video menu after changing the frame rate).

If it doesn't matter if the re-muxed video is an MKV rather than an MP4, MKVMergeGUI is easier to use and faster than YAMB.

Of course the above will only change the frame rate of the video. If there's an audio stream which you need to keep in sync with the video then you'd probably need to re-encode it while changing it's speed to match. Getting that right can be a bit of a process. MKVMergeGUI does have a function for time stretching the audio stream, but how successfully it works depends on the type of audio.

2
H.264/AVC / Re: Why use 1 pass CRF for encoding DVD ?
« on: September 09, 2011, 11:36:29 AM »
How are you resizing the DVD (what is the output resolution)? Are you using anamorphic encoding or encoding with square pixels? Are you re-encoding the audio or if not, which audio track(s) are you keeping?

I encode using CRF 19 for DVDs (anamorphic encoding) and if I had to take a huge guess, I'd say they average out to about 2GB, so 7GB does sound rather excessive. I use MeGUI myself, but not the one click encoder, as I'm a control freak.

3
H.264/AVC / Re: Newb question: VC-1 stream to h264 ?
« on: September 07, 2011, 11:01:50 PM »
There's probably no need to get as close to the original bitrate as possible (you don't know how efficiently the source was compressed or the settings used when encoding it etc), just as close to the original quality as possible.
A CRF value of 16 definitely will give you transparent quality (I'm not sure I've come across anyone who uses a lower value and doing so could very well give you a file size larger than the original) but I doubt you'll see any difference using a CRF value of 18. I struggle to see much difference using a CRF value of 20.

If you must match the bitrate, then a 2 pass encode using the same file size for the video stream as the source would be the best bet.

The main difference between the two methods....
When you use a CRF value you're picking the quality but have no idea what the file size will be. The bitrate will vary (over the length of the video) according to what's required to achieve the desired quality.
When you use a 2 pass, file size encoding method you're effectively setting the quality in advance (by virtue of picking a file size) but you have no idea what that quality will be. The bitrate will still vary (over the length of the video) but by picking a file size you're telling the encoder the total number of bits to use in advance. In order to work out how to distribute them to maintain a consistent quality, it has to run two passes.

There may even be some rare circumstances where the source video is very hard to compress (because the quality is poor for example) so in order to achieve a transparent quality the bitrate of the encode needs to be greater than that of the source.

Personally, I can't see a point to running 2 pass encoding when CRF encoding is much faster (you're only running a single pass) and it lets you determine the quality. From one of the x264 developers:
http://forum.doom9.org/showpost.php?p=1373437&postcount=2396
"Given the same amount of encoding time, CRF is superior to 2-pass at the same bitrate. Given the same settings rather than the same time, they're effectively identical within margin of error. My recent tests show that CRF generally has a very slight edge, albeit the difference is so small that you'd have to have OCD to care."

It's probably best to experiment a little to determine what's best for you.
Once you've extracted the video stream to an MKV using MeGUI's HD Streams Extractor, use MKVToolnix http://www.videohelp.com/tools/MKVtoolnix to split off a 5 to 10 minute section of it and then run some test encodes to see what you're happy with. It'll probably be a good chance to make sure your encode plays well on your hardware player
Under MeGUI's x264 encoder configuration there's an option for selecting common target playback devices. The different options place different restrictions on the encoder (which effect how efficiently it can compress the video). Using CRF encoding it shouldn't matter. I'm pretty sure the quality remains the same while more restrictive settings will just produce larger file sizes. When running 2 pass encoding though, different settings may effect the over-all quality for a given file size. It's another reason why "matching bitrates" isn't really a valid way of matching quality.

There's a little bit of a learning curve with MeGUI but it's worth it as it's a good program. It has a "one click encoder" method or the normal "manual" method for setting up encodes. I generally use the latter method as it gives you full control. If you have any questions regarding using MeGUI I've no doubt I (or someone else) will be able to help.

4
H.264/AVC / Re: Newb question: VC-1 stream to h264 ?
« on: September 07, 2011, 06:10:11 AM »
MeGUI is a pretty good program for converting to h264. http://www.videohelp.com/tools/MeGUI

If you're not concerned about file sizes, using single pass CRF (constant rate factor) encoding will give you a consistent quality relative to the source video (the lower the CRF value, the higher the quality).

When encoding, I tend to resize everything to 720p rather than encode at 1080p as it keeps the file sizes down and the difference between 720p and 1080p on my 51" Full HD plasma is fairly marginal (I use a CRF value of 20 which produces an average file size of about 4GB with AAC audio).

Depending on who you ask, a CRF value of 18 (some say 16) is considered to be "transparent".

MeGUI has a HD streams extractor under the tools menu. Use it to extract the appropriate streams from your ripped Bluray file, then convert the extracted streams. You can keep the original audio track rather than convert it.

5
Newbies / Re: Remux ok, but in sync.
« on: August 23, 2011, 11:45:28 PM »
I find every now and then a small change in frame rate will fix the audio sync.
Once you've got the beginning in sync, try changing the frame rate to see if it effects the sync towards the end. Also, try specifying the original frame rate when muxing, if you're not already.

I've found (using ffdshow to display the frame duration) two videos can have the same frame rate (23.976 for example) but it's "rounded" by the muxing program or the program supplying the original frame rate info. It's generally only a small difference, the frame duration might only differ by 1 or 2ms, but it can be enough to have a program assuming 23.976 when 23.975 would be closer to the original. It doesn't seem to happen very often, but it does happen.

Anyway, if the original frame rate is 23.976, try 23.975 or 23.977 to see what happens.

I can't help you with determining the audio delay used in the original wma files as I never work with them. Your best guess might have to do.

6
Video Containers / Re: .AVI extension on XP
« on: August 20, 2011, 03:46:12 PM »
Most players will open video files from the SendTo menu.

Why not leave it as an AVI and put a shortcut to your custom viewer in the SendTo menu? That way WMP (makes me shudder to even think of using it) will open the files using a double click and with one extra mouse click you can open the video with your custom viewer instead. Assuming it opens AVIs....

Right Click - SendTo - Custom Viewer.

Or alternatively you could associate the custom viewer with AVIs and put a shortcut to the Windows Media thingie in the SendTo menu, if there's not one there already.

I've got shortcuts to many of my favourite programs there. Some don't play nice. The worst that can happen is the file won't open, but most programs do.

7
MPEG-4 (A)SP / Running mutliple instances of AutoGK
« on: July 04, 2011, 12:14:54 AM »
Running Mutliple Instances Of AutoGK

After years of using AutoGK I learned something new today. I'm posting this information just in case, like me, other AutoGK users had no idea you could open more than one instance of AutoGK at a time.

As much as I like AutoGK it's started to frustrate me that it... or XviD... aren't all that great at utilising a CPU, especially a quad core (or more) CPU. Of course there's not much you can do about it but it'd be nice if you could at least keep that CPU busy by running more than one encode at a time.

Today I discovered you can. Open your AutoGK shortcut and add "-multi" to the end of the target line. So it'll look something like this:
"C:\Program Files\AutoGK\AutoGK.exe" -multi
Now you can use the shortcut to open multiple instances of AutoGK. The only thing you need to be aware of.... when running more than one instance of AutoGK at a time you must save the output files to different folders. It's because AutoGK creates a temp folder in the same location as the output file and if more than one instance of AutoGK is trying to use the same temp folder you'll get errors. Just create a separate output folder for each output file and you'll be fine.

When I think of all those times I'd at least have liked to be able to set up and preview a second or third encode while one is already running, or how long I could have been encoding two DVDs at a time..... I'm not sure if I'm happy I can now do so, or if I want to have a little cry.....

8
Newbies / Re: Want to start x264 encoding... where do I begin?
« on: June 22, 2011, 03:00:38 PM »
Start with an encoding GUI. One of the most straightforward is HDConvertToX. It does require the installation of additional software but you'll find the list when you download the program.

One of the most popular encoder GUIs is MeGUI. It's got a little more of a learning curve but it's a good program. I use it regularly.

Both HDConvertToX and MeGUI will encode a wide variety of video types using the x264 encoder and save the output as MP4 or MKV files etc. There's no doubt several guides to using MeGUI which you'll find via Google. Probably the same for HDConvertToX.

You'll find both programs easily enough using Google.

9
MPEG-4 (A)SP / Encoding MKVs and MP4s using AutoGK (Part two)
« on: June 22, 2011, 05:14:53 AM »
Encoding MKVs and MP4s using AutoGK (Part Two).

Preparing a (MKV, MP4) video file for conversion using AutoGK.
(We're actually creating a tiny AVI which AutoGK can open and encode but which contains no actual video. It just points to the video file we're really encoding)

Let's assume you have a video file called movie.mkv. It's a HD video which we want to convert to SD AVI using AutoGK. We will therefore use the color conversion template we created after installing AVISynthesizer (we'll also assume we keep working/saving files to the same directory where movie.mkv resides).

Step one: Open MKVcleaver and use it to open the original MKV file. Select the appropriate audio track (if there's more than one) then hit "extract". Fairly soon you'll have your audio track extracted and saved to your hard drive. If it's AC3, DTS or MP3 then you can use it "as is". If it's AAC you'll need to convert it to AC3 or MP3 manually (not covered in this guide).

Step Two: Right click on movie.mkv and select SendTo/AVISynthesizer. A window will open with a list of templates. Select the "DirectShowSource Colour Convert - no audio" template created when installing AVISynthesizer. In a few seconds AVISynthesizer will create a simple script and save it to the same directory as movie.mkv.

Step Three: Right click on your newly created script and select "wrap into AVI" (this option was installed by avs2avi). A command prompt window will open and in a few seconds it'll prompt you to "press any key" to close the window. A newly created AVI will be saved to the same directory. This AVI can be opened with any media player and it'll play the video contained in the original movie.mkv file. ffdshow should decode it.

Step Four: We now need to mux the audio track into the tiny AVI we just created.
Open VirtualDubMod and then open the newly created AVI. From the top menu select Streams/Streams list. When the new window opens select the "Add" button and open the audio stream which was extracted from the original movie.mkv file (or the manually converted version if it was AAC etc). Once it's loaded select okay.
From VirtualDubMod's top menu select File/SaveAs and save it as a new AVI. Make sure AVI is the selected file type and most importantly of all, make sure in the bottom "video mode" box you select "direct stream copy" or VirtualDubMod will convert the video rather than just save it.

If all goes well you now have a second AVI which also contains an audio type supported by AutoGK and which you can load into AutoGK and convert in the usual way.
Don't delete or move the original MKV file or the initial script created, otherwise your newly created AVI won't work. You can delete the intermediate files once the conversion is completed.

I use the above process regularly (and the need to convert AAC audio manually aside), the whole process takes a minute or so and I have and AVI ready for converting with AutoGK.

When converting MP4s the above process is exactly the same but instead of using MKVCleaver to extract the audio you'd use YAMB.

Additional note one:
As ffdshow will be decoding the video it's possible to use ffdshow's filters during the encoding process. For instance you can apply some sharpening using ffdshow if you wish. I find using "unsharp mask" as the sharpener works well, although I'd never use more than a level of 15 as I don't like "obvious" sharpening. Asharp also works nicely (in fact I prefer it). I think it's basically an adaptive unsharp mask. A threshold of 0.9 and an adaptive strength of 3 adds a subtle sharpening.
ffdshow can also be used to resize the video to the correct aspect ratio if the original MKV or MP4 happens to be anamorphic (doesn't use square pixels). Just don't enable any filters while creating the initial AVI which AutoGK will re-encode. They can be enabled afterwards or while previewing the encode with AutoGK.

Additional note two:
For those who've pondered over the concept of being able to frame accurately edit an MKV or MP4 file before converting, the above method has always allowed me to do so.
You create your script, wrap it into an avi, open it with VirtualDubMod, load the audio stream.... and before re-saving it you can edit it as desired.... then just resave the edited version for re-encoding.
Actually, it's better to use VirtualDub for the job rather than VirtualDubMod. For some reason, when cutting and joining AVIs containing AC3 audio, VirtualDubMod seems to add non-audio data to the AC3 stream where it's cut. It doesn't matter if you're keeping the AC3 audio, but when converting it the non-audio parts get skipped and this can cause slight audio sync issues. It seems this doesn't happen when you edit video containing AC3 audio with VirtualDub.

10
MPEG-4 (A)SP / Encoding MKVs and MP4s using AutoGK (Part one)
« on: June 22, 2011, 05:09:50 AM »
Encoding MKVs and MP4s using AutoGK (Part One).

I started writing a guide to using AutoGK to encode file types is doesn't natively handle (mainly focused on MP4 & MKV). It's still rough as I never got around to finishing it properly but I thought I'd post it here. It might help give AutoGK a bit more longevity for some people, which would be nice as it's a great program. I still use it this way regularly.

I've divided the guide into two posts. The first is the annoying "one time only" stuff which needs to be installed and configured. This is the stuff which eventually makes it fairly easy to set up an AutoGK encode of an MKV or MP4 file. Many seasoned video encoders will already have much of it installed.
The second post is the fun stuff, which explains how to take an MKV or MP4 file and convert it with AutoGK. Once the following software is installed and configured and you've done it a few times, setting up an encode of an MKV or MP4 file only takes a minute or two.

Encoding MP4 and MKV files using AutoGK.

This guide explains how to use an AVISynth script to allow AutoGK to encode file types it doesn't natively support. Almost any type of video you can play on your PC can be converted using AutoGK with a little preparation. This guide assumes you're familiar with AutoGK, ffdshow and the Haali media Splitter. It doesn't matter if you're not familiar with the latter two, just Google, download and install them. We'll also be installing and configuring a few extra utilities which let us create an AVISynth script and then an AVI for AutoGK to convert (for those who aren't familiar with doing it the "manual" way).

When it comes to audio AutoGK supports AC3, DTS and MP3 but not AAC. If the original video file contains any of the first three we can use AutoGK to convert it, if not it needs to be converted "manually". The audio side of converting won't be covered too extensively here, but for the most common video file types (MP4 and MKV) we can simply extract supported audio streams from the original file and add them to the AVI we're going to create for AutoGK to convert.

The most common "problem" audio type you're likely to meet will be AAC. I convert it using foobar2000 (http://www.foobar2000.org) as it'll open, play and convert the audio inside MKV and MP4 files directly. It'll also mix multichannel audio down to stereo while converting (which you need to do if converting to MP3). Foobar2000 requires the installation of third party encoders, the most common being the LAME MP3 encoder, AFTEN AC3 encoder and Nero AAC encoder. It also requires additional third party plugins to decode some audio types, but once it's set up, foobar2000 makes converting the audio easy. It is though, a different topic, so I won't cover using foobar2000 here.

This guide will assume you're converting either MP4 or MKV files. It'll assume the audio tracks are of a type AutoGK can convert. It'll assume if the original audio is an unsupported type such as AAC, you've converted it manually to either AC3 or MP3. Any video type can be converted using this method.... for more exotic container types it's actually handling the audio which gets trickier, so we'll primarily look at converting video using AutoGK while including audio types it does support.

Required software:
ffdshow tryouts (http://ffdshow-tryout.sourceforge.net/)
Haali Media Splitter (http://haali.su/mkv/)
AVISynthesizer (http://tangentsoft.net/video/asynther/)
avs2avi (http://hmage.net/files/avs2avi-0.3.zip)

For converting MKV files:
MKVcleaver (http://www.videohelp.com/tools/MKVcleaver)
MKVtoolnix (http://www.videohelp.com/tools/MKVtoolnix) (required for MKVCleaver to work)

For converting MP4 files:
Yamb (http://yamb.unite-video.com/)

Installing and configuring the additional software:

Installing AVISynthesizer is just a matter of running the exe. Once it's installed navigate to the installation folder, then the templates folder. We're going to make two addition templates for creating AVISynth scripts.
Open notepad. Copy and paste the following:

#ASYNTHER DirectShowSource - no audio
[DirectShowSource("%f", audio=false)]

Save the notepad document as "DirectShowSource - no audio.avst". Make sure it's extension is avst rather than txt. Move the new template to the AVISythesizer templates folder.
Now repeat the process for creating a second template. This time copy and paste the following into notepad:

#ASYNTHER DirectShowSource Colour Convert - no audio
[DirectShowSource("%f", audio=false)]
LoadPlugin("C:\Program Files\AutoGK\filters\ColorMatrix.dll")
ColorMatrix(mode="Rec.709->Rec.601", clamp=0)

You'll need to modify the LoadPlugin path according to where AutoGK is installed on your PC.
Save the template as "DirectShowSource Colour Convert - no audio.avst". This template will be used when converting high definition sources to standard definition AVIs as to do it correctly, color correction usually needs to be employed. For other conversions (SD to SD, HD to HD) the first template will be used.

We've now finished setting up our templates for creating basic AVISynth scripts.
Next we need to install AVS2AVI. To install AVS2AVI simply unzip the downloaded zip file, right click on avs2avi.inf and select "install".

Installation of MKVCleaver, MKVToolnix and YAMB should require no explanation and don't require any configuring (with the exception of MKVCleaver which requires you to tell it where MKVToolnix is installed the first time you run it or it won't work).

For those who are unfamiliar with using VirtualDubMod, if you've used AutoGK you'll have no doubt seen it running as AutoGK converts your video. We need to use it manually while setting up our conversion. Ideally the version of VirtualDubMod which installs with AutoGK should be upgraded to the last available version (1.5.10.2). I won't bother with the details for doing so here, the version which installs with AutoGK will suffice, it's just a bit slower at preparing our AVI than the last version.
For convenience navigate to your AutoGK installation folder, then the VirtualDubMod sub-folder and create a shortcut to VirtualDubMod.exe. Move the shortcut to your desktop or somewhere it's easy to access.

That's all the installing and setting up taken care of. All of the above is a "one time only" thing which simplifies the process of actually converting the video. Next I'll explain how to prepare a video file for converting. It's a fairly quick and straightforward process once you've done it a few times.

11
H.264/AVC / Re: A handy little app my brother made for me...
« on: May 22, 2011, 10:06:06 AM »
Thanks for offering the program to others.

Me.... I personally prefer to do it the other way around. Rather than crop and then resize to the closest mod16 dimensions, I prefer to pick the width I want, then crop a little extra if necessary until it'll resize down to fit into mod16 dimensions.

Generally I convert to 720p, which means a width of 1280, and the height is of course subject to cropping the black bars. Sometimes the sides need a few pixels cropped anyway, but I don't mind losing a few more from the sides if necessary to minimise the aspect distortion.

The only encoder GUI I know of which still calculates aspect ratio distortion for you is HDConvertToX. It lets you pick your resized dimensions then calculates the aspect ratio distortion as you crop. It's fairly easy to crop what's necessary, then adjust it (crop a few more pixels from the sides etc) if necessary until the aspect ratio distortion is virtually zero.

Mind you I generally don't fuss too much about mod16 either. The only time I try to stick to mod16 is when encoding to 720p and the video virtually doesn't require cropping. That way I end up with 1280x720 (16:9). For encoding to SD and those times I use XviD, it's handy being able to calculate the aspect ratio distortion while cropping and resizing to mod16 dimensions.

12
Encoder GUIs / Re: MeGUI Colour Correction
« on: April 18, 2011, 12:44:59 AM »
Quote from: J_Darnley on April 17, 2011, 04:17:02 AM
And if you can't see a difference, ignore it, don't use ColorMatrix(), don't set anything on the command line.

Yeah I think that's what I'll be doing from now on. It's pretty easy to enable/disable colour correction in MeGUI and refresh the preview to see if it makes a difference. If it does I'll keep checking the corrected colours against the original video until I'm sure it's always getting it right (as opposed to changing the colours when it's not needed). I won't use the BluRay presets in MeGUI until I understand why they add the stuff they do to the command line.

13
Encoder GUIs / Re: MeGUI Colour Correction
« on: April 17, 2011, 09:10:18 AM »
Quote from: J_Darnley on April 17, 2011, 04:17:02 AM
How is this different to: movie = ConvertToYV12(movie)  This will use Rec601 coefficients when doing the RGB->YUV conversion

That's the problem. I'm a beginner when it comes to understand the colour conversion aspect so I don't know when various colour coefficients will be used. This is what I'm trying to understand. There is a brightness difference but it's not a TV/PC levels type difference.

Can I give you an example and get you (or someone) to explain to me what's happening step by step If I'm getting it wrong? I'll keep it to mpeg2 to mpeg4 conversion because that's really the type of conversion I'm wanting to understand.

I recorded a 720p mpeg2 file and opened it with Gspot. Here's what it looks like.



When converting the video with colour correction MeGUI adds this to the script:
ColorMatrix(hints=true, threads=0)
AutoGK adds this:
ColorMatrix("Rec.709->Rec.601",opt=0,hints=false,threads=0)

I don't really understand the difference but in this case they both have exactly the same effect on the picture.
Below are two screen shots (edit: swapped original images for better ones, although the difference still isn't as obvious when displayed in a browser. Green is greener in the second pic).

Screen shot A.
This is how the mpeg file displays when opened directly with MPC-HC.
It's also how the (converted) video displays after colour correction is applied.



Screen shot B.
This is how the video displays when using a simple mpeg2source script to open the d2v file directly.
It's also how the video displays when using a simple directshowsource script to open the mpeg file directly.
It's how the video displays without colour correction.



Okay, so I finally found a sample which shows the difference colour correction can make (I assume screen shot A is actually the correct colours?) even though whenever I've encoded DVDs in the past and checked I've not seen it make any difference. I assume the DVDs I've checked must have been R.601 and colour correction has therefore had no effect?

Here's where I'm confused as to what happens when encoding with XviD v x264. Correct me if I'm making false assumptions but I assume the above video is R.709. Well it is according to DGIndex even though it appears to me Gspot disagrees. But assuming R.709 is correct then colour conversion to R.601 is correct as the way I understand it XviD always uses R.601 coefficients when encoding (and I assume also when the video is decoded) so all is well.

But what if I encode using the x264 encoder? Which colour co-coefficients does it use for encoding (and which are used for decoding)? I'd assume it can encode using either so that's where I'm getting confused. Does it default to R.601 for SD and R.709 for HD, making it necessary to convert the colours when encoding some DVDs?

Which takes me back to my original post and what happens when encoding with MeGUI using the BluRay preset. It adds "Color primaries : BT.709-5" etc using the x264 command line which seems illogical if colour conversion to R.601 is taking place. Maybe I'll just have to ask the guy who puts together the presets for MeGUI.

I'm just trying to ensure I eventually understand how this all works. Comments anyone?

14
Encoder GUIs / Re: MeGUI Colour Correction
« on: April 17, 2011, 12:55:55 AM »
I deleted my previous two posts as they read like me thinking out loud (which I was, I guess) so now I've done some more reading and experimenting here's where I'm up to....

Code: [Select]
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177
The above is only added to the media file's "properties" (media info) by MeGUI when using the BluRay preset (via the x264 command line). It adds the same whether converting to SD or HD. It appears to be nothing more than a "suggestion" to the media player and in reality probably has nothing to do with the colours used or any colour conversion when encoding.
Groucho2004, your suggestion to use --colorprim etc in the command line seems to be what causes x264 to write the above information to the stream but as I said it doesn't seem to be directly related to the colours used. In fact from the x264 help files:

"Video Usability Info (Annex E):
The VUI settings are not used by the encoder but are merely suggestions to
the playback equipment. See doc/vui.txt for details. Use at your own risk."

So if I'm not sure of the colours used wouldn't writing VUI settings probably be a bad idea?

Quote from: Groucho2004 on April 12, 2011, 12:55:39 PM
In general, I suggest you use ColorMatrix when you convert from SD (BT601, BT470-2) to HD (Rec.709) or vice versa like this:
Code: [Select]
ColorMatrix(clamp=0, interlaced=false, opt=0, mode="Rec.601->Rec.709")
ColorMatrix(clamp=0, interlaced=false, opt=0, mode="Rec.709->Rec.601")

Okay, I tried it and yes it makes a difference. What seems to happen is the majority of the time it just brightens or dulls the video a little, however when converting some HD sources to SD, using ColourMatrix corrects the "hue". "Rec.601->Rec.709" seems to add a greenish hue, "Rec.709->Rec.601" a reddish hue. The former seems to correct the colours when I converted a couple of test HD sources to SD.

Finally back to DVD conversion which is what started me looking at colour conversion.....

MeGUIs colour correction option is only available for DVD/mpeg sources. It seems to load the AVISynth plugin ColorMatrix.dll which obtains the colour info from the d2v file and converts it if need be. I tried a couple of DVD conversions with and without colour correction enabled but it didn't seem to make any difference. I guess I'll just leave it enabled as it no longer seems to have the bug which messes with the colours so I assume at worst it'll do no harm.
I did read the following regarding AutoGK's colour correction option in it's help files:

""Color correction" option allows you to slightly change color gamut closer to what the source actually contains (gamut often is changed automatically when doing MPEG2 -> MPEG4 conversion because of the tool involved, i.e. avisynth)"

It pretty much implies AVISynth automatically changes the colours during the process of converting and the colour conversion plugin isn't necessary much of the time. This is from an AutoGK script and I've seen it in some HDConvertToX scripts. Does it have anything to do with the type of colour conversion under discussion?

Code: [Select]
movie = isRGB(movie) ? ConvertToYV12(movie) : movie
movie = isYUY2(movie) ? ConvertToYV12(movie) : movie
I still have many questions....

- Is there a way to reliably determine the colours specified for a video (if they are specified), whether it be DVD, AVI, MKV etc?
- Which colour gamut is generally used with DVD video and if the colour information isn't specified what does the encoder assume, Rec.709 or Rec.601? The mpeg specs seem to say one thing while forum wisdom says the other.
- Under which circumstances would AVISynth automatically convert the colours and when does it require the ColorMatrix.dll plugin for DVD conversion?
- Why does converting the colours mostly only seem to effect the brightness of the video while sometimes it makes quite a noticeable difference to the hue?
- Should I ever need to add ColorMatrix() to an AVISyth script when converting DVDs (no upscaling)?
- And finally.... as long as my encodes look the same as the source when I play each on my PC, should I just forget worrying about the colours used and assume they are correct?

Any answers anyone?
Thanks.

15
Newbies / Re: Merged files are async :-(
« on: April 13, 2011, 06:09:22 AM »
Regarding the location/seek bar in MPC-HC. Yes I had the same problems using it with your ts files as you do. Either the video would get stuck, or there'd suddenly be artifacts etc. But I think that's just an issue with you particular files. The seek bar works perfectly with all the other media files I have.I'm using the same version of MPC-HC as you are.

I'm no encoding expert and definitely no expert when it comes to de-interlacing. Maybe I couldn't de-interlace your samples properly because joining them had corrupted them. When trying to deinterlace them I'd end up with a video with lots of artifacts as per my 4th screen shot. Using the Yadif de-interlacer seemed to work best (it's the one used for the third screenshot) so maybe try it on your complete ts files. I've not had a lot of experience de-interlacing HD material but I think the motion blur is just an unavoidable side effect. Your MKV sample seemed to be de-interlaced properly but it looks blurry when the camera is panning quickly due to the motion. The higher the definition the more noticeable the motion blur seems to be.
I do recall recording some 1080i programs a while back and had exactly the same problem. They had enough motion blur to begin with and the encodes looked quite blurry too so in the end I just gave up and found somewhere to download them. Just about everything seems to be broadcast interlaced where I am (Australia). Maybe that's one reason why I download everything I watch.

"If you are recording a concert, opera, film, fiction, ok. but if you are recording a soccer match or most of all the GP Formula One with a lot of fast running shots...you get a disaster!! here the (very good) Handbrake fails, you get a progressive output witch looks worse as the interlaced source (I tried detelecine on, then off, default...nothing to do).
hmmm perhaps I have to wait for DVB-T2 at 1080p50!"

That pretty much described the problem I was having with my recordings. I found when playing the interlaced source it'd still look  blurry (played on a progressive monitor), but when de-interlacing and encoding, the encodes would look just as bad or even worse. Personally I think the sample MKV you uploaded in the other thread is about as good as the de-interlacing will get.

"hey the third photo looks perfect!!!
this is the result I'm looking for!! very fine! how to do to get your result? You have used MeGui and your graphic card..."

I don't think it's perfect, it just doesn't look too bad because it's a single frame, possibly where the camera wasn't panning quite as fast or where the people in the shot had stopped moving as much, and because I reduced the resolution for the screen shot.
I used MeGUI to take the screen shots. Once you setup an encode you can preview the AVISynth script it's creating. All I did was pause the preview video, take a screen shot (1st image), enabled the de-interlacing, refreshed the preview and took another screen shot (3rd image).

"I was so happy with Handbrake, but at this point (at the sequence you posted) I get very a strange effect (http://rapidshare.com/files/456030122/1-1__1_.mkv):
also after processing in HB, the "mice's thooths effect" disappears (good!), but...the faces of the actors are shimmering and changing their colours (not good).

That's supposed to be a different video from the original samples?? I'm not seeing any shimmering or colour changes there but the video does seem to stutter in places.

"I dont know if my GPU is able to do this good deinterlacing you get...but for my purpose the most important thing is that I are able to watch the output on my tv set (not on PC)."

The GPU would only be deinterlacing when playing interlaced video, it wouldn't have anything to do with deinterlacing when encoding. Is your TV progressive or interlaced? I assume it's not an old CRT? If it is maybe you could encode the video without any de-interlacing, but if it's a progressive TV I'd be thinking your MKV sample is probably about as good as it gets. Or maybe try a different deinterlacer to see if the results look any better. Using MeGUI, I thought either the Yadif or the TomsMoComb deinterlacers looked best.

16
Encoder GUIs / Re: MeGUI Colour Correction
« on: April 12, 2011, 11:25:23 AM »
Quote from: Groucho2004 on April 12, 2011, 07:54:17 AM
Here:
http://forum.doom9.org/showthread.php?t=133982
is a lot of info.

Thanks for that. I did a lot of reading, but I'm still a little confused as to what's going on. From what I understand of what I read, SD DVDs are generally BT.601, so even with the colour conversion option enabled in MeGUI BT.601 would still be used when encoding to standard definition (no colour conversion would take place). It would also appear the WMR9 renderer (which I'm using) uses BT.601 for SD and BT.709 for HD regardless of the specified colour space. That would explain why my SD encodes look the same on my PC whether I encode using the x264 encoder (colour correction enabled or disabled) or using the XviD encoder.

So I'm left with trying to understand (assuming I've got it right so far) why my SD encodes using MeGUI always specify BT.709. I guess it's as Mr VacBob said (and now maybe I understand why) that it's possibly an MeGUI bug. I'd also assume if I played those encodes on a player which obeys the colorimetry in the stream, the displayed colours would then be wrong. Which seems a little disappointing considering the number of DVDs I've encoded with MeGUI.

Is it possible every DVD encode I've checked so far really came from a DVD using BT.709 and MeGUI is getting it right? I suppose I should dig out a couple of the original DVDs later on today and check them with GSpot to make sure.

How am I doing so far? And should I stop using MeGUI if I want to ensure the colours are always displayed correctly?

Quote from: Groucho2004 on April 12, 2011, 07:54:17 AM
Apart from that - Real men don't use a "gui".  ;D

I hate working on cars and I'm a terrible handyman so I've no delusions about being a real man. I do keep all my emotions bottled up though so I'm not a complete girl. ;D

17
Encoder GUIs / Re: MeGUI Colour Correction
« on: April 12, 2011, 03:11:43 AM »
Well I tried a short encode using colour correction, then one without. MPC-HC reports the same thing both times.

Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

I also encoded the same video using HDConvertToX. There was no colour info in amongst the media info that time.

I'm more confused than ever because all three encodes looked to have exactly the same colours to me. I had all three maximised on my monitor and synced up so I could switch between them and if there's any colour difference I can't see it. Should I be able to see a colour difference?

 At least I assume it's now safe to use MeGUI's colour correction. It doesn't seem to mess with the colours any more.

Thanks.

18
Newbies / Re: Merged files are async :-(
« on: April 12, 2011, 03:03:37 AM »
Quote from: anuswara on April 11, 2011, 04:04:55 PM
I remember that in the past I have disinstalled MPC from my old PC because the cursor dont worked. And now the same issue with my newer pc.

When you say the cursor doesn't work, do you mean the mouse doesn't work?

Quote from: anuswara on April 11, 2011, 04:04:55 PM
no. my TS files are ok, because they work fine with powerdvd and on a standalone bd player and on a media player.

I downloaded the samples you linked to in your other thread. Those ts files certainly seem to have issues. Playback with MPC-HC was only reliable if I played them from the start, but there's lots of compression artifacts. The second one crashed VLC.

Quote from: anuswara on April 11, 2011, 04:04:55 PM
the 1080i50 (European dvb-t broadcast) content is very very hard to handle with, this happens most of all when the camera take a horizontal running shot [[oh my good, see please my post here. this reencoding process is so hard that the HB's developers itself are unable to help me.
http://doom10.org/index.php?topic=1532.0 ]]

Well I tried encoding them using Megui and several different types of deinterlacing. Your StaxRip encodes seem to be about as good as it gets. Aside from the fact both ts files crashed MeGUI when I tried to analyse them, they still seem to have problems although I don't understand what they are. It's almost like the fields aren't always lined up properly horizontally.

For instance this is what I'd assume would be normal when looking at a frame without deinterlacing.



Yet the very next frame looks like this.



After deinterlacing:





Yet the same section of video plays fine on the PC with the video card doing the de-interlacing. It's over my head, but I certainly couldn't do anything better than you've already done.

19
Newbies / Re: Using Staxrip to remux large H.264 MKV file ripped with DVDfab Blu-ray Ripper.
« on: April 10, 2011, 10:58:13 PM »
I don't think I've ever made a 720p encode which has topped 5GB using a CRF of 19. They seem to average about 3GB. I can't see the difference between my 720p encodes and the original disc (not on my TV or computer monitor at least). I think If I had to choose between 720p CRF19 medium preset and 1080p using the fastest preset and higher CRF, I'd choose 720p every time. Not that I've ever compared the speed difference, but I think the 720p encode would look better and the file size is much smaller. Maybe try a comparison 720p encode using a better quality setting and slower preset to see what the speed difference is and if the encodes look any better.

I must admit I've never been a StaxRip fan (well not since the early versions). I don't think that necessarily makes it a bad program but it definitely doesn't work the way my brain works. I much prefer MeGUI, or for a program which still gives quality encodes while being mind-numbingly easy to use (well almost) HDConvertToX. Both will still give you the same same x264 preset options as StaxRip, and MeGUI has lots of presets for hardware compatibility (I know Staxrip does too but using them didn't seem all that straight forward to me). I find I can get my head around what MeGUI and HDConvertToX are doing more than I can with Staxrip. But that's probably just me....

20
Newbies / Re: Merged files are async :-(
« on: April 10, 2011, 10:19:26 PM »
I don't have any h264 ts files on my PC but I'm pretty sure I've played them with MPC-HC before without any problem.
I do have a couple of mpeg2 ts files on my PC (I just recorded them using my Winfast capture card) and MPC-HC played them without an issue. The speed increase and decrease buttons also worked as they should.

Which OS are you using? I'm wondering if changing the renderer might solve your issues. I'm using XP and I generally find the WM9 renderer when using MPC-HC works best (EVR is generally a disaster), although I just changed it to the overlay mixer and tried playing a ts file again and everything was still okay. Maybe your ts files are damaged in some way?

Can you record programs as a program stream rather than as a transport stream? It might make your life easier if you can just work with mpeg files rather than ts files.

I can only suggest (as far as getting MPC-HC to play your files okay) installing the Haali media splitter, disabling MPC-HC's internal ts source filter and playing a ts file that way to see if the Haali splitter does a better job with your files. You can still leave all the appropriate transform filters enabled in MPC-HC so it can still decode the video using it's internal filters.
I used to use Haali and ffdshow for just about everything but I actually switched to using MPC-HC's internal filters for playback as it seemed to fix the audio sync problems I was having occasionally (mostly with MP4s). I pretty much only use Haali and ffdshow these days for some encoding jobs.

Only other suggestion...... I pretty much try to avoid like the plague having anything other than MPC-HC, Haali and ffdshow installed. I won't install any other software (playback or encoding) which installs additional system codecs or media splitters etc. Since doing so, I've had virtually no playback problems.
You could try installing the Combined Community Codec pack (it's basically MPC-HC, Haali and ffdshow anyway) only when it installs it'll scan your system for anything which it thinks will interfere with it's ability to play files correctly and ask if it can disable them. In fact thinking about it you probably wouldn't even have to install the CCCP. Just let it disable the stuff it doesn't like and then cancel the installation. I recall there were a couple of times I had problems playing certain files (when I used the CCCP) but after running the installer and letting it disable what it didn't like the files played okay. Doing so never effected any other software's ability to play files.... at least not that I was aware of. As a result after my last reformat I only installed MPC-HC, haali and ffdshow and to date everything plays okay (well aside from one issue playing AVISyth scripts but that's another story). I'd assume there can be conflicts involved which are beyond my understanding, aside from how to eliminate them.

Just some thoughts....

PS I should add I do also have VLC installed as an alternative player for those times I do need to play problem files, but to the best of my knowledge it doesn't install any system codecs etc. It uses it's own internal decoders which shouldn't interfere with anything else. Since my last reformat 6 months ago, I've only used VLC once, and that was to play a file to check it was working okay after I installed it. I don't think I've had a need to use it again since.

21
Newbies / Re: Using Staxrip to remux large H.264 MKV file ripped with DVDfab Blu-ray Ripper.
« on: April 10, 2011, 09:01:17 PM »
Remuxing involves simply copying existing video and audio streams etc and muxing them into a new MKV. There's no encoding involved and the process should be as quick as your hard drive can read and write. It seems like you're encoding, not simply remuxing.

I have a Q9450 overclocked slightly to 3.2ghz. I also have a E6750 overclocked to the same speed. When encoding using the x264 encoder the dual core takes basically twice as long as the quad core.

I always resize my BluRay encodes to 720p. Are you resizing or encoding at 1080p? If memory serves me correctly, the quad core averages around 15 to 20 fps, but at worst I think I'd be looking at 3 hours or so to encode a movie (720p). I only use single pass encoding though with a CRF of 19 and the medium speed preset. I can't see any point to 2 pass encoding as it takes about twice as long and I'm not too concerned about the file size (the only reason for bothering with 2 pass encoding). I never use the dual core PC for x264 encoding as it's too slow. It does the XviD stuff.
Using the same settings the quad core usually encodes a DVD in around "real time".

I've tried decoding with my GPU and the CoreAVC decoder, but using my GeForce 8600GT video card it slows the encoding process down slightly compared with using the CPU for decoding (and I've no idea whether you can decode with the GPU when using StaxRip).

You need a faster CPU. Definitely a quad core (at least) if you're after speed. I'm not sure whether a really fast GPU doing the decoding would speed things up all that much. Someone else might know. There's some CPU performance charts here which might give you an idea what to look for.
http://www.tomshardware.com/charts/processors,6.html
http://www.cpubenchmark.net/cpu_lookup.php?cpu=Intel+Pentium+Dual+E2200+%40+2.20GHz

I'm planning on upgrading my dual core PC to an Intel Core i7-2600 in the near future as I seem to do a lot of BluRay encoding these days.
So how bad/good did the CRF22, very fast encode look?

22
Encoder GUIs / Re: MeGUI Colour Correction
« on: April 10, 2011, 08:24:29 PM »
Later today I'll rip a DVD again and convert it with colour correction enabled and then with it disabled.

Would it be safe to assume I should see a difference between the colour of the two encodes? I'd also assume the one which uses colour correction should look the same as the original DVD?

Anyway, I'll try a couple of encodes and report back.

Thanks.

23
Newbies / Re: Advantages of x264 presets
« on: April 10, 2011, 06:24:24 AM »
Quote from: J_Darnley on April 09, 2011, 04:30:19 AM
x264's presets don't control hardware compatibility.  They control the the speed of the encoder (hence their names) and the quality/bits.

Sorry, I guess I didn't read the post properly and ended up being dumb. I was thinking of presets encoder GUIs use for hardware compatibility, such as those used by MeGUI, not x264 presets.

24
Encoder GUIs / Re: MeGUI Colour Correction
« on: April 10, 2011, 06:18:16 AM »
Quote from: Mr VacBob on April 09, 2011, 06:42:16 PM
Color correction should be the responsibility of the decoder. Use the appropriate --colormatrix when encoding and that should be all - assuming you started with a YUV source. If you're resizing from SD (smpte240m) to HD (bt709) then it may be worth doing if you find your player ignores the colormatrix tag.

Thanks.
I just opened a DVD encode with MPC-HC and looked at the media info. Here's the relevant bits:

Color primaries                 : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics    : BT.709-5, BT.1361
Matrix coefficients             : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

It's not resized to HD, just an anamorphic SD encode. I haven't used --colormatrix when encoding, I've just converted using MeGUI with the colour conversion option disabled. Does the x264 encoder convert the colours when encoding? I'd have assumed it doesn't, hence MeGUI having an option to convert colours, although if it does then why would MeGUI have the colour correction option? I'm sure last time I compared an encode with the original DVD (using a PC) the colours looked the same (MeGUI's colour correction disabled).

Does any of the above tell you whether my DVD encodes should be playing back with the correct colours? I generally use a PC for playing encodes but occasionally I do use a standalone player. I'm still a little lost and trying to learn.

Thanks again.

25
Encoder GUIs / MeGUI Colour Correction
« on: April 09, 2011, 03:51:02 AM »
Is it necessary to use colour correction and if so under what circumstances?

A while ago I noticed when converting DVDs the colour correction option would alter the colours a little so I stopped using it. I think at the time I read it was due to a dgindex bug.

Since then I've never enabled the colour correction option, but now I'm wondering if I should. For instance when converting a DVD using x264 and then playing the encode on a BluRay player, will it display with slightly different colours if I encode the video with colour correction enabled than it would with colour correction disabled when encoding? Does colour correction need to be used when encoding a BluRay video?

Thanks.

26
Newbies / Re: Advantages of x264 presets
« on: April 09, 2011, 03:29:30 AM »
Quote from: MaxBlack on April 07, 2011, 04:50:32 AM
More specifically, it IS possible to make manual settings that result in garbage-out. Deviate from the standard settings (and presets) at your own stupidity er, I mean, risk!  ;)

Most of the presets are for hardware compatibility, allowing an encode to be played on a particular device. Changing encoder settings would possibly break that compatibility. They may also effect how efficiently the encoder can encode the video, but other settings such as file size and resolution etc can help you to produce garbage also. Which settings were you wanting to change?

27
Newbies / Re: Merged files are async :-(
« on: April 09, 2011, 03:19:12 AM »
Thanks for the additional info.

Maybe try Media Player Classic Home Cinema as an alternative to VLC. I prefer it to VLC. These days it'll play all the common file formats "out of the box"as VLC does, i.e. no need for additional system codecs.

Unlike VLC though, you can get it to use system codecs if you wish (VLC has an option to use system codecs but it also seems to happily ignore it's own setting). I also install ffdshow and the Haali media splitter (I use them for converting mainly). On the rare occasion I have problems with a file I disable the appropriate internal filters in MPC-HC and use ffdshow and Haali to do the work. If the problem persists then I assume there's likely to be something wrong with the file.

Without knowing exactly how it all works "under the hood" I'd assume your joined files have video and audio streams of slightly different lengths, so when you join them there will be slight gaps in one of the streams. The player should still play them in sync but it sounds like (for want of a better description) VLC is skipping over the gaps which puts the audio and video out of sync.

28
Newbies / Re: Merged files are async :-(
« on: April 06, 2011, 09:47:25 PM »
Quote from: anuswara on April 06, 2011, 04:09:28 PM
with the latest build 4.60 I get async (see above please).

but the same process with build 4.30 works fine, the 2 files I have appended, are now all in sync!!


That's interesting. Thanks for posting the info.
I was thinking the reason might be something to so with the video and audio streams being slightly different lengths and this was causing the audio to go out of sync, but I've never had problems with audio sync when joining MKV's before (even when I know the track lengths are slightly different).

I'm still using version 4.4.0 as I've been using PCs for long enough to hate upgrading software (I work on the "if it ain't broken, don't upgrade it" principle). I guess I'll be staying with version 4.4.0 for a while longer.

29
Newbies / Re: Merged files are async :-(
« on: April 05, 2011, 08:18:30 PM »
Your recording software doesn't have a pause button?

After you've converted the ts files to MKV, and before you append them, is the audio of each MKV still in sync?
I don't have an answer but I'm just wondering where the sync is actually lost.... when converting the individual ts files to MKV or when joining the MKVs. I'd suspect it's the former.

"Bunkus tell me: "use the sync option""

I don't know much about StaxRip but could he be referring to a StaxRip sync option?

I've joined quite a few MKV files where the audio and video tracks aren't exactly the same length (I know because when trying to convert the individual files to a single AVI, for example, I've lost audio sync) but when converting to individual MKV files first and then appending them to each other the audio sync hasn't been lost.

Without knowing why you're having the problem, maybe you'd be better off recording the whole program as a single file and then editing out the commercials and saving the edited version as a single file for converting?
http://www.videohelp.com/tools/tsMuxeR

Can you record the program as a program stream rather than as a transport stream? If so I think that would result in the program being recorded as ordinary mpeg files. That might give you more options for editing before converting using a program such as AVIdemux. Although thinking about it, I think AVIdemux can open ts files anyway.... http://fixounet.free.fr/avidemux/

30
Newbies / Re: Difference between one-pass and two-pass enconding?
« on: March 29, 2011, 07:31:06 PM »
Quote from: nm on March 29, 2011, 01:06:03 AM
Yet you kept wondering if the printed final ratefactor is that value.

Yes.

Quote from: nm on March 29, 2011, 01:06:03 AM
It works some things out to help second pass rate control, but it can't estimate the CRF that the second pass arrives at.

Yet from the post you linked to, Dark Shikari wrote:
"2-pass tries to approximate CRF by using the information from the first pass to decide on a constant quality factor."

Quote from: nm on March 29, 2011, 01:06:03 AM
Final bitrate distribution (and therefore quality) is approximately the same:

http://forum.doom9.org/showthread.php?p=1230509#post1230509

Which is why what you're saying still doesn't make sense to me.
The encoder can't estimate the CRF that the second pass will arrive at while at the same time it tries to approximate CRF by using the information from the first pass to decide on a constant quality factor. Final bitrate distribution (and therefore quality) is approximately the same for the two pass encode even though it happens without knowing what the quality will be as the encoder distributes those bits. I guess I don't understand how it works well enough yet....

Pages: [1] 2