I think I don't have enough knowledge to understand what you wrote. "Blacks", "12", "0", "whites", "255"... I'm sorry. Are you talking about analizing color depth? Which is the unit of measurement? Which instrument/software do you use?
Anyway, thanks a lot for posting.
Ignazio

@lordofthestrings, yellow is (afaik?) referring to Luminance. 0 = black, 255 = white.

What do you mean with «unplayable»? Here it was slow, but it worked, in contrast to the ogv file. The bitrate is not fixed but varying; Like if you zip some files: Zipping 5 MB text files may result in 100 kB, zipping 5 MB video may still be 4.9 MB. Same with the input video; if only very few things change, the bitrate is low, otherwise it is high.

2 pass rendering, by the way, looks at your file in the first pass, and then renders it in the second pass. Here it uses data gathered from the first pass to decide when to use high bitrate and when to use low bitrate. The average bit rate stays the same, but it is lower e.g. for a simple text clip and higher for something moving, so you gain quality, moving the bitrate to where it is really needed.

Your out of sync problem is strange. About long or short clips: When exactly is the audio out of sync? On the whole clip or only towards the end? The latter would make sense if someone, e.g. ffmpeg, thought the audio would run a tiny bit faster than the video. And would require a bug report at the appropriate place.

@yellow I've been talking to some ffmpeg guys recently which told me that FFV1 were absolutely lossless. Output is mathematically identical to the input. It also supports different color spaces, so no loss there either.


(PS: Everything without guarantee, just what I think to know)

You're right there is no stretching of luma. ('Luminance' being a linear light principle, 'Luma' being a gamma encoded video space one) :-)

http://poynton.com/papers/YUV_and_luminance_harmful.html


The stretching I saw was from a lowsy decoder. Thanks for the extra FFV info, I'll check it out, certainly a struggle to playback but to be expected, colour spaces, I wonder if RGB is available?


Sorry to add unnecessarily to this thread Granjow & lordofthestrings, my query does not relate to your A/V problems.

Are you kidding? Informations and knowledge are always welcome!
Ignazio

@yellow
I've read him as well. Well, at least partially, lots of other things to do right now :)
Regarding Luma vs Luminance, how do I know whether my input is already gamma corrected for the human eye? Is this just a standard behaviour? That's a question to which I couldn't (yet) find an answer in Poynton's papers.

And yes, should be RGB available as well in FFV1. Playback is slow sometimes, especially for seeking, but it worked here :)

Granjow

Hey Dan,
I think I found something interesting about this problem.
If I use the batch transcode tool (which calls ffmpeg) I get this A/V sync issue but when I put the HDV .m2t file on the timeline and then render to DNxHD I get perfect sync!
So, correct me if I'm wrong, rendering is done by MLT, right? Why the heck MLT does a perfect rendering and ffmpeg gives this very annoying issues?
Anyway, I'm really happy I solved my problem, but now, if possible, I'd like to find a way to batch render all the clips separately with MLT. Is there a way to do it? I'm not a power user but I'm sure I can handle a shell command line to do this.
Thanks a lot and sorry for my english,
Ignazio

@lordofthestrings:

Which transcoding profile do you choose, there are several one available depending on frame frate,..

For me, the DNxHD RENDERING profile is (to see rendering profile args, click on the small (i) icon:
s=1920x1080 aspect=@16/9 b=220000k vcodec=dnxhd acodec=pcm_s16le

The DNxHd TRANSCODING profile is like:
-s 1920x1080 -r pal -flags +ilme+ildct -b 185000k -threads 2 -vcodec dnxhd -acodec copy %1.mov

You can see that rendering profile encodes audio to pcm_s16le, while the transcoding profile copies the original audio. Maybe that causes the problem.
When using the transcode feature, you can edit the FFmpeg parameters, so maybe try to change them to look closer to the rendering profile (add acodec=pcm_s16le ).
Just make sure to leave the %1.mov at the end of the encoding options.

Thanks for the quick reply.
I'm in PAL land and my source files are HDV ".m2t" interlaced. So, when transcoding I use:

-s 1920x1080 -r pal -top -1 -flags +ilme+ildct -b 185000k -threads 2 -vcodec dnxhd -acodec copy %1.mov

The rendering profile is:

-s 1920x1080 -r pal -top -1 -flags +ilme+ildct -b 185000k -threads 2 -vcodec dnxhd -acodec copy %1.mov

I've tried your suggestion (adding acodec pcm_s16le) but no luck, still the same sync issues...

MLT has a different way of trying to do A/V sync using avformat/avcodec libs than ffmpeg utility. ffmpeg has a few sync options, each with different values that I think only one may know or really understand by reading source of ffmpeg.c. Probably one of those more closely matches MLT behaviour, but I do not know. :-) Furthermore, I would not trust much info you can find on the net about these because they are likely very specific to ffmpeg version and certain file types and files. So, to use an equivalent melt to transcode:

melt input.mts -profile atsc_1080i_50 -consumer avformat:output.mov b=185000k threads=2 vcodec=dnxhd acodec= pcm_s16le

Thank you so much, I will try it tonight when I'll be at home, I hope it works!

I tried but no luck... Looks like there's something wrong in the command... I tried "acodec= pcm_s16le", "acodec=pcm_s16le" and "acodec pcm_s16le". The result is always the same, here attached.

I think I'll wait for the release of Maverik with an updated ffmpeg version. All in all, I'll have to wait just another month :-)

It seems that version 0.7.8 solved my problem. Now my transcoded files are Ok.
It was worth waiting, Kdenlive is fantastic, stable and full of features.
Thank you, Dan, for your contribution.
Ignazio