Hi guys, I am having a problem where there is a slight blur on converted videos. I am trying to automate a couple of workflows where Adobe Media Encoder is currently used. Here are the commands that I am running: MXF Conversion: ffmpeg -y -i in.mxf -r 25 -vf settb=1/25 -flags +ilme+ildct -timecode 00:00:00:00 -acodec pcm_s16le -filter_complex "[:1:a][:2:a]amerge=inputs=2[aout]" -map "[aout]" -map 0:0 -qscale:v 6 -vcodec prores_ks -profile:v 1 -video_track_timescale 25 -copytb -1 out.mov MP4 Conversion: ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1 -sws_flags full_chroma_inp+full_chroma_int -copytb -1 out.mov I have uploaded a couple of sample screenshots to http://www.bit.st/screenshots/ <http://www.bit.st/screenshots/> Thank you in advance! /dave.
Are you really need prores codec? If you concern quality then use some loseless codec like utvideo... W dniu 2017-03-23 o 12:43, Dave pisze:
Hi guys,
I am having a problem where there is a slight blur on converted videos. I am trying to automate a couple of workflows where Adobe Media Encoder is currently used.
Here are the commands that I am running:
MXF Conversion:
ffmpeg -y -i in.mxf -r 25 -vf settb=1/25 -flags +ilme+ildct -timecode 00:00:00:00 -acodec pcm_s16le -filter_complex "[:1:a][:2:a][aout]" -map "[aout]" -map 0:0 -qscale:v 6 -vcodec prores_ks -profile:v 1 -video_track_timescale 25 -copytb -1 out.mov
MP4 Conversion:
ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1 -sws_flags full_chroma_inp+full_chroma_int -copytb -1 out.mov
I have uploaded a couple of sample screenshots to http://www.bit.st/screenshots/ <http://www.bit.st/screenshots/>
Thank you in advance!
/dave. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
ProRes is required because it is going into Final Cut Pro 7.
On 24 Mar 2017, at 2:20 am, chronek <chronek@interia.eu> wrote:
Are you really need prores codec? If you concern quality then use some loseless codec like utvideo...
W dniu 2017-03-23 o 12:43, Dave pisze:
Hi guys,
I am having a problem where there is a slight blur on converted videos. I am trying to automate a couple of workflows where Adobe Media Encoder is currently used.
Here are the commands that I am running:
MXF Conversion:
ffmpeg -y -i in.mxf -r 25 -vf settb=1/25 -flags +ilme+ildct -timecode 00:00:00:00 -acodec pcm_s16le -filter_complex "[:1:a][:2:a][aout]" -map "[aout]" -map 0:0 -qscale:v 6 -vcodec prores_ks -profile:v 1 -video_track_timescale 25 -copytb -1 out.mov
MP4 Conversion:
ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1 -sws_flags full_chroma_inp+full_chroma_int -copytb -1 out.mov
I have uploaded a couple of sample screenshots to http://www.bit.st/screenshots/ <http://www.bit.st/screenshots/>
Thank you in advance!
/dave. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
If "ffmpeg -i in.mp4 -acodec pcm_s16le -sws_flags full_chroma_inp+full_chroma_int+accurate_rnd+bitexact -sws_dither none -vcodec prores_ks -profile:v 1 -copytb -1 out.mov" not work as should then there are posibilities (1) you are using old ffmpeg (2) there is bug in ffmpeg decoder what deblock h264 when it shoud not (3) AME is encoding to different settings than prores_ks profile:v 1 (4) theres problem with timestamps and ffmpeg trying sanitize it by blending frames to keep framerate please provide a small part of your source video for testing W dniu 2017-03-23 o 19:59, Dave pisze:
ProRes is required because it is going into Final Cut Pro 7.
On 24 Mar 2017, at 2:20 am, chronek <chronek@interia.eu> wrote:
Are you really need prores codec? If you concern quality then use some loseless codec like utvideo...
W dniu 2017-03-23 o 12:43, Dave pisze:
To answer your suggestions Chronek: I tried encoding with your suggested command line it was still pretty much the same. 1) I downloaded a fresh copy of ffmpeg and compiled it and still had the same results 2) I am not really in a position to comment on 3) I assure you AME is using the same settings 4) Might be a possibility, I am a bit of a newbie when it comes to this. Below is the metadata for the original clip in case anything is lost in the cut down version. The cut down version of the clip was created with QuickTime and you can download it here: http://www.bit.st/screenshots/in.mp4 $ ./ffprobe -v error -show_format -show_streams in.mp4 [STREAM] index=0 codec_name=h264 codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 profile=Main codec_type=video codec_time_base=1/50 codec_tag_string=avc1 codec_tag=0x31637661 width=1920 height=1080 coded_width=1920 coded_height=1080 has_b_frames=1 sample_aspect_ratio=1:1 display_aspect_ratio=16:9 pix_fmt=yuv420p level=41 color_range=tv color_space=unknown color_transfer=unknown color_primaries=unknown chroma_location=left field_order=unknown timecode=N/A refs=1 is_avc=true nal_length_size=4 id=N/A r_frame_rate=25/1 avg_frame_rate=25/1 time_base=1/50000 start_pts=0 start_time=0.000000 duration_ts=13934000 duration=278.680000 bit_rate=9798319 max_bit_rate=N/A bits_per_raw_sample=8 nb_frames=6967 nb_read_frames=N/A nb_read_packets=N/A DISPOSITION:default=1 DISPOSITION:dub=0 DISPOSITION:original=0 DISPOSITION:comment=0 DISPOSITION:lyrics=0 DISPOSITION:karaoke=0 DISPOSITION:forced=0 DISPOSITION:hearing_impaired=0 DISPOSITION:visual_impaired=0 DISPOSITION:clean_effects=0 DISPOSITION:attached_pic=0 DISPOSITION:timed_thumbnails=0 TAG:creation_time=2017-03-01T22:53:40.000000Z TAG:language=eng TAG:handler_name=Alias Data Handler TAG:encoder=AVC Coding [/STREAM] [STREAM] index=1 codec_name=aac codec_long_name=AAC (Advanced Audio Coding) profile=LC codec_type=audio codec_time_base=1/48000 codec_tag_string=mp4a codec_tag=0x6134706d sample_fmt=fltp sample_rate=48000 channels=2 channel_layout=stereo bits_per_sample=0 id=N/A r_frame_rate=0/0 avg_frame_rate=0/0 time_base=1/48000 start_pts=0 start_time=0.000000 duration_ts=13376640 duration=278.680000 bit_rate=253386 max_bit_rate=319125 bits_per_raw_sample=N/A nb_frames=13065 nb_read_frames=N/A nb_read_packets=N/A DISPOSITION:default=1 DISPOSITION:dub=0 DISPOSITION:original=0 DISPOSITION:comment=0 DISPOSITION:lyrics=0 DISPOSITION:karaoke=0 DISPOSITION:forced=0 DISPOSITION:hearing_impaired=0 DISPOSITION:visual_impaired=0 DISPOSITION:clean_effects=0 DISPOSITION:attached_pic=0 DISPOSITION:timed_thumbnails=0 TAG:creation_time=2017-03-01T22:53:41.000000Z TAG:language=eng TAG:handler_name=Alias Data Handler [/STREAM] [FORMAT] filename=/Users/dave/in.mp4 nb_streams=2 nb_programs=0 format_name=mov,mp4,m4a,3gp,3g2,mj2 format_long_name=QuickTime / MOV start_time=0.000000 duration=278.719589 size=350280600 bit_rate=10053993 probe_score=100 TAG:major_brand=mp42 TAG:minor_version=0 TAG:compatible_brands=mp42mp41 TAG:creation_time=2017-03-01T22:53:40.000000Z [/FORMAT] /dave.
On 24 Mar 2017, at 11:35 am, chronek <chronek@interia.eu> wrote:
If "ffmpeg -i in.mp4 -acodec pcm_s16le -sws_flags full_chroma_inp+full_chroma_int+accurate_rnd+bitexact -sws_dither none -vcodec prores_ks -profile:v 1 -copytb -1 out.mov" not work as should then there are posibilities (1) you are using old ffmpeg (2) there is bug in ffmpeg decoder what deblock h264 when it shoud not (3) AME is encoding to different settings than prores_ks profile:v 1 (4) theres problem with timestamps and ffmpeg trying sanitize it by blending frames to keep framerate
please provide a small part of your source video for testing
W dniu 2017-03-23 o 19:59, Dave pisze:
ProRes is required because it is going into Final Cut Pro 7.
On 24 Mar 2017, at 2:20 am, chronek <chronek@interia.eu> wrote:
Are you really need prores codec? If you concern quality then use some loseless codec like utvideo...
W dniu 2017-03-23 o 12:43, Dave pisze:
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Hello, Thanks for sample, nah i do not have prores codec and could not encode it with AME, could you tell me what filesize or bitrate you get with AME and that sample? Yes it is somehow blurry that why i want compare bitrate, now was trying: ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1:flags=full_chroma_int -copytb -1 -strict -2 -flags +ildct out.mov W dniu 2017-03-24 o 12:04, Dave pisze:
To answer your suggestions Chronek:
I tried encoding with your suggested command line it was still pretty much the same.
1) I downloaded a fresh copy of ffmpeg and compiled it and still had the same results 2) I am not really in a position to comment on 3) I assure you AME is using the same settings 4) Might be a possibility, I am a bit of a newbie when it comes to this. Below is the metadata for the original clip in case anything is lost in the cut down version.
The cut down version of the clip was created with QuickTime and you can download it here:
W dniu 2017-03-24 o 12:04, Dave pisze:
To answer your suggestions Chronek:
I tried encoding with your suggested command line it was still pretty much the same.
1) I downloaded a fresh copy of ffmpeg and compiled it and still had the same results 2) I am not really in a position to comment on 3) I assure you AME is using the same settings 4) Might be a possibility, I am a bit of a newbie when it comes to this. Below is the metadata for the original clip in case anything is lost in the cut down version.
The cut down version of the clip was created with QuickTime and you can download it here:
http://www.bit.st/screenshots/in.mp <http://www.bit.st/screenshots/in.mp4>
I got a decent result with one of the latest zeranoe builds: ffmpeg -i in.mp4 -c:v prores_ks -profile:v 1 -flags +ilme+ildct -top 1 -vf scale=interl=1 -sws_flags +full_chroma_inp+full_chroma_int -c:a pcm_s16le -ar 48000 -ac 2 dave_proresLT.mov Setting sws_flags just makes a minimal difference. Vendor and vtag don't make any difference at all, except the writing library metadate. Pix_fmt is set automatically. The standard prores encoder is even blurrier than prores_ks, but it's twice as fast on my machine. What's interesting, DNxHD remains just as sharp when using the intermediate bitrate (115/120/145M, 8bpc), in comparison -- so 2 more bpc doesn't automatically give you a "better" result. Erik
Erik Dobberkau wrote:
W dniu 2017-03-24 o 12:04, Dave pisze:
To answer your suggestions Chronek:
I tried encoding with your suggested command line it was still pretty much the same.
1) I downloaded a fresh copy of ffmpeg and compiled it and still had the same results 2) I am not really in a position to comment on 3) I assure you AME is using the same settings 4) Might be a possibility, I am a bit of a newbie when it comes to this. Below is the metadata for the original clip in case anything is lost in the cut down version.
The cut down version of the clip was created with QuickTime and you can download it here:
http://www.bit.st/screenshots/in.mp <http://www.bit.st/screenshots/in.mp4>
I got a decent result with one of the latest zeranoe builds:
ffmpeg -i in.mp4 -c:v prores_ks -profile:v 1 -flags +ilme+ildct -top 1 -vf scale=interl=1 -sws_flags +full_chroma_inp+full_chroma_int -c:a pcm_s16le -ar 48000 -ac 2 dave_proresLT.mov
Setting sws_flags just makes a minimal difference. Vendor and vtag don't make any difference at all, except the writing library metadate. Pix_fmt is set automatically.
The standard prores encoder is even blurrier than prores_ks, but it's twice as fast on my machine. What's interesting, DNxHD remains just as sharp when using the intermediate bitrate (115/120/145M, 8bpc), in comparison -- so 2 more bpc doesn't automatically give you a "better" result.
Haven't had time to look properly just a couple of thoughts. in.mp4 is not too good to start with! Lol at the hat when (guess) the encoder makes the cloth texture appear and does psy so it stays still for a while the hat moves, before disappearing. The screenshots look worse than encoding this test, though it is slightly blurred. What are we looking with? Me a crappy tn panel 8 bit in - but then dithered, more than that, what are we playing with? Me using mpv + opengl so the conversion to rgb for display does preserve the full 10 bit 422. Use another player and you may find that it gets a cheap non interlace aware cludge down back to yuv420p before getting converted to rgb.
Seranoe seems to be windows only? I am testing on a Mac at the moment but the final install will be on a Linux box.
On 25 Mar 2017, at 1:08 am, Erik Dobberkau <erik.dobberkau@gmail.com> wrote:
W dniu 2017-03-24 o 12:04, Dave pisze:
To answer your suggestions Chronek:
I tried encoding with your suggested command line it was still pretty much the same.
1) I downloaded a fresh copy of ffmpeg and compiled it and still had the same results 2) I am not really in a position to comment on 3) I assure you AME is using the same settings 4) Might be a possibility, I am a bit of a newbie when it comes to this. Below is the metadata for the original clip in case anything is lost in the cut down version.
The cut down version of the clip was created with QuickTime and you can download it here:
http://www.bit.st/screenshots/in.mp <http://www.bit.st/screenshots/in.mp> <http://www.bit.st/screenshots/in.mp4 <http://www.bit.st/screenshots/in.mp4>>
I got a decent result with one of the latest zeranoe builds:
ffmpeg -i in.mp4 -c:v prores_ks -profile:v 1 -flags +ilme+ildct -top 1 -vf scale=interl=1 -sws_flags +full_chroma_inp+full_chroma_int -c:a pcm_s16le -ar 48000 -ac 2 dave_proresLT.mov
Setting sws_flags just makes a minimal difference. Vendor and vtag don't make any difference at all, except the writing library metadate. Pix_fmt is set automatically.
The standard prores encoder is even blurrier than prores_ks, but it's twice as fast on my machine. What's interesting, DNxHD remains just as sharp when using the intermediate bitrate (115/120/145M, 8bpc), in comparison -- so 2 more bpc doesn't automatically give you a "better" result.
Erik _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org <mailto:ffmpeg-user@ffmpeg.org> http://ffmpeg.org/mailman/listinfo/ffmpeg-user <http://ffmpeg.org/mailman/listinfo/ffmpeg-user>
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org <mailto:ffmpeg-user-request@ffmpeg.org> with subject "unsubscribe".
On Sat, 25 Mar 2017 10:57:19 +1100 Dave <dave@bit.st> wrote:
Seranoe seems to be windows only? I am testing on a Mac at the moment but the final install will be on a Linux box.
See http://ffmpeg.org/download.html for links to builds for macOS and Linux. Please try to avoid top-posting on this mailing list.
Hi Lou, Sorry I wasn’t trying to top post, just respond to everyone’s questions. I thought it would be easier to read if I responded to them individually. I realise that ffmpeg can be downloaded there. I was referring to Erik’s post where he said that he was using "zeranoe builds” and saw on https://ffmpeg.zeranoe.com/builds/ <https://ffmpeg.zeranoe.com/builds/> there was only space for a Windows download. Anyways I try and respond to everyone’s questions and points in the one email from now on. The full ffmpeg output is: $ ./ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1 -sws_flags full_chroma_inp+full_chroma_int -copytb -1 out.mov ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers built with Apple LLVM version 8.0.0 (clang-800.0.42.1) configuration: libavutil 55. 34.101 / 55. 34.101 libavcodec 57. 64.101 / 57. 64.101 libavformat 57. 56.101 / 57. 56.101 libavdevice 57. 1.100 / 57. 1.100 libavfilter 6. 65.100 / 6. 65.100 libswscale 4. 2.100 / 4. 2.100 libswresample 2. 3.100 / 2. 3.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'in.mp4': Metadata: major_brand : mp42 minor_version : 1 compatible_brands: mp41mp42isom creation_time : 2017-03-24T10:21:26.000000Z Duration: 00:00:20.17, start: -0.002354, bitrate: 10552 kb/s Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv), 1920x1080 [SAR 1:1 DAR 16:9], 9719 kb/s, 23.97 fps, 25 tbr, 50k tbn, 50 tbc (default) Metadata: creation_time : 2017-03-24T10:21:26.000000Z handler_name : Core Media Video encoder : AVC Coding Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 253 kb/s (default) Metadata: creation_time : 2017-03-24T10:21:26.000000Z handler_name : Core Media Audio Output #0, mov, to 'out.mov': Metadata: major_brand : mp42 minor_version : 1 compatible_brands: mp41mp42isom encoder : Lavf57.56.101 Stream #0:0(eng): Video: prores (prores_ks) (apcs / 0x73637061), yuv422p10le, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 12800 tbn, 25 tbc (default) Metadata: creation_time : 2017-03-24T10:21:26.000000Z handler_name : Core Media Video encoder : Lavc57.64.101 prores_ks Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, stereo, s16, 1536 kb/s (default) Metadata: creation_time : 2017-03-24T10:21:26.000000Z handler_name : Core Media Audio encoder : Lavc57.64.101 pcm_s16le Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> prores (prores_ks)) Stream #0:1 -> #0:1 (aac (native) -> pcm_s16le (native)) Press [q] to stop, [?] for help frame= 504 fps=4.8 q=-0.0 Lsize= 218002kB time=00:00:20.18 bitrate=88491.5kbits/s speed=0.192x video:214210kB audio:3784kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.003929% The problem occurs with both the prores and prores_ks codecs and doesn’t occur with Adobe. In the screenshots that I took the image is blown up 300%. In regards to monitors being used 5K iMac, MacBookPro retina, Flanders broadcast monitor and a cheap Samsung 27”.
On 25 Mar 2017, at 11:06 am, Lou <lou@lrcd.com> wrote:
On Sat, 25 Mar 2017 10:57:19 +1100 Dave <dave@bit.st> wrote:
Seranoe seems to be windows only? I am testing on a Mac at the moment but the final install will be on a Linux box.
See http://ffmpeg.org/download.html for links to builds for macOS and Linux.
Please try to avoid top-posting on this mailing list. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
I think reason why you can not get the same result is simple, ame using apple prores, apple codec is closed and patented, ffmpeg prores is opensource community implementation and creates non standard prores files, try increase bitrate (-bits_per_mb 1200) and check if it get good result, if result will be good then it only means that ffmpeg prores have lower encode efficienty and that why is blurred
Dave wrote:
The full ffmpeg output is:
$ ./ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1 -sws_flags full_chroma_inp+full_chroma_int -copytb -1 out.mov
FWIW I tested a bit the format conversion + various flags and the only ones that made the ssim/psnr better 420 -> 422 10 bit and back were accurate_rnd or bitexact, both gave the same score. interl=1 recently got improved, I don't know if that fix is in current release or not. Whatever the flags, there is no softening and the psnr/ssim are high for chroma (exact for luma). So as has been said - try throwing more bits at it. On the face of it going from 10mbit h264 to 80mbit prores may seem plenty, but prores is I frame only. If you look at libh264 stats when encoding you will see that the (normally sparse) I frames are generally 10x the size of the others. I frame compression is "expensive".
Hi, The AME encode of the sample is 209.3MB. Media Info reports the bitrate as 81.3Mbps for the video and 546Kbps for the audio.
On 24 Mar 2017, at 11:53 pm, chronek <chronek@interia.eu> wrote:
Hello,
Thanks for sample, nah i do not have prores codec and could not encode it with AME, could you tell me what filesize or bitrate you get with AME and that sample?
Yes it is somehow blurry that why i want compare bitrate, now was trying: ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1:flags=full_chroma_int -copytb -1 -strict -2 -flags +ildct out.mov
W dniu 2017-03-24 o 12:04, Dave pisze:
To answer your suggestions Chronek:
I tried encoding with your suggested command line it was still pretty much the same.
1) I downloaded a fresh copy of ffmpeg and compiled it and still had the same results 2) I am not really in a position to comment on 3) I assure you AME is using the same settings 4) Might be a possibility, I am a bit of a newbie when it comes to this. Below is the metadata for the original clip in case anything is lost in the cut down version.
The cut down version of the clip was created with QuickTime and you can download it here:
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
ffmpeg -y -i in.mxf -r 25 -vf settb=1/25 -flags +ilme+ildct -timecode 00:00:00:00 -acodec pcm_s16le -filter_complex "[:1:a][:2:a]amerge=inputs=2[aout]" -map "[aout]" -map 0:0 -qscale:v 6 -vcodec prores_ks -profile:v 1 -video_track_timescale 25 -copytb -1 out.mov
This will give you ProRes LT, I suppose this is intended? Do you also generate the same format (i.e. resolution, scan, bitrate/profile) from AME?
MP4 Conversion: ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1 -sws_flags full_chroma_inp+full_chroma_int -copytb -1 out.mov
Same here, and did you test if removing the +full_chroma_int flag made a difference? Erik
2017-03-23 18:12 GMT+01:00 Erik Dobberkau <erik.dobberkau@gmail.com>:
ffmpeg -y -i in.mxf -r 25 -vf settb=1/25 -flags +ilme+ildct -timecode
00:00:00:00 -acodec pcm_s16le -filter_complex "[:1:a][:2:a]amerge=inputs=2[aout]" -map "[aout]" -map 0:0 -qscale:v 6 -vcodec prores_ks -profile:v 1 -video_track_timescale 25 -copytb -1 out.mov
This will give you ProRes LT, I suppose this is intended? Do you also generate the same format (i.e. resolution, scan, bitrate/profile) from AME?
MP4 Conversion: ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1 -sws_flags full_chroma_inp+full_chroma_int -copytb -1 out.mov
Same here, and did you test if removing the +full_chroma_int flag made a difference?
I also wonder if you have to set -pix_fmt yuv422p10le manually, or if the encoder does this automatically...and/or using -vtag apch and/or -vendor ap10 would make a difference.
We still do not know what is his colorspace of input video, if it is only yuv420p then conversion to prores_ks profile:v 1 (yuv422p10) will be losy, not to mention that prores is itself losy, why not use native yuv420p? If you really need change codec why not use utvideo it can loseless yuv420,yuv422,yuv422p10,rgb,rgb10,etc.... or just use avisynth scrypt and load direct to AME... +full_chroma_int flag show that you doing conversion of colorspace W dniu 2017-03-23 o 18:12, Erik Dobberkau pisze:
ffmpeg -y -i in.mxf -r 25 -vf settb=1/25 -flags +ilme+ildct -timecode 00:00:00:00 -acodec pcm_s16le -filter_complex "[:1:a][:2:a]amerge=inputs=2[aout]" -map "[aout]" -map 0:0 -qscale:v 6 -vcodec prores_ks -profile:v 1 -video_track_timescale 25 -copytb -1 out.mov
This will give you ProRes LT, I suppose this is intended? Do you also generate the same format (i.e. resolution, scan, bitrate/profile) from AME?
MP4 Conversion: ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1 -sws_flags full_chroma_inp+full_chroma_int -copytb -1 out.mov
Same here, and did you test if removing the +full_chroma_int flag made a difference?
Erik _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
chronek :
We still do not know what is his colorspace of input video, if it is only yuv420p then conversion to prores_ks profile:v 1 (yuv422p10) will be losy, not to mention that prores is itself losy, why not use native yuv420p? If you really need change codec why not use utvideo it can loseless yuv420,yuv422,yuv422p10,rgb,rgb10,etc.... or just use avisynth scrypt and load direct to AME...
Does it matter? If he's using ProRes as online editing codec at his place, this is the desired (intermediate) format. Of course every conversion is lossy.
+full_chroma_int flag show that you doing conversion of colorspace
Colorspace conversion should not affect sharpness. What I see from the screenshots is a strong interpolation, and I wonder what's causing this (as does Dave, I guess). There's a noticable difference between the AME and the ffmpeg results.
I do not know what for he need prores codec, maybe he not need it.... I did not see previous posts or screenshots... so what is source file container/codec/colorspace/is interlaced? and what is desired container/codec/colorspace and for what he need it? (maybe can be used something else)
Does it matter? If he's using ProRes as online editing codec at his place, this is the desired (intermediate) format. Of course every conversion is lossy.
Colorspace conversion should not affect sharpness. What I see from the screenshots is a strong interpolation, and I wonder what's causing this (as does Dave, I guess). There's a noticable difference between the AME and the ffmpeg results. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On 24 Mar 2017, at 4:12 am, Erik Dobberkau <erik.dobberkau@gmail.com> wrote:
ffmpeg -y -i in.mxf -r 25 -vf settb=1/25 -flags +ilme+ildct -timecode 00:00:00:00 -acodec pcm_s16le -filter_complex "[:1:a][:2:a]amerge=inputs=2[aout]" -map "[aout]" -map 0:0 -qscale:v 6 -vcodec prores_ks -profile:v 1 -video_track_timescale 25 -copytb -1 out.mov
This will give you ProRes LT, I suppose this is intended? Do you also generate the same format (i.e. resolution, scan, bitrate/profile) from AME?
The resolution, scan and bitrate/profile are all the same in AME
MP4 Conversion: ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1 -sws_flags full_chroma_inp+full_chroma_int -copytb -1 out.mov
Same here, and did you test if removing the +full_chroma_int flag made a difference?
Without +full_chroma_int the problem is still just as bad.
Erik _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
2017-03-23 12:43 GMT+01:00 Dave <dave@bit.st>:
ffmpeg -y -i in.mp4 -acodec pcm_s16le -vcodec prores_ks -profile:v 1 -vf scale=interl=1 -sws_flags full_chroma_inp+full_chroma_int -copytb -1 out.mov
Complete, uncut console output missing. Do you see the blurring only with prores_ks or also with the default prores encoder? Do you see the blurring only using the Adobe decoder or also when decoding with FFmpeg? Carl Eugen
2017-03-23 12:43 GMT+01:00 Dave <dave@bit.st>:
ffmpeg -y -i in.mxf -r 25 -vf settb=1/25 -flags +ilme+ildct -timecode 00:00:00:00 -acodec pcm_s16le -filter_complex "[:1:a][:2:a]amerge=inputs=2[aout]" -map "[aout]" -map 0:0 -qscale:v 6 -vcodec prores_ks -profile:v 1 -video_track_timescale 25 -copytb -1 out.mov
Do you see the blurring only using the Adobe decoder or also when decoding with FFmpeg? Doesn't "-profile:v 3" increase the quality? Please remove qscale from your command line, it has no effect on prores encoding. Please find out what "top-posting" means and avoid it here if you request support. Carl Eugen
Do you see the blurring only using the Adobe decoder or also when decoding with FFmpeg?
Doesn't "-profile:v 3" increase the quality? Please remove qscale from your command line, it has no effect on prores encoding.
IIRC the quality of AME was described to be better than ffmpeg's when applying the same parameters (at least the ones that are accessible to the user). Erik
On Mon, Mar 27, 2017 at 10:08:02 +0200, Carl Eugen Hoyos wrote:
Doesn't "-profile:v 3" increase the quality? Please remove qscale from your command line, it has no effect on prores encoding.
From the Wiki: https://trac.ffmpeg.org/wiki/Encode/VFX#Prores
From empirical testing we've found that a qscale of 9 - 13 gives a good result without exploding the space needed too much. The given command lines also use qscale. (I know nothing about prores, so I'm not about to change that Wiki entry. ;-)) Just wondering, Moritz
2017-03-27 12:19 GMT+02:00 Moritz Barsnick <barsnick@gmx.net>:
On Mon, Mar 27, 2017 at 10:08:02 +0200, Carl Eugen Hoyos wrote:
Doesn't "-profile:v 3" increase the quality? Please remove qscale from your command line, it has no effect on prores encoding.
From the Wiki: https://trac.ffmpeg.org/wiki/Encode/VFX#Prores
From empirical testing we've found that a qscale of 9 - 13 gives a good result without exploding the space needed too much.
The given command lines also use qscale.
qscale apparently makes a difference for prores_ks, not for prores. I wonder now if the described issue shouldn't be very different for different values of qscale (and different for prores and prores_ks). Thank you for pointing this out, Carl Eugen
participants (7)
-
Andy Furniss -
Carl Eugen Hoyos -
chronek -
Dave -
Erik Dobberkau -
Lou -
Moritz Barsnick