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.

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.

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.

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.

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.

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.

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?

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.

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?

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.

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.

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).

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....

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).

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?

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 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.

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?

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.