@willifan: I can imagine that ffmpeg makes a false assumption about the usage of 16-235 values in the input, as it seems to be a common thing for yuv420 media files.

But if you use "in_rage=full:out_range=full", that should be fine with material recorded in the 0-255 value range. I don't know whether ProRes is in any regard expecting levels to be not using the full scale. You could try to use "in_range=full:out_range=mpeg" and see if that helps.

On the timecode issue: Can you relay us what ffmpeg (or ffprobe) tells about that "data stream"? Also, I see that you kept "-map 0" out of your above scripts - but it might be that ffmpeg does not map data stream into the output by default. Please try with "-map 0" before the output file name.

If the ffmpeg output contains information on what stream those timecodes are, you could also use an explicit mapping, like "-map "0:2" to map the third stream of the first into the output...

(And btw.: I do not have an orginal GH4 .MTS file to test with. Panasonic missed their chance to sell me one before my last field trip, so now I wait until more than one dealer has the GH4 on stock, which is usually the time when prices fall.)

@LPowell: Yes, ffmpeg does read the "full range flag", at least since this change from January 2010.

But if you search for it on the WWW, you'll find plenty of reports where people complain that one or the other input file conveys wrong information in this flag - especially digital cameras. A very comprehensive description of the issue and experiments with NLE software are described here.

@karl - From the linked article:

"I’d hazard a guess that even 32bit precision RGB processing would still start from what the codec provides and if the first thing the codec does after decompression is squeeze luma the damage is already done."

Sounds like the author doesn't understand the nature of 32-bit floating point RGB color space. The first thing an H.264 decoder does is decompress the file into 8-bit YUV format, whose luma scale is always 16-235. The next thing done is to convert the YUV components into RGB color space, scaled according to how the Full Range Flag is set. When this is done in 32-bit floating point mode, there is more than enough precision available to avoid perceptible image degradation, regardless of whether the data is scaled as Full Range or Studio Swing.

@karl: you are right, using "-c:d copy -map 0" it work.;)
Really sorry, I tried a lot of combination but not this one... i think that the timecode in the audio track is not important. The file prores now work in Premiere and I can see the timecode.
Now I want fix the clipping problem over 235 - you can see what I mean comparing the original with converted with some video waveform monitor. In my example there are some "spike" over 235 ultra white, clipped on the converted file. Difference is negligible anyway.
Many thanks

What about using ffmbc? I read over there that is better handling the correct input/outputs and handling these conversions.

I experimented a different approach, "evolution" of the first karl script. Instead of scaling to 4K color components u and v, then rescale to 2K all together, I did exactly as in the first karl script, but adding an "scale" operation for f u and v which in reality does nothing but solves the problem of wrong merge , probably because the "scale" copy plans u and v in an array 32-bit, homogeneous with the floor Y.
The script is slightly faster, and I think in this way there is less risk that the color components are modified in some way. The script is the follow:
"C:\Program Files\ffmpeg\bin\ffmpeg.exe" -i "input.MOV" -filter_complex "extractplanes=y+u+v[y][u][v]; [y] scale=w=iw/2:h=1080:in_range=full:flags=print_info+bicubic+bitexact [ys]; [u] scale=w=iw1:h=1080:in_range=full:flags=print_info+neighbor+bitexact [us];[v] scale=w=iw1:h=1080:in_range=full:flags=print_info+neighbor+bitexact [vs]; [ys][us][vs]mergeplanes=0x001020:yuv444p,format=pix_fmts=yuv444p10le" -sws_dither none -q 0 -quant_mat hq -c:v prores_ks -profile:v 4 -c:a copy -c:s copy -c:d copy -map 0 "E:\temp\output.mov"
or,
ffmpeg -i "$1" \ -filter_complex 'extractplanes=y+u+v[y][u][v]; [y] scale=w=iw/2:h=1080:in_range=full:flags=print_info+bicubic+bitexact [ys]; [u] scale=w=iw1:h=1080:in_range=full:flags=print_info+neighbor+bitexact [us]; [v] scale=w=iw1:h=1080:in_range=full:flags=print_info+neighbor+bitexact [vs]; [ys][us][vs]mergeplanes=0x001020:yuv444p,format=pix_fmts=yuv444p10le' \ -sws_dither none \ -q 0 -quant_mat hq \ -c:v prores_ks -profile:v 4 \ -c:a copy \ -c:s copy \ -c:d copy \ -map 0 \ "$1_2k_ProRes4444.mov"
any feedback is welcome.

@maxr: sorry, I use windows and not mac or unix...
There was an error in the unix script, please try now, I modified my post.

@karl: may be you are right. I don't know how work "scale" filter in ffmeg, my assumption was that it work always in a 32 bit array, and it will be re-formatted when cast in to the output. I have no tools for check it...

Have you guys tried the Thomas Worth technique? http://www.eoshd.com/comments/topic/5426-mac-app-to-resample-gh4-8-bit-420-to-10-bit-444/ the luma channel becomes a real 10bit here's 2 frames to compare I simply cranked the mids...look at the sky Any chances we can get as good with ffmpeg?

@Karl Thanks for the help! really appreciate but even with your script, i still have a crash am i doing something wrong?

Getting back to the topic at hand...try free gopro cineform ! You know ...it's like a drag-and-drop easily installed already running application, not to be facetious but when this world already has alot of problems...why invent new ones !

@LPowell

This is a topic dedicated solely for any kind of progress updates on software, code and methods to downscale 4k with best possible results to help people establish a workflow for converting 4k footage.

...looks like the topic is all inclusive....but many people will prefer off the shelf solutions in contrast to writing code !

@schprox: I think the differences you are seeing are not actually caused by ffmpeg and Thomas' software doing anything different with regards to averaging each 4 adjacent luma pixels - if that was the case, we should expect to see most differences in mid-tones, not in the highlights of the image.

I think what you see is the difference of using (logarithmic) DPX as an output format versus using ProRes.

If you want more comparable results, instruct ffmpeg to also output to individual DPX images:

ffmpeg -i "input.mp4" -filter_complex "extractplanes=y+u+v[y][u][v]; [u] scale=w=3840:h=2160:flags=print_info+neighbor+bitexact [us]; [v] scale=w=3840:h=2160:flags=print_info+neighbor+bitexact [vs]; [y][us][vs]mergeplanes=0x001020:yuv444p,format=pix_fmts=yuv444p10le,scale=w=1920:h=1080:flags=print_info+bicubic+full_chroma_inp+full_chroma_int" -sws_dither none  -q 0 -map 0 "output%05d.dpx"

(Notice the pattern "%05d" in the output name is relevant as ffmpeg will need to write one output image file per frame.)