Hello Tim,
do you think that these flags can also be implemented into the IMX
encoding of ffmpeg?
+ SIGNAL STANDARD = 1
(ITU 601)
+ Color siting = 4
(Rec 601)
Best Regards
Christoph
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
On 13/04/15 08:34, Christoph Gerstbauer wrote:
Hello Tim,
do you think that these flags can also be implemented into the IMX
encoding of ffmpeg?
+ SIGNAL STANDARD = 1
(ITU 601)
+ Color siting = 4
(Rec 601)
[..]
They could easily be hardcoded in, however they could then be
On 13/04/15 11:48, Christoph Gerstbauer wrote:
Therfore I think the only sane approach would be to have them as user
settable flags which would take more careful thinking about...
Yes, sorry, I didnt said it detailed: Yes a flag which can be enabled by
the user would be the best solution for
Therfore I think the only sane approach would be to have them as user
settable flags which would take more careful thinking about...
Yes, sorry, I didnt said it detailed: Yes a flag which can be enabled by
the user would be the best solution for that.
Do you think these 2 flags could be
On 23/03/15 09:45, Christoph Gerstbauer wrote:
If it works for you I will submit a tidied up version, with revised fate
checksums, but that will have to wait awhile as I'm away next week...
Hello Tim!
thank you, it works for PAL and NTSC (720x512/720x480) but there is a
just little bug for
Hello Tim!
thank you, it works for PAL and NTSC (720x512/720x480) but there is a
just little bug for NTSC when encoding to 720x486 in stored dimension!
My patch only deals with the addition of the display y offset metadata,
it should not touch exisiting metadata, are you saying that the figures
On 30/03/15 09:44, tim nicholson wrote:
On 30/03/15 08:33, Christoph Gerstbauer wrote:
Hello Tim!
thank you, it works for PAL and NTSC (720x512/720x480) but there is a
just little bug for NTSC when encoding to 720x486 in stored dimension!
My patch only deals with the addition of the display y
On 19/03/15 15:48, Christoph Gerstbauer wrote:
Shame, don't understand the qmax issue. but if you look at:-
tests/lavf_regression.sh line 90
you will see an IMX30 example which uses -qmax 12 and my other other
parameters. However not sure what difference closed/open gop makes on I
frame
Am 20.03.2015 um 16:21 schrieb tim nicholson:
On 20/03/15 09:19, tim nicholson wrote:
On 19/03/15 15:48, Christoph Gerstbauer wrote:
Shame, don't understand the qmax issue. but if you look at:-
tests/lavf_regression.sh line 90
you will see an IMX30 example which uses -qmax 12 and my other
On 20/03/15 15:21, tim nicholson wrote:
On 20/03/15 09:19, tim nicholson wrote:
On 19/03/15 15:48, Christoph Gerstbauer wrote:
Shame, don't understand the qmax issue. but if you look at:-
tests/lavf_regression.sh line 90
you will see an IMX30 example which uses -qmax 12 and my other other
On 18/03/15 09:46, Christoph Gerstbauer wrote:
Hello
I am testing with ffmpeg the IMX50 D10 encoding, and I am very close to
my target but I have to create 3 metadata values in the MXF header which
is standard in most IMX50 MXF ecndodings:
+ SIGNAL STANDARD = 1 (ITU 601)
+ display y
Don't know if its relevant but your coding parameters are slightly
different to the one's I use for D10, and I wonder if this affects the
automatic metadata insertion..
-flags +ildct+ilme+low_delay
Well ilme seems kind of redundant for I frame only coding but probably
harmless.
-tag:v mx5p
Hello
I am testing with ffmpeg the IMX50 D10 encoding, and I am very close to
my target but I have to create 3 metadata values in the MXF header which
is standard in most IMX50 MXF ecndodings:
+ SIGNAL STANDARD = 1 (ITU 601)
+ display y offset = 32 - I am encoding 720x608 sources with
13 matches
Mail list logo
