On 11/7/2017 11:03 AM, Constantine wrote:
Stream #0:0: Video: vp8 (VP80 / 0x30385056), yuv420p(progressive),
480x640, 527 kb/s, SAR 1:1 DAR 3:4, 60 fps, 60 tbr, 60 tbn, 60 tbc
[vp8 @ 0x55c1ee9e05e0] Discarding interframe without a prior keyframe!
VP8, like most delivery codec
I have a completely broken AVI file that I'd like to restore. It is so bad
that apps like DivFix++ don't recognize it. Reading AVI specs gave me a hint
that with little heuristics I could extract a frame (FTR: they're stored in
chunks starting with FourCC, then size of the chunk, then the data).
On Sun, Nov 5, 2017 at 6:16 PM, Baek Seung Hoon
wrote:
> (Its mail continuous previous my one.. sorry)
>
> I wonder know what is different ffmpeg internal sequence following 2
> commands..
>
> 1.
> > ffmpeg -y -i ./input.mp4 -filter_complex
> "[0:v]hwupload_cuda=device=0,scale_npp=w=960:h=540[
2017-11-06 14:25 GMT+01:00 Moritz Barsnick :
> On Mon, Nov 06, 2017 at 13:46:29 +0100, Carl Eugen Hoyos wrote:
>> > It seems the image2 muxer uses the framerate reported by the
>> > demuxer (but as cfr).
>>
>> This is wrong, the image2 muxer does not know anything about
>> the input frame rate.
>
>
2017-11-06 15:11 GMT+01:00 Jakob Schneider :
>
>>> Ah no, sorry, the problem is, that I have non-image data (vectors
>>> coordinates)
>>> that I want to press into an image with the yuv420p pixel format
>
>>That is a bad idea given that (for your scenario) hevc is a lossy codec.
>
> even if I use
2017-11-05 22:08 GMT+01:00 Michael Koch :
>>> ffmpeg -framerate 0.5 -i IMG_%3d.jpg -r 2 -codec:v mpeg4 temp.mp4
>>> ffmpeg -i temp.mp4 -vf "framerate=fps=25" -codec:v mpeg4 out.mp4 /
>>
>> You should be able to combine the command lines using the fps filter.
>
> I did already try that, but unfortun
Does anybody know of a way to incorporate the service_name metadata
from a live incoming mpegts stream into the output file name/path? Is
there any means by which to make that metadata value available as a
variable?
-Reuben
___
ffmpeg-user mailing list
f
/ffmpeg -framerate 0.5 -i IMG_%3d.jpg -r 2 -codec:v mpeg4 temp.mp4 />>/ffmpeg -i temp.mp4
-vf "framerate=fps=25" -codec:v mpeg4 out.mp4 /
You should be able to combine the command lines using the fps filter.
I did already try that, but unfortunately it doesn't work. I did try this
command lin
Ah no, sorry, the problem is, that I have non-image data (vectors
coordinates)
that I want to press into an image with the yuv420p pixel format
>>> That is a bad idea given that (for your scenario) hevc is a lossy codec.
>> even if I use "-x265-params lossless=1"? is there another
On 2017-11-06 09:11 AM, Jakob Schneider wrote:
Ah no, sorry, the problem is, that I have non-image data (vectors coordinates)
that I want to press into an image with the yuv420p pixel format
That is a bad idea given that (for your scenario) hevc is a lossy codec.
even if I use "-x265-params l
>> Ah no, sorry, the problem is, that I have non-image data (vectors
>> coordinates)
>> that I want to press into an image with the yuv420p pixel format
>That is a bad idea given that (for your scenario) hevc is a lossy codec.
even if I use "-x265-params lossless=1"? is there another codec i co
Thanks Carl and Kieran,
The version is not an issue at all, just curious because I saw in this post:
https://ffmpeg.org/pipermail/ffmpeg-user/2015-March/025630.html
that the recreated DPX files were also version 2.
Regards,
Xavi
-Missatge original-
De: ffmpeg-user [mailto:ffmpeg-user-bo
On Mon, Nov 06, 2017 at 13:46:29 +0100, Carl Eugen Hoyos wrote:
> > It seems the image2 muxer uses the framerate reported by the
> > demuxer (but as cfr).
>
> This is wrong, the image2 muxer does not know anything about
> the input frame rate.
Hmm. Even if I avoid testsrc (in case it is not quite
2017-11-06 11:55 GMT+01:00 Jakob Schneider :
> Ah no, sorry, the problem is, that I have non-image data (vectors coordinates)
> that I want to press into an image with the yuv420p pixel format
That is a bad idea given that (for your scenario) hevc is a lossy codec.
Please remember not to top-post
2017-11-06 12:23 GMT+01:00 Moritz Barsnick :
> On Sun, Nov 05, 2017 at 21:14:26 +0100, Mikael Persson wrote:
>> Regarding: -vsync vfr
>> From the doc: Frames are passed through with their timestamp or dropped so
>> as to prevent 2 frames from having the same timestamp.
>>
>> This would ensure no re
2017-11-06 13:21 GMT+01:00 Camara Caamaño, Xavier :
> I updated the Windows build for ffmpeg and at least the error doesn't show up.
Yes.
> I still get the warning of:
>
> Cannot allocate worst case packet size, the encoding could fail.
This is expected for high-res input, you will get an error
Hi,
I updated the Windows build for ffmpeg and at least the error doesn't show up.
I still get the warning of:
Cannot allocate worst case packet size, the encoding could fail.
However, after wrapping the 6k 16bit dpx sequence into ffv1.mkv and de-wrapping
again into dpx, the checksums
are t
On Sun, Nov 05, 2017 at 21:14:26 +0100, Mikael Persson wrote:
> Regarding: -vsync vfr
> From the doc: Frames are passed through with their timestamp or dropped so
> as to prevent 2 frames from having the same timestamp.
>
> This would ensure no repetitions, but does not guarantee that no frames ar
Ah no, sorry, the problem is, that I have non-image data (vectors coordinates)
that I want to press into an image with the yuv420p pixel format, so that I can
encode them with ffmpeg and later decode them with NVDEC and get my original
data.
So it is not really a question regarding ffmpeg, more
Hi
On Mon, Nov 6, 2017 at 9:39 AM, Jakob Schneider
wrote:
>
> Hi everyone,
>
> I am trying to use NVDEC to speed up my transfers of OpenGL related stuff (3D
> Objects), that means treat these objects as images and encode them. As stated
> at https://developer.nvidia.com/nvidia-video-codec-sdk#N
Hi,
Just in terms of the issue:
That error message was introduced in December 2006 here:
https://github.com/FFmpeg/FFmpeg/commit/38a7834bbb24ef62466b076715e0add60e1d6962
in order to fix this issue with 5k encodes:
https://trac.ffmpeg.org/ticket/6005
which refers to a max packet size of 2147483
Hi,
On Mon, Nov 6, 2017 at 9:18 AM, Camara Caamaño, Xavier
wrote:
> Dear list,
>
> I have some issues related to the wrapping of a dpx imatge sequence into ffv1
> in mkv container.
>
> I get an error when I try to wrap a 6K 16bit image sequence: Invalid minimum
> required packet size
> I know I
Hi everyone,
I am trying to use NVDEC to speed up my transfers of OpenGL related stuff (3D
Objects), that means treat these objects as images and encode them. As stated
at https://developer.nvidia.com/nvidia-video-codec-sdk#NVDECFeatures, NVDEC
only supports the YUV420 pixel format, so I can’t
Dear list,
I have some issues related to the wrapping of a dpx imatge sequence into ffv1
in mkv container.
I get an error when I try to wrap a 6K 16bit image sequence: Invalid minimum
required packet size
I know I'm pushing a lot, but these are the original scanned images of a 35mm
negative fi
24 matches
Mail list logo
