I'm still experimenting with moving some of my media to mp4/h.264. The quality/filesize is quite acceptable, and I'm even messing about with chapter marks and such.
However, I consistently get colour changes when re-encoding. The quality of the image itself is fine, but it's either too dark/too bright (sometimes at the same time, ie very large brightness range) or the colours are otherwise changed (ie the video goes all 'orangey'). I'm using both Nero Recode2 and SUPER, and I can't find any options regarding colour settings. Does anyone know anything that can help me with this?
xvid -> h.264 question
Moderator: Thanas
xvid -> h.264 question
I tend to prefer mp4 over h.264; I'm not sure why, but the iPod can take a higher bitrate mp4 file (2500) than h.264 (1500), maybe h.264 requires more processing power. And mp4 seems to have more support.
Unfortunately, having no familiarity with that software, I can't help much
I use iSquint and the rare times I have color problems it's usually only slightly brighter and I don't bother to fix it.
Unfortunately, having no familiarity with that software, I can't help much
I use iSquint and the rare times I have color problems it's usually only slightly brighter and I don't bother to fix it.Yeah, h.264 needs a fair bit of grunt - not a problem in my environment, where it's only going to be used on computers, my 360, and various DV players.
My concern is simply that unlike converting for portable use, I won't keep the originals. Thus I'd like as close a conversion as possible... but I'm not sure what I'm doing wrong.
My concern is simply that unlike converting for portable use, I won't keep the originals. Thus I'd like as close a conversion as possible... but I'm not sure what I'm doing wrong.
Note for the clueless: H.264 is MP4. It's one of the codecs supported in the MPEG-4 standard. The two video codecs supported are MPEG-4 part 2, and MPEG-4 part 10. H.264 is MPEG-4 part 10.
"preemptive killing of cops might not be such a bad idea from a personal saftey[sic] standpoint..." --Keevan Colton
"There's a word for bias you can't see: Yours." -- William Saletan
"There's a word for bias you can't see: Yours." -- William Saletan
Thanks for that. 
Are the h.264 levels just standards? Ie, is there any point choosing 'level2.2' or whatever and then encoding at very low bitrates? They seem to just be bitrate/feature standards.
I've still got no luck with colour settings. It's kinda frustrating to get decent quality reencoding but have the colours messed up, particularly since none of the software I use seem to have any colour settings or options at all.
Are the h.264 levels just standards? Ie, is there any point choosing 'level2.2' or whatever and then encoding at very low bitrates? They seem to just be bitrate/feature standards.
I've still got no luck with colour settings. It's kinda frustrating to get decent quality reencoding but have the colours messed up, particularly since none of the software I use seem to have any colour settings or options at all.
Wikipedia's H.264 article has a good about of information on the various levels.
Some poking has lead me to examples on Macs where inappropriate colour profiles can lead to this kind of brightness issue. How would you change those sort of settings in a Windows environment? Can I just change the attributes of the file to lower brightness?
My experimentation suggests it's entirely a brightness issue: orange-heavy scenes go 'orangey', bright lights wash out whole scenes, etc.
My experimentation suggests it's entirely a brightness issue: orange-heavy scenes go 'orangey', bright lights wash out whole scenes, etc.
I have found some more out about this issue. I found suggestions that under Windows the problem may be hardware/driver related. I also read that under VLC, the first instance will have the colour problem, and that any further instances of VLC will display properly.
I was able to test this extensively - indeed, it explained some anomalous experimentation results of my own - and it seems that the issue is at the player or driver level. The files themselves seem to be encoded properly, and no data is being lost. There are no updated drivers for my card (it's an 6600 Nvidia).
Ironically, some of the things I found on this issue go back to 2005 - apparently QT initally had a similar issue.
I was able to test this extensively - indeed, it explained some anomalous experimentation results of my own - and it seems that the issue is at the player or driver level. The files themselves seem to be encoded properly, and no data is being lost. There are no updated drivers for my card (it's an 6600 Nvidia).
Ironically, some of the things I found on this issue go back to 2005 - apparently QT initally had a similar issue.
Though it may decrease performance, you could try the latest 100.xx drives instead of the most current 6600 ones (90.xx?). Just a quick question, are you using a FFDshow codec to encode or a video for windows codec?
“Most people are other people. Their thoughts are someone else's opinions, their lives a mimicry, their passions a quotation.” - Oscar Wilde.
Yeah, the latest 6600 drivers are 93.74 (or something). I'm not sure how old that is... 
I'm using Nero Recode 2.5 atm. SUPER was introducing some interesting horizontal banding, but Recode is fine (it also allows me to mess with chapters etc).
So long as I keep an 'empty' VLC instance open, everything displays fine - apparently the first VLC instance uses the hardware settings/acceleration, while further instances don't. Thus, depending on the order I was opening the files I'd been experimenting with, my results could suddenly be reversed.
I'm using Nero Recode 2.5 atm. SUPER was introducing some interesting horizontal banding, but Recode is fine (it also allows me to mess with chapters etc).
So long as I keep an 'empty' VLC instance open, everything displays fine - apparently the first VLC instance uses the hardware settings/acceleration, while further instances don't. Thus, depending on the order I was opening the files I'd been experimenting with, my results could suddenly be reversed.
