There are a few tracs on it, and this:
https://superuser.com/questions/902661/ffmpeg-past-duration-0-xx-too-large
Seems to be a bug somehow to me but I never looked closely enough.
On Mon, Apr 16, 2018 at 7:50 PM, Gabriel Balaich
wrote:
> Hey all, I'm having an issue with the "Past duration
Dear Lou,
Thanks for your quik repply... this is exactly what I need :) ...
I will check the ZMQ filter now !
If someone have different clue it could be great too ;)
Thanks again !
Le 2018-06-05 23:22, Lou Logan a écrit :
> On Tue, Jun 5, 2018, at 1:06 PM, David Barbassat wrote:
>
>>
On Tue, Jun 5, 2018, at 1:06 PM, David Barbassat wrote:
> Dear All,
>
> I am looking for a way to encode by ffmpeg a video but with a dynamic
> crop provided by shell variables
>
> For example is it possible to use ${x} and ${y} in the command line and
> change them during the encoding process
Dear All,
I am looking for a way to encode by ffmpeg a video but with a dynamic
crop provided by shell variables
For example is it possible to use ${x} and ${y} in the command line and
change them during the encoding process without launch the encoding each
time ?
Like a crop motion :)
Rega
Thanks for the reply! :-)
My request/question is not strictly related to decklink but capturing in
general; The ability to set the start tc when the first frame is captured
from any capture device. The method should not be depending on incoming tc
signals from external devices but rather rely on t
> On Jun 4, 2018, at 4:41 PM, Steinar Apalnes wrote:
>
> Hi,
>
> I'm doing a lot of capturing through decklink video devices and I was
> wondering if it was, or would be possible to make ffmpeg set a frame
> accurate start TC based on wall clock when the first frame was captured?
> An option li
Thanks all! Meanwhile let me try every way that you have suggested.
Zak, I look forward to see your result too!
Sincerely,
Sook Sin
Sent from Mail for Windows 10
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
On 05. 06. 2018 16:15, Carl Eugen Hoyos wrote:
> 2018-06-05 10:55 GMT+02:00, Mitja Pirih :
>
>> I am transcoding a live channel from live source. Everything
>> works as expected until SAR/DAR changes then ffmpeg
>> crashes out.
> If you experience a crash with FFmpeg, please provide
> backtrace, di
I understand now that there is no new ffmpeg process starting. But I do
have one doubt, is there any possibility that the P or B frames may be
converted to one another during encoding process? Because I find the same
total number of frames at both ends, but the number of P and B frames
differ.
R
> If you experience a crash with FFmpeg, please provide> backtrace, disassembly
>and register dump.
Carl Eugen, If you're going to demand this information, you need to be prepared
to do a lot of work helping people to get it. The ability to do these things is
not common among computer users.
If
2018-06-05 10:55 GMT+02:00, Mitja Pirih :
> I am transcoding a live channel from live source. Everything
> works as expected until SAR/DAR changes then ffmpeg
> crashes out.
If you experience a crash with FFmpeg, please provide
backtrace, disassembly and register dump.
Thank you, Carl Eugen
In production, drop this: -hwaccel cuvid -c:v mpeg2_cuvid
There's a reason mpv devs do not recommend cuvid, in particular.
https://github.com/mpv-player/mpv/commit/dbef5b737e2f994f02923c8214cba368b663a655
On 5 June 2018 at 11:55, Mitja Pirih wrote:
> Hi,
>
> I am transcoding a live channel fro
Hi,
I am transcoding a live channel from live source. Everything works as
expected until SAR/DAR changes then ffmpeg crashes out. It happens only
when I use HW transcoding. Have you seen this behavior before? Any ideas
how to solve this issue?
/usr/bin/ffmpeg -hwaccel cuvid -c:v mpeg2_cuvid -i
ud
13 matches
Mail list logo
