The default -pix_fmt for dpx when provided with a yuv422p10le source
file appears to be rgb48be, which seems reasonable enough.
However upon inspection of the created dpx it appears to be only rgb24
which is not what I would have expected. Can anyone shed light on this?:-
ffmpeg -i
On 11/05/15 10:54, tim nicholson wrote:
The default -pix_fmt for dpx when provided with a yuv422p10le source
file appears to be rgb48be, which seems reasonable enough.
However upon inspection of the created dpx it appears to be only rgb24
which is not what I would have expected. Can anyone
On 11/05/15 12:32, Moritz Barsnick wrote:
On Mon, May 11, 2015 at 10:59:45 +0100, tim nicholson wrote:
identify -verbose dpx-HD-0001.dpx
Image: dpx-HD-0001.dpx
Format: DPX (SMPTE 268M-2003 (DPX 2.0))
Geometry: 1920x1080
Class: DirectClass
Type: true color
Depth: 8 bits-per-pixel
Once again, decided to give ffserver a try but, again it crashed:
kernel: [7169843.523862] ffserver[24324] general protection ip:7fa6247bf777
sp:7fffa7b4b5a0 error:0 in libc-2.13.so[7fa624746000+182000]
On Thu, May 7, 2015 at 10:08 PM, Reuben Martin reube...@gmail.com wrote:
On Saturday, May
On Mon, May 11, 2015 at 09:02:40 -0400, En Figureo Canal wrote:
Once again, decided to give ffserver a try but, again it crashed:
Didn't that belong into the ffserver crashes from time to time
thread?
kernel: [7169843.523862] ffserver[24324] general protection ip:7fa6247bf777
sp:7fffa7b4b5a0
On 11/05/15 12:59, tim nicholson wrote:
Thanks for the confirmation that it s not ffmpeg.
[..]
In fact it is related to:-
http://sourceforge.net/p/graphicsmagick/bugs/131/
and for some bizzare reason Ubuntu/Mint do not build it with 16 bit
support, my SuSE box is fine...
--
Tim.
Key
On Mon, May 11, 2015 at 14:50:10 +0100, tim nicholson wrote:
In fact it is related to:-
http://sourceforge.net/p/graphicsmagick/bugs/131/
Interesting, especially for an identify module, which should aim for
some sort of precision.
Let's just (help to) make sure ffprobe doesn't misdetect. :-)
running the same command here, I get an image that contains ~16 bits
worth of data and it looks 'correct' in Nuke. It also matches a PNG
made with ffmpeg
Kevin
On Mon, May 11, 2015 at 2:50 PM, tim nicholson
nichot20-at-yahoo@ffmpeg.org wrote:
On 11/05/15 12:59, tim nicholson wrote:
Thanks
From: kevwe...@hotmail.co.uk
To: ffmpeg-user@ffmpeg.org
Date: Sun, 10 May 2015 18:23:10 +
Subject: Re: [FFmpeg-user] HD SD Down-Convert Prores Color
To: ffmpeg-user@ffmpeg.org
From: ceho...@ag.or.at
Date: Sun, 10 May 2015 14:27:29 +
Subject: Re: [FFmpeg-user] HD SD Down-Convert
Could I just run my unaligned files through ffmpeg again with a set
keyframe interval and disabled scene cut detection?
Or do I need to scrap them and re-encode the source file and generate
new files that are properly aligned? We have thousands and am trying
to save time where possible.
On
Hello,
I have noticed that /libfdk_aac/ in VBR mode spits out CBR audio encodes,
ONLY, or at least is flagged as CBR in MediaInfo. While encoding there is a
warning as you can see in the log below.
C:\Users\ADMINISTRATOR\Videosffmpeg -i 1.mp4 -c:v copy -c:a libfdk_aac
-vbr 1 1_0.mp4
ffmpeg
We allow the viewers to select a low bandwidth or high bandwidth file
and stream just the selected file. I am trying to move us to one
player with that does adaptive bit rate switching. Of course I'd like
the videos to be playable in the older iOS, androids as well as
desktops with slow and fast
12 matches
Mail list logo
