ffmpeg: flv encoding high quality

[marcorocchini]

but if I encode my source HD mxf with ffmpeg in flv/.avi can I encode in high quality, high bitrate and yuy or yuv 422?

thanks

[Selur]

Since:
1. flv and avi both can contain MPEG-4 AVC content
2. MPEG-4 AVC can support the color formats you asked for
3. ffmpeg can convert to high quality MPEG-4 AVC content using x264 (assuming it is compiled with x264 support)
4. ffmpeg can create flv and avi content
a high quality conversions should be possible.

How good the conversion is now mainly depends on the encoding settings you use.
Can't really help you there, since I normally don't use ffmpeg to create MPEG-4 AVC and there are probably other users who know more about encoding to MPEG-4 AVC using ffmpeg than I. (would have to read up on x264<>ffmpeg mappings and the like)
-> Yes, it is possible to create what you want and it shouldn't be that complicated.

[marcorocchini]

ffmpeg -i c0020.mxf -vcodec flv -pix_fmt yuvj422p -q:v 0 -vf colormatrix=bt601:bt709 -an flv.avi

I have try this but won't encode in 422, ffmpeg seems want encode only in 420

[poisondeathray]

FLV is not a codec, it's a container

-vcodec libx264

Not very many hardware players support AVC 422 , and if this is for web/browser, only some iterations of flash player do

[marcorocchini]

but there is not a way to encode with "flv1" in ffmpeg, so it encode in yuvj422p?

Considering my source c0020.mxf: in general is correct in ffmpeg encode using yuvj422p or yuv422p?

I think is not properly correct using rgb's format (also in virtualdub), however if I does not do colorspaces conversions is better for quality. Or I mistake?

[poisondeathray]

but there is not a way to encode with "flv1" in ffmpeg, so it encode in yuvj422p?

Considering my source c0020.mxf: in general is correct in ffmpeg encode using yuvj422p or yuv422p?

I think is not properly correct using rgb's format (also in virtualdub), however if I does not do colorspaces conversions is better for quality. Or I mistake?

fourcc "FLV1" is sorensen spark. It's 1st generation flash video, very low quality and doesn't support 422

yuvj422p is "full range" , you only use that when the encoder and decoder expects full range, eg. MJPEG . Otherwise it will be decoded incorrectly

if you use video=>fast recompress in vdub, no color space conversions occur

[marcorocchini]

ok for virtualdub: fast recompress=same colorspace and no conversion

but in ffmpeg, assumed that my source is yuv (or yuy2) if I use -pix_fmt yuvj422p this involve hoewvwe a colorspace conversion? or how is to be used ffmpeg as the "fast recompress" of virtualdub?

[poisondeathray]

ok for virtualdub: fast recompress=same colorspace and no conversion

but in ffmpeg, assumed that my source is yuv (or yuy2) if I use -pix_fmt yuvj422p this involve hoewvwe a colorspace conversion? or how is to be used ffmpeg as the "fast recompress" of virtualdub?

Your source is yuv422p

You can check with ffmpeg -i input.mxf

yuv422p(tv, bt709)

xdcam cameras actually record Y' 16-255 . But there are usable overshoots (235-255) or "superbrights" than can be brought down to legal range and used . In vdub, they are clipped if converted to RGB

It's not the same thing as yuvj422p . The "j" means a full range flag is present . The actual levels are untouched (input levels = output levels) , nothing is clipped and you are still in YUV color model . That's different than converting to RGB . But the danger is the behaviour of the recieving software or decoder. Some obey flags, some do not. You can get unintended results . But formats like mjpeg are standardized to be full range (because they are based on jpeg which use 0-255 in YUV) , so it's "normal" to use full range for the mjpeg case. There is no cause for concern and all software handles it correctly. But "normal" codecs use "legal range" or "TV" range YUV , from Y' 16-235 , CbCr 16-240 .

[Selur]

Here's an example hot to convert a 10bit 4:2:2 prores file to 4:2:2 8bit x264 inside a flv container.

ffmpeg -i "H:\TestClips&Co\prores\prores422_.mov" -pix_fmt yuv422p10le -an -vcodec libx264 -crf 18 "h:\output\test.flv"

select a higher crf value to archive less file size an quality preservation;
select a lower crfv values get archive larger file sizes an preserve more quality

'-q:v 0' would probably trigger a lossless conversion

regarding the colors like poisondeathray mentioned, use:
yuv422p for TV range input (16-235)
yuvj422p for PC range input (0-255)

main point is using libx264 as encoder.

[marcorocchini]

Thank you selur, maybe I use "flv in avi"?

Consider my source is:

https://dl.dropboxusercontent.com/u/39871584/C0020.mxf

I apply this:

ffmpeg -i c0020.mxf -vcodec flv -pix_fmt yuvj422p -q:v 0 -an flv.avi

OR

ffmpeg -i c0020.mxf -vcodec flv -pix_fmt yuv422p -q:v 0 -an flv.avi

or using -vcodec flv1 or using -pix_fmt yuv422p101e (it strangely returns "Unknow pixel format request")

don't work or convert in 420

I will do others proof with libx264

[marcorocchini]

ok for virtualdub: fast recompress=same colorspace and no conversion

but in ffmpeg, assumed that my source is yuv (or yuy2) if I use -pix_fmt yuvj422p this involve hoewvwe a colorspace conversion? or how is to be used ffmpeg as the "fast recompress" of virtualdub?

Your source is yuv422p

You can check with ffmpeg -i input.mxf

yuv422p(tv, bt709)

xdcam cameras actually record Y' 16-255 . But there are usable overshoots (235-255) or "superbrights" than can be brought down to legal range and used . In vdub, they are clipped if converted to RGB

It's not the same thing as yuvj422p . The "j" means a full range flag is present . The actual levels are untouched (input levels = output levels) , nothing is clipped and you are still in YUV color model . That's different than converting to RGB . But the danger is the behaviour of the recieving software or decoder. Some obey flags, some do not. You can get unintended results . But formats like mjpeg are standardized to be full range (because they are based on jpeg which use 0-255 in YUV) , so it's "normal" to use full range for the mjpeg case. There is no cause for concern and all software handles it correctly. But "normal" codecs use "legal range" or "TV" range YUV , from Y' 16-235 , CbCr 16-240 .

So possibly I have to find a codec that work with a command line -pix_fmt yuv422p

but considering my source C0020.mxf

if I would like use HuffYUV as encoder, the command line would be:

ffmpeg -y -i c0020.mxf -vcodec ffvhuff -pix_fmt yuv422p -q:v 0 -flags +ilme+ildct -top 1 -an temp3.avi

There is possibility to optimize this way of encoding? ... source file is 275MB, encoded=2,1GB

[Selur]

"-pix_fmt yuv422p101e" -> is wrong "yuv422p10le"
also like mentioned before flv is a container not a codec, so -vcodec flv isn't helping.
Also if your input das not have 10bit precision, 10le is wrong too

I will do others proof with libx264

Looking forward to that

So possibly I have to find a codec that work with a command line -pix_fmt yuv422p

like libx264,.... *gig*

-> looked at your source and

ffmpeg -y -i "C0020.mxf" -pix_fmt yuv422p -an -vcodec libx264  -flags +ildct+ilme -x264opts tff=1  -crf 18 "test.flv"

will encode to interlaced H.264 content inside a flv container and preserve the 422 color sampling


so:

Format                                   : MPEG Video
Commercial name                          : XDCAM HD422
Format version                           : Version 2
Format profile                           : 4:2:2@High
Format settings, BVOP                    : Yes
Format settings, Matrix                  : Custom
Format settings, GOP                     : M=3, N=12
Format_Settings_Wrapping                 : Frame
Duration                                 : 36s 600ms
Bit rate                                 : 50.0 Mbps
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 25.000 fps
Standard                                 : Component
Color space                              : YUV
Chroma subsampling                       : 4:2:2
Bit depth                                : 8 bits
Scan type                                : Interlaced
Scan order                               : Top Field First
Compression mode                         : Lossy
Bits/(Pixel*Frame)                       : 0.965
Stream size                              : 218 MiB (83%)

will become:

Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High 4:2:2@L4.0
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Codec ID                                 : 7
Duration                                 : 36s 600ms
Bit rate                                 : 31.9 Mbps
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:2
Bit depth                                : 8 bits
Scan type                                : MBAFF
Bits/(Pixel*Frame)                       : 0.616
Stream size                              : 139 MiB (96%)

side note: you might also want to set vui settings to preserve the Color primaries, Transfer characteristics, Matrix coefficients information and depending on what you want to do with the flv modify the libx264 settings and maybe deinterlace.

[marcorocchini]

Selur I thank you but using -vcodec lib264 don't help my specific problem:

using

ffmpeg.exe -i c0020.mxf -vcodec libx264 -pix_fmt yuv422p -preset veryfast -tune fastdecode -crf 0 -r 25.000 -flags +ildct+ilme -x264opts keyint=1:tff=1 -an x264_output.avi

or

ffmpeg -y -i "C0020.mxf" -pix_fmt yuv422p -an -vcodec libx264 -flags +ildct+ilme -x264opts tff=1 -crf 18 "test.flv"

(but I'm costrincted to the .avi format output)

or

ffmpeg -y -i "C0020.mxf" -pix_fmt yuv422p -an -vcodec libx264 -flags +ildct+ilme -x264opts tff=1 -crf 18 "test.flv"ffmpeg -y -i "C0020.mxf" -pix_fmt yuv422p -an -vcodec libx264 -flags +ildct+ilme -x264opts tff=1 -crf 18 "test.avi"

in all cases to use the libx264 (but also the use of -vcodec mpeg2video) I carry the same problem I have with MPG2 or using ffdshow VFW in my NLE (but virtualdub and all programs that take from VFW-ffdshow) the clip shows the first frame black and with difficulty seeking.



The problem is related to ffdshow and in particular to the module VFW of ffdshow, in DirectShow all work ok.. but I'm forced to use VFW because my NLE uses only VFW.

If you use your command line and the output in VirtualDub via VFW you can see the problem (first frame black and others).

May be strange but when I use

ffmpeg -i c0020.mxf -vcodec flv -pix_fmt yuvj422p -q:v 0 -an flv.avi

incredibly everything works fine inside my nle: first frame ok, seeking good, no deblocking... but ffmpeg returns that encode in 420

[Selur]

No comment about the vcodec flv and 420, has been explained before. (from my point of view using -vcodec flv is just a bad idea)
Normally people who use x264 for intermediate use either lossless encoding with a keyint of 1 or the AVC-intra (-intra) option.

but I'm costrincted to the .avi format output

then why ask for flv in the first place

I think everything that was needed to solve the problem was said.
-> which you much luck with your further endeavours

[marcorocchini]

the problem is in FFDSHOW that cannot decode well any formats in Vfw.

Maybe there is a good way to encode in libx264 or I don't have use ffdshow but another decoder vfw for libx264.

However I can not use flv, for various reasons, not least the fact that it does not work in 422.

Much more simply: if I do

ffmpeg -i c0020.mxf -vcodec copy -an outputCOPY.avi

and use ffdshow with mpegINavi=libavcodec and set the registry vidc.mpg2=ff_vfw.dll

I get exactly the same problem: first frame is black, deblocking (only on playback, export is ok), seeking a little difficult in backward ecc..



it is strange that using -vcodec flv are solved all the problems except for the YUV422 encoding impossible