Re: [FFmpeg-user] ffmpeg makes some sources darker

> On 2016 Jan 4, at 5:11 PM, Carl Eugen Hoyos wrote: > > You could test to set them with the following: > -color_primaries bt709 -color_trc bt709 -colorspace bt709 > (with a faster preset), it shouldn't make a > difference but who knows... > > And please also test with -vcodec x264, Carl Eugen

Re: [FFmpeg-user] ffmpeg makes some sources darker

Andy Furniss wrote: Andy Furniss wrote: Strange, unless there is something in the pngs that causes a different viewer to produce different output. I looked again (display from ancient imagemagic) and can't see any difference - psnr/ssim agree. The pngs are not the same md5sum wise md5sum fra

Re: [FFmpeg-user] ffmpeg makes some sources darker

Andy Furniss gmail.com> writes: > I think it's because the master is flagged as rec709 > but the yuv and I guess hevc aren't. While this is at least likely (sorry for my original comment, I don't know what I looked at), the source code seems to disagree: colour_primaries etc. are read from b

Re: [FFmpeg-user] ffmpeg makes some sources darker

> > Strange, unless there is something in the pngs that causes a different viewer > to produce different output. > > I looked again (display from ancient imagemagic) and can't see any difference > - psnr/ssim agree. > > The pngs are not the same md5sum wise OK - you’re definitely getting way

Re: [FFmpeg-user] ffmpeg makes some sources darker

Andy Furniss wrote: Strange, unless there is something in the pngs that causes a different viewer to produce different output. I looked again (display from ancient imagemagic) and can't see any difference - psnr/ssim agree. The pngs are not the same md5sum wise md5sum frame1-yuv-709.png frame

Re: [FFmpeg-user] ffmpeg makes some sources darker

Jim Worrall wrote: It seems ffmpeg swscale/png honors the 709 for the master. testing - ffmpeg -i in.mkv -vframes 1 frame1-master.png ffmpeg -i in.mkv -vframes 1 -vcodec rawvideo -f rawvideo frame1-master.yuv ffmpeg -f rawvideo -pix_fmt yuv420p -s 1920x1080 -i frame1-master.yuv frame1-yuv

Re: [FFmpeg-user] ffmpeg makes some sources darker

> On 2016 Jan 4, at 3:29 PM, Andy Furniss wrote: > I think it's because the master is flagged as rec709 but the yuv and I > guess hevc aren’t. Although my opinion is not worth much, I suspect you are onto it here. > > Some players (not mplayer) would assume 709 for >= 720p so you wouldn't > not

Re: [FFmpeg-user] ffmpeg makes some sources darker

Jim Worrall wrote: On 2016 Jan 4, at 1:33 PM, Carl Eugen Hoyos wrote: How did you produce the screenshots? ffmpeg -i in.mkv -vf fps=1/6 %03din.png I do see that one of the png files you uploaded is lighter but when I look at the 91st frame of the file you uploaded, it is darker here with M

Re: [FFmpeg-user] ffmpeg makes some sources darker

> On 2016 Jan 4, at 1:33 PM, Carl Eugen Hoyos wrote: > > How did you produce the screenshots? ffmpeg -i in.mkv -vf fps=1/6 %03din.png > > I do see that one of the png files you uploaded > is lighter but when I look at the 91st frame of > the file you uploaded, it is darker here with > MPlaye

Re: [FFmpeg-user] some containers require "monotonically increasing" RAM expected or leak (mp4, nut)?

Roger Pack gmail.com> writes: > I noticed when doing some test to isolate memory leaks > that the following commands "grow monotonically" (RAM > size required) Yes, indexes do not come for free. mpeg streams have no index, nut seems to allow to disable it. I don't know if an isom file without

Re: [FFmpeg-user] ffmpeg makes some sources darker

Jim Worrall gmail.com> writes: > Unfortunately I can’t attach the screenshots here, > but here are links to them: How did you produce the screenshots? I do see that one of the png files you uploaded is lighter but when I look at the 91st frame of the file you uploaded, it is darker here with

[FFmpeg-user] ffmpeg makes some sources darker

I’ve been using ffmpeg with libx265 to transcode Star Wars blurays to smaller files. Episodes 1 and 2 went perfectly. I made screenshots from identical points and they were virtually indistinguishable. When I did Episode 3, I noticed that the screenshots from the transcode were darker than th

[FFmpeg-user] some containers require "monotonically increasing" RAM expected or leak (mp4, nut)?

Hello all. I noticed when doing some test to isolate memory leaks that the following commands "grow monotonically" (RAM size required) however valgrind doesn't report any leaks. I presume this is expected? ** nut container size grows over time: ./ffmpeg -f lavfi -i color=c=red:size=40x40 -vcod

Re: [FFmpeg-user] null video sink

Le quintidi 15 nivôse, an CCXXIV, Roger Pack a écrit : > Anyway the closest I've found is the "null" container + rawvideo The null muxer uses a wrapped frame (and until recently, a raw picture), there is no muxing overhead. Regards, -- Nicolas George signature.asc Description: Digital signa

Re: [FFmpeg-user] null video sink

On 12/29/15, Nicolas George wrote: > Le nonidi 9 nivôse, an CCXXIV, Roger Pack a écrit : >> Could anyone be kind enough to show me how to use this in a filtergraph? >> When I try to, it seems to still output and encode: > >> Stream mapping: >> Stream #0:0 (h264) -> scale (graph 0) >> Stream #0

Re: [FFmpeg-user] Real-time HAP encoded streaming

Kenneth Fields gmail.com> writes: > A normal, H.264 codec is unusable for p2p > conferencing/performing as it takes seconds to > encode. (Depending on the definition of "normal":) This is definitely wrong, at least x264 has options for encoding with a deadline and is used for conferencing (b

Re: [FFmpeg-user] Real-time HAP encoded streaming

On 1/4/16, Kenneth Fields wrote: > Hi, > in general documentation, > Supported External Libraries, Formats, Codecs or Features > = > I see Vidvox HAP under 2.1 file formats and not under video codecs. > Can real-time HAP encoded network streaming be done? Anyone st