from .mxf ---> avi 1080/1088 mess --> mp4 please please please help my cats

[marcorocchini]

Hi, please can help my poor cats ?



I have a big problem that I can not solve

My .mxf source:
https://dl.dropboxusercontent.com/u/39871584/C0111.MXF

my source:
attached C0111.AVI
is the "same" of C0111.MXF but in Morgan MJPEG codec, I was a problem that strangely this codec produce 1920x1088 images (instead of 1920x1080)

so now I would like do this:

- encode C0111.avi in mp4 but returning at 1920x1080

- and encode C0111.MXF in mp4

but I'm not able do to this

with ffmpeg can I resize or resize/crop or crop but preserving same quality also if the .avi is 1088? and what is the commandlines?

thanks also by my cats

[Gravitator]

MediaInfo(Source file):

General
Complete name : H:\TEMP\C0111.MXF
Format : MXF
Format profile : OP-1a
Format settings : Closed / Complete
File size : 21.6 MiB
Duration : 2s 920ms
Overall bit rate : 62.0 Mbps
Encoded date : 2014-06-21 21:01:19.000
Writing application : SONY Opt 1.22
Writing library : SONY Opt 1.22

Video
ID : 2
Format : MPEG Video
Format version : Version 2
Format profile : 4:2:2@High
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format_Settings_Wrapping : Frame
Codec ID : 0D01030102046001-0401020201040300
Duration : 2s 920ms
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
Time code of first frame : 00:00:00:00
Time code source : Group of pictures header
Stream size : 17.4 MiB (81%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Hi marcorocchini,
You somehow miraculously MXF (21 MB) turned to AVI (73 MB) !
No need to crop or resize - only normal packaging to mkv, mp4, avi (passthrough).
Recode for size reduction is not going to?

[poisondeathray]

Since morgan is causing problem: Don't use morgan => problem fixed

[marcorocchini]

mmm but my Broadcats TV channell need morgan.. what I have to do?
please help my cats

[poisondeathray]

mmm but my Broadcats TV channell need morgan.. what I have to do?
please help my cats

No they don't. No Broadcaster in the world uses Morgan, or requests it for submissions . It's a non standard MJPEG format.

[marcorocchini]

poison I have change mjpeg codec, I use lead codec

I wonder this: if I convert my .avi in a mjpeg lead avi file and the .avi I convert it on mp4, this mp4 have to be or not same video levels and same Bt709 of the original mxf hd file?


And if I play the .mp4 on my media player box that have 1 Sd analog output, do it BT709-->bt601 colorconversion? I should have send my .mp4 to the broadcats television, but if I know all parameters for SD files I don't know parameters for hd files. At the moment I can upload .mp4 files with a system called vmover

In attachment: bars HD with lead mjpeg codec

I have use

v:\automazioneclip\core\ffmpeg.exe -y -i barsLead.avi -pix_fmt yuvj420p -f rawvideo -vcodec rawvideo - | v:\automazioneclip\core\ffmpeg.exe -y -f rawvideo -s 1920x1080 -r 25 -i - -c:v libx264 -profile:v main -level:v 3 -g 33 -bf 1 -crf 18 -flags +ilme+ildct -top 1 -vf colormatrix=bt601:bt709 -c:a libvo_aacenc -b 256k -aspect 16:9 out.mp4

but in the sd output of the mediaplayer box, levels seems wrong

[poisondeathray]

poison I have change mjpeg codec, I use lead codec

I wonder this: if I convert my .avi in a mjpeg lead avi file and the .avi I convert it on mp4, this mp4 have to be or not same video levels and same Bt709 of the original mxf hd file?

It depends on the decoder used, depends on the software handing off to lead/mjpeg

Technically mjpeg is usually suppose to be stored at 0-255 YUV, but some decoders convert this by clamping, some clip, some return full range. That's one of the many reasons it's not a good intermediate - it's very inconsistent

So it also depends what your software did internally before rendering out to Mjpeg . Did it work in YUV for the entire workflow? Did it do a RGB => YUV conversion? If so, what matrix ?

And if I play the .mp4 on my media player box that have 1 Sd analog output, do it BT709-->bt601 colorconversion? I should have send my .mp4 to the broadcats television, but if I know all parameters for SD files I don't know parameters for hd files. At the moment I can upload .mp4 files with a system called vmover ^^

If media box has sd analog output (composite ? Red, Yellow, White ?) , it will be outputing YUV signal, and no 709<=>601 conversion occuring. That will be responsiblity of the display as it recieves the YUV signal and displays as RGB

[poisondeathray]

Check your lead mjpeg link, I cannot see it

You don't need to pipe to change the levels; the ffmpeg version of -vf scale can override the -pix_fmt yuvj420p issue . ffmbc version cannot - it uses different -vf scale . -vf scale now has input/output matrices and tv/pc ranges .

Your interlaced chroma will cause issues , because you are scaling interlaced 422 => interlaced 420, but using progressive scaling algorithm => this will cause "chroma ghosting. You need interl=1 to signal interlaced scaling

These things were mentioned in your other thread

[marcorocchini]

mm sorry: this is attachemet is the .avi in lead mjpg

[poisondeathray]

There is chroma aliasing (see vertical lines on the test pattern) in leadmjpg file, especially visible if you view Cb, Cr planes separately. Also there is a combing pattern that shouldn't be present on still image.

This has been cropped, enlarged 2x with nearest neighbor resize. Top half is original, bottom half is lead mjpeg. Notice the grid pattern and vertical line




This has correct matrix if it was exported from your NLE (it matches the barsHD.mxf), so no need to adjust for 700<=>601 , but I would still "flag" the metadata as 709 with libx264 using -x264opts

If you still want to use it without piping (I wouldn't because of the quality issues in the lead mjpeg file), you can override the full range ffmpeg decoding yuvj422p and levels PC=>TV by using -vf scale with in_range and out_range. You force both to be TV and it will be the same as the original mxf

Btw, you level limits don't make sense for HD encoding
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

Level 3 is meant for SD encoding, You should be using Level 4, or 4.1 . You should use maxrate and bufsize if this is for devices.

ffmpeg -i leadmjpg.avi -c:v libx264 -pix_fmt yuv420p -profile:v main -level:v 4.1 -g 33 -bf 0 -crf 18 -flags +ildct+ilme -x264opts tff=1:ref=1:colorprim=bt709:transfer=bt709:colormatrix=bt709:vbv-maxrate=40000:vbv-bufsize=30000 -vf scale=w=-1:h=-1:interl=1:in_range=tv:out_range=tv -an -aspect 16:9 lead.mp4

Remember this post?
https://forum.videohelp.com/threads/365502-MP4-from-ffmpeg-unplayable-please-help-my-**...=1#post2330581

That illustrates chroma ghosting issue from interlaced 422 => 420 using progressive scaling algorithm. -vf scale with interl=1 will use interlaced chroma scaling

[poisondeathray]

Can you upload same colorbars with morgan mjpeg ? I want to see if chroma issues exist with it as well

There was a field order glitch in your first morgan file at the end

You should be able to crop the 8px out vertically without issue (they're just at the bottom, and 8px crop is "legal" for interlaced 4:2:2 or 4:2:0)

[marcorocchini]

yes yes yes

[poisondeathray]

It looks clean/fine, but it was encoded using vdub according to the name ?

Are you planning to use morgan from NLE, or from vdub ?

Was leadMJPG.avi from vdub or from NLE ? (I want to rule out issue with your NLE, or was it fault of lead codec? )

[poisondeathray]

So to do the 8px crop, you can use -vf crop (no special rules for interlaced vertical crop in this case since it's 8px) ; but since you have to do in_range , out_range as well, you need to use -filter_complex

So this is for your morgan files. This commandline uses no bframes (copied from your commandline given above), but I would use profile:v high, and -bf 2 instead - high@L4.1 with 2 bframes is pretty standard for HD AVC encodes . It will give you slightly better compression (better quality at the same filesize, or lower filesize at the same quality)

ffmpeg -i morgan_input.avi -c:v libx264 -profile:v main -level:v 4.1 -g 33 -bf 0 -crf 18 -flags +ildct+ilme -x264opts tff=1:ref=1:colorprim=bt709:transfer=bt709:colormatrix=bt709:vbv-maxrate=40000:vbv-bufsize=30000 -filter_complex crop=out_h=1080:y=0,scale=interl=1:in_range=tv:out_range=tv -pix_fmt yuv420p -an -aspect 16:9 morgan_output.mp4

[marcorocchini]

mm yes it seems work but if I don't mistake levels video are a little attenuated: is there a way to change levels, pc-->tv or viceversa?

out_range=full?

[poisondeathray]

How are you checking levels ? What hardware or software? What display and graphics setup -> are they calibrated ?

Levels in the output are the same as the source mxf. Check and confirm with a waveform.

There is no levels filter in ffmpeg yet, but there is a LUT function - I haven't used it. Basically there is no easy way to make adjustments yet like you can in a NLE or avisynth

source mxf


ffmpeg libx264 output

[marcorocchini]

I use vlc: seems that mp4 from the .avi have level a little attenuted

reference is: same commandline but source is barsHD.mxf (original bars HD from the camera), and the levels semms ok

And then: open the .mp4 with virtualdub with the FFmpeg plugin



but seems also the .mp4 have levels attenuated

hoewver I transfer in uncompressed (YUY2) output file into my digisuite system connected to the waveform video:

result is that if I open barsHD.mxf in virtualdub and put the output on timeline, bars levels is ok
but when I use the ffmpeg output from this commandline, levels are attenuated

[poisondeathray]

The original MXF, and output h264/MP4 are legal range Y'16-235 .

or did you mean levels attenuated COMPARED TO THE MJPEG ???

That's because the mjpeg is "illegal" 0-255 . The mjpeg will be decoded by ffmpeg as 0-255 full range YUV , but unless you convert to RGB with a full range matrix the blacks will be crushed, whites blown when they are converted to RGB for display. But most hardware and software cannot handle full range properly even if flagged full range. They will use the wrong Rec matrix. The correct thing to do is use standard/legal range YUV 16-235 so it looks correct everywhere

[marcorocchini]

when I you your commanline and source is directly .mxf --> levels is ok also on my digisuite hardware system and confirm is all ok

but "strangely" when the source is .avi mjpeg levels are attenuated

as reference I assume that scale and levels

[marcorocchini]

I wonder, in ffmpeg what correspond to avisynth at the

ColorYUV(levels="PC->TV")

(or viceversa)?

[poisondeathray]

Without a doubt, the levels in the output MP4 (derived from morgan) are the same as the MXF . 100% certain

You might be using different renderer for display . Make sure you have 1 video application open at one time. Then close it, then reopen and open other video. In vdub disable direct x

I wonder, in ffmpeg what correspond to avisynth at the

ColorYUV(levels="PC->TV")

(or viceversa)?

You can change the -vf scale in_range and out_range . I wouldn't do it here unless you want something different than the mxf and wrong levels

[poisondeathray]

Or maybe you're using old ffmpeg ? you need new ffmpeg for the new -vf scale with in_range and out_range . Look at the log file for errors

Check this, it's just 2 frames from the morgan avi as input, with the same commandline

[marcorocchini]

mm, my cats demand: what version of ffmpeg are you using?

[marcorocchini]

Oh my cats have think what you have think at the same time ^^

[marcorocchini]

V:\automazioneclip\core>ffmpeg
ffmpeg version N-58502-g738ebb4 Copyright (c) 2000-2013 the FFmpeg developers
built on Nov 27 2013 22:01:44 with gcc 4.8.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetyp
e --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --ena
ble-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-l
ibopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libsp
eex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aa
cenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavp
ack --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
libavutil 52. 55.100 / 52. 55.100
libavcodec 55. 44.100 / 55. 44.100
libavformat 55. 21.102 / 55. 21.102
libavdevice 55. 5.102 / 55. 5.102
libavfilter 3. 91.100 / 3. 91.100
libswscale 2. 5.101 / 2. 5.101
libswresample 0. 17.104 / 0. 17.104
libpostproc 52. 3.100 / 52. 3.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfi
le}...

[poisondeathray]

I don't know when they added the new -vf scale with the new options, but just download new ffmpeg binary to be sure

Download the file from post #22 to check as well

[marcorocchini]

mmmm

[marcorocchini]

now I have used the ffmpeg version N-64405-g7d179b1 Copyright (c) 2000-2014 the FFmpeg developers
built on Jul 3 2014 22:02:04 with gcc 4.8.3 (GCC)

but I see also in vlc 2 different levels: when (in your commanline) I use as inputfile the original mxf --> levels are ok
meanwhile when use the mjpeg avi levels are attenuated


hoewver I have this issue also when in vlc I play directly a .mxf and a .avi mjpeg file, but this problem are solved when after NLE and using ffmpeg and or ffmbc in pipe I reencode in mxf or mp4 SD

[poisondeathray]

Is "mmmm" good or bad ?

Go it figured out ?

If you don't force "TV" levels with vf scale, ffmpeg "thinks" MJPEG is yuvj420p . That "j" means full range. So when you convert to yuv420 normally, the contrast will be reduced as you go from 16-235 to 32-215 . Reduced range, reduced contrast. Image looks "washed" out. I explained this to you in a few of your other threads

Wrong levels (compare with post #16)



If you use an RGB color picker, you will see "white" is 235,235,235, instead of 255,255,255 like it is in post #16. i.e "white" is not "white"

[poisondeathray]

but I see also in vlc 2 different levels: when I use as inputfile the original mxf levels are ok
meanwhile when use the mjpeg avi levels are attenuated

Remember I said mjpeg is BAD. That's one of the reasons. Different prorams will handle MJPEG differently. Very inconsistent. Some decode full range, some clamp, some clip

In order to "reverse" what was done, that ffmpeg commandline is required, the levels in post 16 show that original source mxf = output mp4. A different workflow might be required if you used another mjpeg decoder

For example, in your NLE, it's not using ffmpeg /libav libraries to decode mjpeg, it might handle mjpeg completely differently