Thanks for all the tips! I'll try to report back, especially if I can achieve the exact color match for a Photo-JPEG. Fwiw, rendering QuickTimes with Shake does have the brightness/gamma shift, but it also/fortunately has the gama atom, which can be stripped with a command-line tool (there are some old ones out there from Frantic and Fuel). For some reason an ffmpeg generated Photo-JPEG QuickTime does not have the gama atom. And I'm not sure that's the exact shift we're seeing. Maybe it's related to the pix_fmt flag?
On Wednesday, May 1, 2013, Nathan Rusch wrote: > Hmm, so after trawling the full 'ffmpeg -help' output, I found that > switching to using the -framerate flag for the image2 demuxer seems to > properly set the input framerate, and the output framerate to match. I > still can't do rate conversions using the -r flag (i.e. I can't set the > output frame rate independent of that of the input), but at least I can > control the results now. > > May be handy to someone who encounters this issue in the future: > > ffmpeg -y -framerate 24 -i /path/to/input_sequence.%04d.**jpg -vcodec > copy /path/to/output/file.mov > > > -Nathan > > > -----Original Message----- From: Holger Hummel|Celluloid VFX > Sent: Wednesday, May 01, 2013 3:06 PM > To: Nuke user discussion > Subject: Re: [Nuke-users] ffmpeg Photo-JPEG QuickTimes > > in this case i was using the legacy/old quicktime player 7.6.6 (1709) / > quicktime version 7.7.1 (2315). > i don't like that new qt x player. but i just checked with that one, > too. same shift. > > i used ffmpeg build N-38292-ga4c22e3. so this is for sure not the newest > build. and yes, that's one of the > annoying things with ffmpeg, that it's basically developed so 'actively' > that there's a fairly high chance that things > break from one build to the next. > > Holger > > Nathan Rusch wrote: > > Are you using whatever the default Quicktime viewer is on OSX these days, > or are you explicitly using Quicktime 7? The two tend to interpret files > differently (which I'm sure some engineer somewhere has an explanation > for), but that might explain why you are seeing a difference. What version > of ffmpeg are you using? > > And yeah, the frame rate thing is very strange. Even running the exact > same command as you, I haven't been able to set the frame rate when using > '-vcodec copy' on a .jpg sequence. Perhaps the behavior I'm seeing is a > regressive bug introduced in one of the newer versions... > > -Nathan > > > -----Original Message----- From: Holger Hummel|Celluloid VFX > Sent: Wednesday, May 01, 2013 2:35 PM > To: Nuke user discussion > Subject: Re: [Nuke-users] ffmpeg Photo-JPEG QuickTimes > > hey Nathan, > > i'm sorry, but i don't understand why that doesn't work for you... > with the command i wrote in my last mail i'm able to generate quicktimes > of all sorts of frame rates - even when using '-vcodec copy'. > i just tested it again before sending the mail. > > i was just able to compare the jpg files and the QT on OS X. the gamma > shift is also visible there. but what's also interesting > is that there's much more banding visible in the QT compared to viewing > the jpg. guess i should try an encode process on linux to > see if that works properly.... > oh well, this endless pain called QT.... > > Holger > > > Nathan Rusch wrote: > > Yeah, I normally use the -r flag to set the source and destination frame > rate, but what I'm saying is that when '-vcodec copy' is passed, the rates > are all ignored, and ffmpeg assumes 25 fps for both the source and > destination. This is with ffmpeg 1.2. > > As for the lack of gamma shifting, these are being encoded on Linux and > viewed on OSX. In Quicktime 7, there is no difference between the raw JPEG > sequence and the resulting .mov. This matches the behavior of files > exported from Quicktime 7 itself, but files encoded with Shake on OSX *do* > show a gamma shift when viewed in Quicktime 7. > > -Nathan > > -----Original Message----- From: Holger Hummel|Celluloid VFX > Sent: Wednesday, May 01, 2013 1:37 PM > To: Nuke user discussion > Subject: Re: [Nuke-users] ffmpeg Photo-JPEG QuickTimes > > hey Nathan, > > regarding the frame rate: > you need to specifiy the '-r 24' parameter before the input file '-i > inputfile.%04d.jpg' then it does set the frame rate > correctly: > > ffmpeg -r 24 -i inputfiles.%04d.jpg -vcodec copy output.mov > > what OS do you see that same gamma/brightness of the jpg files as well > as the resulting QT? > i'm on windows here so that might be once more the reason for the > problem i'm having... > > cheers, > Holger > > > Nathan Rusch wrote: > > The '-vcodec copy' option is nice, but I've had issues using it in > conjunction with trying to set the frame rate for the output media; any > combination of flags attempting to set either the source or destination > frame rates seem to be ignored, and you always end up with a 25 fps output > file. > > Also, for what it's worth, using ffmpeg to re-encode a JPEG sequence > doesn't introduce a gamma shift in any scenario I've encountered. > > -Nathan > > > -----Original Message----- From: Holger Hummel|Celluloid VFX > Sent: Wednesday, May 01, 2013 7:50 AM > To: Nuke user discussion > Subject: Re: [Nuke-users] ffmpeg Photo-JPEG QuickTimes > > unfortunately, i don't know how to get around that nasty > gamma/brightness shift either. i'd be more than happy to find the > solution for this. > but there's another option that you can also use to get a Photo-JPEG > Quicktme with the exact jpg quality you want. > you just render out a jpg sequence with the esact setting as you want > from within Nuke and then use ffmpeg's '-vcodec copy' option. > this will just copy/wrap the jpg files into a Quickt > >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
