On 2/20/19, 11:36 PM, "DeBacker, Bart" wrote:
On 2/20/19, 6:06 PM, "ffmpeg-user on behalf of Carl Eugen Hoyos"
wrote:
2019-02-20 21:15 GMT+01:00, DeBacker, Bart :
>
> On 2/19/19, 2:15 PM, "ffmpeg-user on behalf of Carl Eugen Hoyos"
>>
>>
On 2/20/19, 6:06 PM, "ffmpeg-user on behalf of Carl Eugen Hoyos"
wrote:
2019-02-20 21:15 GMT+01:00, DeBacker, Bart :
>
> On 2/19/19, 2:15 PM, "ffmpeg-user on behalf of Carl Eugen Hoyos"
>>
>> 2019-02-18 22:53 GMT+01:00, Marton Balint :
>> >
>> > On Mon, 18 Feb
2019-02-20 21:15 GMT+01:00, DeBacker, Bart :
>
> On 2/19/19, 2:15 PM, "ffmpeg-user on behalf of Carl Eugen Hoyos"
>>
>> 2019-02-18 22:53 GMT+01:00, Marton Balint :
>> >
>> > On Mon, 18 Feb 2019, DeBacker, Bart wrote:
>>
>> >> I grabbed the latest snapshot and see the same behavior. I don't
>> >>
On 2/19/19, 11:48 AM, "ffmpeg-user on behalf of Ted Park"
wrote:
> On Feb 17, 2019, at 9:22 PM, DeBacker, Bart
wrote:
>
> Output #0, mp4, to 'lores.mp4':
> Metadata:
>application_platform: Omneon Media Api (mqx)
>uid :
On 2/19/19, 2:15 PM, "ffmpeg-user on behalf of Carl Eugen Hoyos"
wrote:
2019-02-18 22:53 GMT+01:00, Marton Balint :
>
> On Mon, 18 Feb 2019, DeBacker, Bart wrote:
>> I grabbed the latest snapshot and see the same behavior. I don't think
>> this is really a bug,
2019-02-18 22:53 GMT+01:00, Marton Balint :
>
> On Mon, 18 Feb 2019, DeBacker, Bart wrote:
>> I grabbed the latest snapshot and see the same behavior. I don't think
>> this is really a bug, since the frames exist and are valid, but the MXF
>> metadata is specifying a start time that is a few
> On Feb 17, 2019, at 9:22 PM, DeBacker, Bart wrote:
>
> Output #0, mp4, to 'lores.mp4':
> Metadata:
>application_platform: Omneon Media Api (mqx)
>uid : e4367ad7-e332-e911-aa0c-00d0280b03c6
>generation_uid : 98377ad7-e332-e911-8165-00d0280b03c6
>company_name:
On 2/18/19, 6:26 PM, "ffmpeg-user on behalf of Ted Park"
wrote:
Is this a problem? When you link it to the original, everything is offset
by the difference?
Exactly, we have a workflow where a user can mark an in and out against the
lores version, and when we cut this out of the
Is this a problem? When you link it to the original, everything is offset by
the difference?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
On Mon, 18 Feb 2019, DeBacker, Bart wrote:
On 2/17/19, 5:57 PM, "ffmpeg-user on behalf of Carl Eugen Hoyos"
wrote:
2019-02-17 23:26 GMT+01:00, DeBacker, Bart :
> ffmpeg -i hires.mxf -s 960x540 lores.mp4
>
> ffmpeg version 4.0.1
This is soon one year old.
Carl
On 2/17/19, 5:57 PM, "ffmpeg-user on behalf of Carl Eugen Hoyos"
wrote:
2019-02-17 23:26 GMT+01:00, DeBacker, Bart :
> ffmpeg -i hires.mxf -s 960x540 lores.mp4
>
> ffmpeg version 4.0.1
This is soon one year old.
Carl Eugen
I grabbed the latest
2019-02-17 23:26 GMT+01:00, DeBacker, Bart :
> ffmpeg -i hires.mxf -s 960x540 lores.mp4
>
> ffmpeg version 4.0.1
This is soon one year old.
Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
On 2/17/19, 3:19 PM, "ffmpeg-user on behalf of Carl Eugen Hoyos"
wrote:
2019-02-17 20:22 GMT+01:00, DeBacker, Bart :
> We are currently using ffmpeg to extract a lower resolution MP4 file
> from our MXF OP1A standard hi-res files. This is the command:
>
> ffmpeg -i
2019-02-17 20:22 GMT+01:00, DeBacker, Bart :
> We are currently using ffmpeg to extract a lower resolution MP4 file
> from our MXF OP1A standard hi-res files. This is the command:
>
> ffmpeg -i hires.mxf -s 960x540 -preset veryfast -framerate 29.97
> -f mp4 lowres.mp4
Complete, uncut console
14 matches
Mail list logo
