AVS › AVS Forum › Display Devices › Display Calibration › AVS HD 709 - Blu-ray & MP4 Calibration
New Posts  All Forums:Forum Nav:

AVS HD 709 - Blu-ray & MP4 Calibration - Page 3

post #61 of 3625
12/5/07 at 8:52am
Quote:
Originally Posted by dr1394 View Post

The burst is 460 pixels wide. The sin() function returns a number from -1 to 1, so it needs to be converted to 16 to 235. 0x80 is the Cb or Cr chroma pixel (black and white pattern).

Ron

Thanks Ron. I figured out the scaling to 16-235 after I posted, but was still working on the other two. That clears things up.
Reply
Reply

AVS Top Picks

post #62 of 3625
12/6/07 at 7:10am
Will this work for a mac? When I click the exe it opens a binary file
Reply
Reply
post #63 of 3625
12/6/07 at 7:20am
Thread Starter 
I really don't know because my time using both Linux and Mac amounts to a total of a few hours each. The ISO was compressed by http://www.7-zip.org/download.html and it shows that there's a Mac OS X version. If nothing else I could upload a .7z compressed file instead of turning it into an exe.
Reply
Reply
post #64 of 3625
12/6/07 at 7:20am
Quote:
Originally Posted by evanhunter View Post

Will this work for a mac? When I click the exe it opens a binary file

We haven't tested it on a Mac, so to be honest I'm not sure. You will be able to burn the disc fine on a Mac, but the self-extracting archive may give you problems.

I'm not quite sure what you mean by opens a binary file. When you double click on the archive, it should prompt you for a location to decompress to, and then should decompress the contents to that location. The only file in the archive is an .iso image. You can burn that image with a number of different programs. I'm not sure if ImgBurn supports Mac (www.imgburn.com), but you can try it.

If you can give me a little more detail about exactly what is happening, then I can probably help. We definetely want Mac users to be able to burn the disk.
Reply
Reply
post #65 of 3625
12/6/07 at 12:04pm
When you double-click the icon, it launches a Windows program to decompress the file, so no, it will not work on a Mac.

What you want to do is run the .exe file on a PC, and then transfer the extracted .iso file to your Mac. You might try to get someone to host the .iso for you, but it's 2.3GB which is going to take a wee bit of time to download.
Reply
Reply
post #66 of 3625
12/6/07 at 12:14pm
Quote:
Originally Posted by JohnnyG View Post

When you double-click the icon, it launches a Windows program to decompress the file, so no, it will not work on a Mac.

What you want to do is run the .exe file on a PC, and then transfer the extracted .iso file to your Mac. You might try to get someone to host the .iso for you, but it's 2.3GB which is going to take a wee bit of time to download.

Johnny,
Do you have a Mac to test on? We can change the compression scheme or offer another download with a scheme that Mac can decompress, like plain .zip, but it will be a bit larger download.

Also, do Mac's have capability to burn ISO built in, or is there a freeware program you can use? I'd like to add that info to the first post if we could.
Reply
Reply
post #67 of 3625
12/6/07 at 1:43pm
I think you guys are fine with 7zip since the mac supports it, but releasing it exclusively as a windows executable is going to cause a problem for anyone not running a windows machine. Also, many people will not trust an .exe online in this day and age. I'd highly recommend just releasing the iso as a zip, a 7zip or the rar format since they are pretty common.
Reply
Reply
post #68 of 3625
12/6/07 at 1:44pm
Quote:
Originally Posted by hwjohn View Post

Also, do Mac's have capability to burn ISO built in, or is there a freeware program you can use? I'd like to add that info to the first post if we could.

macs can burn ISOs directly from the disk utility app.
Reply
Reply
post #69 of 3625
12/6/07 at 1:45pm
Thread Starter 
Looking at google it looks like there are mac programs to uncompress .7z, so I'll recompress the ISO and upload a second version tonight so that it's not so windows-specific.
Reply
Reply
post #70 of 3625
12/7/07 at 8:10am
Quote:
Originally Posted by hwjohn View Post

Johnny,
Do you have a Mac to test on? We can change the compression scheme or offer another download with a scheme that Mac can decompress, like plain .zip, but it will be a bit larger download.

Also, do Mac's have capability to burn ISO built in, or is there a freeware program you can use? I'd like to add that info to the first post if we could.

Yup, I've got both a Mac and PC on my desk here at work. As stated above, the Mac can burn (and even mount as a drive) an .iso image right out of the box. If I expand the .exe file on the PC and move it to the Mac, I then have no trouble with it.
Reply
Reply
post #71 of 3625
12/7/07 at 8:58am
There are a bunch of apps able to decompress .7z on the mac, I just used one called EZ 7z and burned the iso from disk utility, no problems.
Reply
Reply
post #72 of 3625
12/7/07 at 9:26am
I can just tried what zoyd posted. I downloaded EZ 7z from here and fed it the .exe file. Worked perfectly. Nice!
Reply
Reply
post #73 of 3625
12/9/07 at 12:00am
Great job.

I'm looking forward to the AVCHD version.
Reply
Reply
post #74 of 3625
12/9/07 at 5:29pm
Thread Starter 
AVCHD is basically what we are currently focused on. We need to be able to encode video with an AviSynth compatible H264 encoder and mux with audio like this http://www.filesend.net/download.php...8d4380ef5d4648.
Reply
Reply
post #75 of 3625
12/9/07 at 6:27pm
Quote:
Originally Posted by alluringreality View Post

AVCHD is basically what we are currently focused on. We need to be able to encode video with an AviSynth compatible H264 encoder and mux with audio like this http://www.filesend.net/download.php...8d4380ef5d4648.

Just to avoid the re-encode? Why bother?

BTW, the file format is AVCHD/HDMV (or .m2ts).

Ron
Reply
Reply
post #76 of 3625
12/9/07 at 6:46pm
Quote:
Originally Posted by dr1394 View Post

Just to avoid the re-encode? Why bother?

BTW, the file format is AVCHD/HDMV (or .m2ts).

Ron

We were originally concerned about Ulead doing the encoding because we noticed some weird artifacts on a test run we made. At some point I think we had issues with RGB levels as well, but we have done so much testing that I can't remember. alluringreality can probably fill you in some more as he has the Ulead software.

I had suggested we use x264 simply because we have a lot of control over it, where we pretty much have no control over the way the Ulead software encodes. I don't even think you can set the Profile and Level in the Ulead software, but again, alluringreality could comment more on that. The problem with x264 is that we can't get the Ulead software to accept any of the muxed encodes. It keeps giving an error about no video data present.

We can get .m2ts files muxed that will play fine on a PC, but Ulead won't accept them. It seems to be hit or miss. The last batch I encoded to try wouldn't even demux with xport. I'm trying to wade through the MPEG4 specs, but as you know, that isn't exactly a 30 minute read...

At this point we are exploring a couple of options. We think that some of the original artifacting could be corrected with some settings in the Ulead software, so we may let it transcode the MPEG2 files that we use for the HD DVD version. In fact, that would be the best option because we wouldn't have to keep separate files for each run. We could just encode to MPEG2 using HCenc for HD DVD, then let Ulead transcode those files to AVC for AVCHD.

Ron, do you have a reference MPEG4 decoder available so that we can check the Ulead output?
Reply
Reply
post #77 of 3625
12/9/07 at 6:49pm
Thread Starter 
Quote:
Originally Posted by dr1394 View Post

Just to avoid the re-encode? Why bother?

So, are you saying the transcode looks fine and to use that?

I just thought there might be some benefit of going straight from image to H264, instead of image to mpeg2 to H264.
Reply
Reply
post #78 of 3625
12/9/07 at 7:33pm
Thread Starter 
Quote:
Originally Posted by hwjohn View Post

we pretty much have no control over the way the Ulead software encodes.

The pictures show the transcoding options.





Basically you can choose lower or upper field first and 1080p on the first screen. The second allows for the quality slider, VBR or CBR, 2-pass encode for VBR, and bit rate selection from 2982-18000.


Quote:


We were originally concerned about Ulead doing the encoding because we noticed some weird artifacts on a test run we made.

I think that was a settings issue. The last run didn't show it on my player.


Quote:


At some point I think we had issues with RGB levels as well

That was with the .mov tests. Color 17 was clearly off on those tests. By eye color 17 seems to match the mpeg2 encoded disk.


Quote:


The problem with x264 is that we can't get the Ulead software to accept any of the muxed encodes. It keeps giving an error about no video data present.

The encode and/or muxing is the issue. MF6+ does seem to be good about accepting ac3 sound.


Quote:


we may let it transcode the MPEG2 files that we use for the HD DVD version. In fact, that would be the best option because we wouldn't have to keep separate files for each run. We could just encode to MPEG2 using HCenc for HD DVD, then let Ulead transcode those files to AVC for AVCHD.

Based on the PS3 test failure with the QuEnc files, if we do go with a transcode then we will have to use HCenc like mentioned. If it turns out that there are no issues with the transcoded files, and that's the way to go, then things should be set except for the HCenc redo and some muxing needed so the m2ts files can be reimported into MF6+ instead of needing the time to always transcode whenever the disk is built.
Reply
Reply
post #79 of 3625
12/9/07 at 7:49pm
If you compress the iso file with zip then everyone will be able to use it because every computer windows/unix/mac comes with unzip. Why force everyone to download yet another decompression program? I'd be surprised if a disk full of visual test patterns compressed much anyway. How big is the zip file versus the 7z file?
Reply
Reply
post #80 of 3625
12/9/07 at 8:06pm
Thread Starter 
On my computer the HD DVD zip from windows is 300MB and the 7-zip is around 20MB, so it's 15 times larger. If you know of a freeware compressor that can do what 7-zip can do fine, but at this time there is no plan to use that format. As it is now it takes me over half an hour to upload, so it's out of the question unless someone wants to do it on their own and host it. I'm not forcing anyone to do anything, just don't download it or use a windows computer so the exe works.
Reply
Reply
post #81 of 3625
12/9/07 at 8:08pm
Quote:
Originally Posted by hwjohn View Post

We were originally concerned about Ulead doing the encoding because we noticed some weird artifacts on a test run we made. At some point I think we had issues with RGB levels as well, but we have done so much testing that I can't remember. alluringreality can probably fill you in some more as he has the Ulead software.

I had suggested we use x264 simply because we have a lot of control over it, where we pretty much have no control over the way the Ulead software encodes. I don't even think you can set the Profile and Level in the Ulead software, but again, alluringreality could comment more on that. The problem with x264 is that we can't get the Ulead software to accept any of the muxed encodes. It keeps giving an error about no video data present.

We can get .m2ts files muxed that will play fine on a PC, but Ulead won't accept them. It seems to be hit or miss. The last batch I encoded to try wouldn't even demux with xport. I'm trying to wade through the MPEG4 specs, but as you know, that isn't exactly a 30 minute read...

At this point we are exploring a couple of options. We think that some of the original artifacting could be corrected with some settings in the Ulead software, so we may let it transcode the MPEG2 files that we use for the HD DVD version. In fact, that would be the best option because we wouldn't have to keep separate files for each run. We could just encode to MPEG2 using HCenc for HD DVD, then let Ulead transcode those files to AVC for AVCHD.

Ron, do you have a reference MPEG4 decoder available so that we can check the Ulead output?

The AVCHD format uses specific PID's. Here's the demux of the Ulead file.
Code:
C:\\xfer>xport -h Export20071209-006.mpg 1 1 1
xport Transport Stream Demuxer 1.00
program = 1, video channel = 1, audio channel = 1
Program Number = 0 (0x0000), Program Map PID = 31 (0x001f)
Program Number = 1 (0x0001), Program Map PID = 256 (0x0100)
program descriptor = 0x05, 0x04, 0x48, 0x44, 0x4d, 0x56
program descriptor = 0x88, 0x04, 0x0f, 0xff, 0xfc, 0xfc
Video PID = 4113 <0x1011>, type = 0x1b
ES descriptor for stream type 0x1b = 0x05, 0x08, 0x48, 0x44, 0x4d, 0x56, 0xff, 0x1b, 0x44, 0x3f
Audio PID = 4352 <0x1100>, type = 0x81
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x06, 0x04, 0x20, 0x05, 0x00, 0xff, 0x01
0 frames before first I-frame
High Profile
Level = 4.0
First Video PTS = 0x00004b03
Audio Bitrate = 128000, Audio Sampling Rate = 48000
Audio Mode = 2/0, bsid = 4, bsmod = 0
First Audio PTS = 0x00004b03, 0
ts rate = unspecified
packets for pid    0 <0x0000> = 1366, first = 1, last = 36840
packets for pid   31 <0x001f> = 1366, first = 4, last = 36843
packets for pid  256 <0x0100> = 1366, first = 2, last = 36841
packets for pid 4097 <0x1001> = 1366, first = 3, last = 36842
packets for pid 4113 <0x1011> = 19868, first = 5, last = 36735
packets for pid 4352 <0x1100> = 11517, first = 131, last = 36849
packets for pid 8191 <0x1fff> = 15, first = 36850, last = 36864
coded pictures = 7364, video fields = 0

C:\\xfer>
The PMT is on PID 256, the PCR is on PID 4097, the video is on PID 4113 and the audio is on PID 4352. There's also a NIT on PID 31. If you look at a demux of a Blu-ray file, it's the same (except there are more audio PID's, sub-title PID's and the DTCP descriptor indicates copy never).
Code:
C:\\xfer>xport -h 00009.m2ts 1 1 1
xport Transport Stream Demuxer 1.00
program = 1, video channel = 1, audio channel = 1
Program Number = 0 (0x0000), Program Map PID = 31 (0x001f)
Program Number = 1 (0x0001), Program Map PID = 256 (0x0100)
program descriptor = 0x05, 0x04, 0x48, 0x44, 0x4d, 0x56
program descriptor = 0x88, 0x04, 0x0f, 0xff, 0xff, 0xfc
Video PID = 4113 <0x1011>, type = 0x1b
ES descriptor for stream type 0x1b = 0x05, 0x08, 0x48, 0x44, 0x4d, 0x56, 0xff, 0x1b, 0x61, 0x3f
Audio PID = 4352 <0x1100>, type = 0x80
ES descriptor for stream type 0x80 = 0x05, 0x08, 0x48, 0x44, 0x4d, 0x56, 0xff, 0x80, 0x61, 0xff
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x29, 0x04, 0x00
0 frames before first I-frame
High Profile
Level = 4.1
LPCM Audio Mode = 3/2+lfe
LPCM Audio Bits/sample = 24
LPCM Audio Sample Rate = 48000
First Video PTS = 0x000ffff0
ts rate = unspecified
packets for pid    0 <0x0000> = 21, first = 1, last = 50437
packets for pid   31 <0x001f> = 3, first = 3, last = 48197
packets for pid  256 <0x0100> = 21, first = 2, last = 50438
packets for pid 4097 <0x1001> = 22, first = 4, last = 50757
packets for pid 4113 <0x1011> = 36755, first = 5, last = 52083
packets for pid 4352 <0x1100> = 11720, first = 1542, last = 52084
packets for pid 4353 <0x1101> = 963, first = 1704, last = 51719
packets for pid 4354 <0x1102> = 963, first = 1724, last = 51721
packets for pid 4355 <0x1103> = 963, first = 1751, last = 51723
packets for pid 4356 <0x1104> = 403, first = 1825, last = 51649
packets for pid 4608 <0x1200> = 243, first = 6, last = 36726
packets for pid 4611 <0x1203> = 7, first = 80, last = 3124
coded pictures = 67, video fields = 0

C:\\xfer>
So it's very likely that Ulead is looking for this structure. It may also be looking for the descriptors (the string 0x48, 0x44, 0x4d, 0x56 is "HDMV" in ascii).

However, the re-encode looks okay to me. You can decide for yourself with the JM reference decoder. It's located at http://iphome.hhi.de/suehring/tml/ and I have a compiled version of 13.0 here:

http://www.w6rz.net/ldecod_patch.zip

Since ldecod outputs to a single 4:2:0 file, I have a couple of tools to make things easier to work with.

http://www.w6rz.net/clipyuvhd.zip

http://www.w6rz.net/yuvtorgb.zip

clipyuvhd converts the single 4:2:0 file to a series of 4:2:2 files in UYVY format. yuvtorgb then converts those UYVY files to .tga format. The command lines are:

ldecod -i bits0001.mpv

clipyuvhd 1920 1080 test_dec.yuv

yuvtorgb 1920 1080 test0000.yuv test.tga

For video RGB levels:

yuvtorgb -v 1920 1080 test0000.yuv test.tga

Ron

EDIT: Use yuvtorgb utility instead of yuvtobmp.
Reply
Reply
post #82 of 3625
12/9/07 at 8:15pm
Quote:
Originally Posted by alluringreality View Post

Basically you can choose lower or upper field first.....

You should use upper (top) field first. All HD is top field first. In fact, everything is top field first except analog NTSC and DV.

ldecod will also be happier with top field first.

Ron
Reply
Reply
post #83 of 3625
12/9/07 at 8:33pm
Quote:
Originally Posted by hatchback View Post

If you compress the iso file with zip then everyone will be able to use it because every computer windows/unix/mac comes with unzip. Why force everyone to download yet another decompression program? I'd be surprised if a disk full of visual test patterns compressed much anyway. How big is the zip file versus the 7z file?

Test patterns compress extremely well because they are static images repeated over and over. The .iso is 3.2 GB and the 7z compressed file is 20 Mb....
Reply
Reply
post #84 of 3625
12/9/07 at 9:52pm
Quote:
Originally Posted by dr1394 View Post

The AVCHD format uses specific PID's. Here's the demux of the Ulead file.
Code:
C:\\xfer>xport -h Export20071209-006.mpg 1 1 1
xport Transport Stream Demuxer 1.00
program = 1, video channel = 1, audio channel = 1
Program Number = 0 (0x0000), Program Map PID = 31 (0x001f)
Program Number = 1 (0x0001), Program Map PID = 256 (0x0100)
program descriptor = 0x05, 0x04, 0x48, 0x44, 0x4d, 0x56
program descriptor = 0x88, 0x04, 0x0f, 0xff, 0xfc, 0xfc
Video PID = 4113 <0x1011>, type = 0x1b
ES descriptor for stream type 0x1b = 0x05, 0x08, 0x48, 0x44, 0x4d, 0x56, 0xff, 0x1b, 0x44, 0x3f
Audio PID = 4352 <0x1100>, type = 0x81
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x06, 0x04, 0x20, 0x05, 0x00, 0xff, 0x01
0 frames before first I-frame
High Profile
Level = 4.0
First Video PTS = 0x00004b03
Audio Bitrate = 128000, Audio Sampling Rate = 48000
Audio Mode = 2/0, bsid = 4, bsmod = 0
First Audio PTS = 0x00004b03, 0
ts rate = unspecified
packets for pid    0 <0x0000> = 1366, first = 1, last = 36840
packets for pid   31 <0x001f> = 1366, first = 4, last = 36843
packets for pid  256 <0x0100> = 1366, first = 2, last = 36841
packets for pid 4097 <0x1001> = 1366, first = 3, last = 36842
packets for pid 4113 <0x1011> = 19868, first = 5, last = 36735
packets for pid 4352 <0x1100> = 11517, first = 131, last = 36849
packets for pid 8191 <0x1fff> = 15, first = 36850, last = 36864
coded pictures = 7364, video fields = 0

C:\\xfer>
The PMT is on PID 256, the PCR is on PID 4097, the video is on PID 4113 and the audio is on PID 4352. There's also a NIT on PID 31. If you look at a demux of a Blu-ray file, it's the same (except there are more audio PID's, sub-title PID's and the DTCP descriptor indicates copy never).
Code:
C:\\xfer>xport -h 00009.m2ts 1 1 1
xport Transport Stream Demuxer 1.00
program = 1, video channel = 1, audio channel = 1
Program Number = 0 (0x0000), Program Map PID = 31 (0x001f)
Program Number = 1 (0x0001), Program Map PID = 256 (0x0100)
program descriptor = 0x05, 0x04, 0x48, 0x44, 0x4d, 0x56
program descriptor = 0x88, 0x04, 0x0f, 0xff, 0xff, 0xfc
Video PID = 4113 <0x1011>, type = 0x1b
ES descriptor for stream type 0x1b = 0x05, 0x08, 0x48, 0x44, 0x4d, 0x56, 0xff, 0x1b, 0x61, 0x3f
Audio PID = 4352 <0x1100>, type = 0x80
ES descriptor for stream type 0x80 = 0x05, 0x08, 0x48, 0x44, 0x4d, 0x56, 0xff, 0x80, 0x61, 0xff
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x48, 0x0e, 0x00
ES descriptor for stream type 0x81 = 0x05, 0x04, 0x41, 0x43, 0x2d, 0x33
ES descriptor for stream type 0x81 = 0x81, 0x04, 0x06, 0x29, 0x04, 0x00
0 frames before first I-frame
High Profile
Level = 4.1
LPCM Audio Mode = 3/2+lfe
LPCM Audio Bits/sample = 24
LPCM Audio Sample Rate = 48000
First Video PTS = 0x000ffff0
ts rate = unspecified
packets for pid    0 <0x0000> = 21, first = 1, last = 50437
packets for pid   31 <0x001f> = 3, first = 3, last = 48197
packets for pid  256 <0x0100> = 21, first = 2, last = 50438
packets for pid 4097 <0x1001> = 22, first = 4, last = 50757
packets for pid 4113 <0x1011> = 36755, first = 5, last = 52083
packets for pid 4352 <0x1100> = 11720, first = 1542, last = 52084
packets for pid 4353 <0x1101> = 963, first = 1704, last = 51719
packets for pid 4354 <0x1102> = 963, first = 1724, last = 51721
packets for pid 4355 <0x1103> = 963, first = 1751, last = 51723
packets for pid 4356 <0x1104> = 403, first = 1825, last = 51649
packets for pid 4608 <0x1200> = 243, first = 6, last = 36726
packets for pid 4611 <0x1203> = 7, first = 80, last = 3124
coded pictures = 67, video fields = 0

C:\\xfer>
So it's very likely that Ulead is looking for this structure. It may also be looking for the descriptors (the string 0x48, 0x44, 0x4d, 0x56 is "HDMV" in ascii).

However, the re-encode looks okay to me. You can decide for yourself with the JM reference decoder. It's located at http://iphome.hhi.de/suehring/tml/ and I have a compiled version of 13.0 here:

http://www.w6rz.net/ldecod_patch.zip

Since ldecod outputs to a single 4:2:0 file, I have a couple of tools to make things easier to work with.

http://www.w6rz.net/clipyuvhd.zip

http://www.w6rz.net/yuvtobmp.zip

clipyuvhd converts the single 4:2:0 file to a series of 4:2:2 files in UYVY format. yuvtobmp then converts those UYVY files to .tga format (with PC levels). The command lines are:

ldecod -i bits0001.mpv

clipyuvhd 1920 1080 test_dec.yuv

yuvtobmp 1920 1080 test0000.yuv test.tga

Ron

EDIT: The yuvtobmp program is really using .tga format.

Thanks Ron, that should be extremely helpful. I'm pretty sure you officially hold the world record for number of obscure video processing programs

I'll double check a couple of the Ulead transcoded clips and hopefully they are correct and we can get an AVCHD version out.

One more question for you... as you see from the screenshots that alluringreality posted, the Ulead software expects a certain minimum bitrate around 2900 kbps. I was having trouble getting x264/MeGUI to produce a bitrate over 1000 kbps, even when I used Constant Quantizer as the encoding method and used the lowest possible quantizer. I finally got up to 3300 kbps by forcing it to use an I-Frame for every frame and making the GOP = 5. How can the Ulead software achieve the minimum bitrate it has specified when it transcodes when x264 has such issues even getting to 1000kbps with these simple patterns?
Reply
Reply
post #85 of 3625
12/9/07 at 10:02pm
Thread Starter 
I ran the Black Clipping .m2ts through "ffmpeg -i *.m2ts -vcodec copy *.h264" to get an .h264 file and followed the procedure given. Starting at color 16 and going up the numbers read: 0, 1, 2, 3, 5, 6, 7. I'm guessing the jump from 3 to 5 is due to PC levels.

I think for future tests I'll chop down the original mpeg2 in VideoReDo first. Those first two programs created almost 25 GB.
Reply
Reply
post #86 of 3625
12/9/07 at 10:36pm
Quote:
Originally Posted by hwjohn View Post

How can the Ulead software achieve the minimum bitrate it has specified when it transcodes when x264 has such issues even getting to 1000kbps with these simple patterns?

It's not. The average bitrate of the posted clip is 174.35 kbps.

The clip contains 7364 fields, which is 122.856 seconds. The demuxed H.264 stream is 2,677,500 bytes.

2,677,500 * 8 / 122.856 = 174350

Ron
Reply
Reply
post #87 of 3625
12/10/07 at 1:01am
Quote:
Originally Posted by alluringreality View Post

I ran the Black Clipping .m2ts through "ffmpeg -i *.m2ts -vcodec copy *.h264" to get an .h264 file and followed the procedure given. Starting at color 16 and going up the numbers read: 0, 1, 2, 3, 5, 6, 7. I'm guessing the jump from 3 to 5 is due to PC levels.

I think for future tests I'll chop down the original mpeg2 in VideoReDo first. Those first two programs created almost 25 GB.

I've updated the YUV to RGB converter to optionally do video levels.

http://www.w6rz.net/yuvtorgb.zip

usage: yuvtorgb <-bv6>

-b for .bmp output (.tga default)
-v for video RGB levels (PC RGB levels default)
-6 for 601 matrix (709 matrix default)

yuvtorgb -v 1920 1080 test0000.yuv test.tga

Ron
Reply
Reply
post #88 of 3625
12/10/07 at 6:57am
Thread Starter 
Thanks again Ron. The black clipping pattern checks out by the procedure given.
Reply
Reply
post #89 of 3625
12/10/07 at 7:07am
Quote:
Originally Posted by dr1394 View Post

It's not. The average bitrate of the posted clip is 174.35 kbps.

The clip contains 7364 fields, which is 122.856 seconds. The demuxed H.264 stream is 2,677,500 bytes.

2,677,500 * 8 / 122.856 = 174350

Ron

Well, that explains it. I should have thought to calculate it myself.

I think I'm going to change the framerate for the second beta of the HD DVD and the first release of the AVCHD from 29.97 fps to 30 fps, just for simplicity in timing. There is no advantage to using either one is there?

Also, HD DVD and AVCHD is a world wide standard, correct? Would we need to change anything to allow playback in PAL countries?
Reply
Reply
post #90 of 3625
12/10/07 at 9:02am
Quote:
Originally Posted by hwjohn View Post

I think I'm going to change the framerate for the second beta of the HD DVD and the first release of the AVCHD from 29.97 fps to 30 fps, just for simplicity in timing. There is no advantage to using either one is there?

If you ever add deinterlacing or audio/video sync patterns then keeping it at 29.97 would be better. If it's easy to change, changing it to 23.976 might be even better.
Reply
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Display Calibration

AVS Top Picks

AVS › AVS Forum › Display Devices › Display Calibration › AVS HD 709 - Blu-ray & MP4 Calibration