[CinCV TNG] cinelerra-gg render bug or feature concerning ffmpeg vfr and cfr

Frederic Roenitz roenitz at aimvis.de
Sat Jul 1 18:31:59 CEST 2017


Thank you very much for your answer ... and the (workaround) fix! :)

I tried cinelerra-gg 5.1.20170629. It's partly working with the old
tv, now.


old tv
======

The "old tv" is a Samsung UE40EH5300 and a little bit younger than it
might have sounded.

I can plug in an usb stick and let the tv play the video from the
stick. The built in player of this tv is, well, let's call it 'picky'.

For the 30.07fps-video, I pressed play, it 'loaded' and said: "The
selected file is not currently supported.". As far as I could see, it
didn't try to play the video, at least it didn't display anything from
the video itself, not even garbage.

So my guess is that it does a couple of 'well intended' (which is IMHO
a bad idea) sanity-checks and blocks at the unknown "fps"-value.

But thanks to you, we no longer have videos with incorrect "fps". :)


'partly'
========

Using the same test scenario as before (start cinelerra, n, select
10seconds, insert video effect: "title" with "Stamp timecode",
render).

After tooo much 'try and error' I found out:

does not work
-------------

1920x1080 using "preset", is *not* played by the old tv when "preset"
is set to:

  slow, slower, veryslow, placebo (yes, I tested it, even if the doc
  says: 'Ignore placebo')


works
-----

1920x1080 using "preset", *is* played by the old tv when "preset"
is set to:

  ultrafast, superfast, veryfast, faster, fast or medium

1920x1080 without "preset", *is* played by the old tv.


1280x720 using "preset", "crf" and/or "g" works!!!



conclusion
==========

1
-

This phenomenon is not directly related to cinelerra-gg.

It's an ffmpeg-and-old-tv-thing.

If anyone has some details about the ffmpeg-preset details, especially
what details do change from 'medium' to 'slow', please share.


2
-

If you want maximum compatibility, don't use ffmpeg-presets 'slow' and
below (this rhymes).

ffmpeg-presets 'medium' and faster are probably ok.



Have a good one :)

Frederic


Good Guy wrote on 29.06.2017 03:32:
> First, thank you for reporting any anomalies.
> Second, sorry for the delayed reply, but Phyllis was out of town.
>    Without her help, things go to hell in a hand basket.
> Third, your extensive information when reporting is much appreciated.
>
> "Where has the "File Format: Quicktime for Linux" in cinelerra-gg gone?"
>
> I am answering the last question first!  Quicktime for Linux seems to be problematic.  The original author, Adam, was an expert at Quicktime, but my expertise lies in other areas and I have had little experience with Quicktime.  I did upgrade it extensively, but as I reworked it, I came to the conclusion that it was just too much risk, and was widely replaceable with ffmpeg.  The ffmpeg group has a lot of developers and I assumed that the diversity of that team would be able to duplicate the Quicktime for Linux that was in the original Cinelerra HV version and cover it well.  However, Phyllis has seen a few forums that seem to indicate that users still prefer using the Cinelerra HV version and the ffmpeg version is lacking. *If the users report exact reasons/samples of how ffmpeg falls short, we could possibly fill in the gaps with the cinelerra-gg *version so no one would miss the original Quicktime for Linux.
>
> "The "30.07 fps" changes depending on the render range in the
> cinelerra-gg timeline: For example using a longer range gives
> "30.20 fps" or "34.07 fps" ...
> ...
> So, what is going on?"
>
> Now for why I answered the last question first -- what is going on in ffmpeg?  Good question.  As far as I can tell, there is a bug in the construction of the STTS table of the quicktime header.  It holds frame numbers and frame durations used to maintain the position information for the video media.  If you turn on verbose logging, you can see it creates a bogus zero duration entry.  This seems to be because the encoder does not calculate the duration of the last frame correctly.  This cascades to create the error you report.  The "bug" is that the number of frame times is 1 less than it should be, so depending on the time duration, instead of (for example) 300 frames divided by the time duration, the code used 1 less or 299.  This is why you might get 30.07 or 34.07 or whatever depending on the length of your video rather than the correct 29.97 with ffprobe.  You would see, however, if in the cinelerra Resources window, if you view with "info" the output of your render
> (such as the one you generated with the .mp4 extension), the Codec correctly reports 29.97.
>
> However, I have created a workaround "fix" that will be promoted with the new builds which will be done in the next couple of days.  Although, I have tested it and it performs much better for me than previously, I would appreciate it very much if you test it to make sure it works for you in other cases.
>
> I have an old tv I use for compatibility testing.
>
> On another note, I would not expect the incorrect reporting of the "fps" to create a problem for an old TV.  So if the revised code "fps" correction still creates a problem for this TV, further looking may be required.  We are not sure what the definition of an "old TV" is, but we still have what used to be an analog tv and Phyllis is constantly using it to test dvds created with cinelerra.  It is doubtful, that we would be able to generate the same error you have though.
>
> GG/Phyllis
>
> On Sun, Jun 25, 2017 at 4:37 AM, Frederic Roenitz <roenitz at aimvis.de <mailto:roenitz at aimvis.de>> wrote:
>
>     Hello and thank you very much for all your time and effort you put
>     into cinelerra! :)
>
>     I'm giving cinelerra-gg a try and have a question about the render
>     output when using FFMPEG.
>
>     cinelerra-gg version: 1:5.1.20170531 on Debian 8.8 via deb
>     https://cinelerra-cv.org/five/pkgs/debian <https://cinelerra-cv.org/five/pkgs/debian> jessie main
>
>
>     When rendering with file format FFMPEG (arbitrary container and
>     codec), ffprobe shows the following for the resulting file (full
>     output see below):
>
>       30.07 fps, 29.97 tbr, 360k tbn, 59.94 tbc (default)
>
>     I expected:
>
>       29.97 fps, 29.97 tbr, 360k tbn, 59.94 tbc (default)
>
>     The "30.07 fps" changes depending on the render range in the
>     cinelerra-gg timeline: For example using a longer range gives
>     "30.20 fps" or "34.07 fps" ...
>
>
>     I have an old tv I use for compatibility testing. If it plays the
>     video, almost every other player plays the video.  Well, it doesn't
>     want to play those videos (most of the time ...).
>
>     mpv, vlc, xine play the file.
>
>
>     My first guess was, that cinelerra-gg rendered the file with variable
>     frame rate (vfr) and not constant frame rate (cfr).
>
>     So for x264 and x265 at Shift-R -> "Video:"-wrench -> "Video Options",
>     I tried things like "vsync cfr" and "r 29.97" and the syntax-variants
>     with and without "=" and for the "x264opts", too. All of these had no
>     effect.
>
>     Other parameters work, for example for x264, I use:
>     preset=slower
>     crf=23
>     g=60
>
>
>     Maybe "-vsync 2" or "-vsync vfr" (synonymous) is hardcoded somewhere
>     in cinelerra-gg? Or it's something with the timebase handling for
>     the frame rate?
>     ...
>
>     ...
>     So, what is going on?
>
>     Please help!
>
>
>     By the way:
>
>     Where has the "File Format: Quicktime for Linux" in cinelerra-gg gone?
>
>
>     Thank you
>
>     Frederic
>
>
>
> _______________________________________________
> Cinelerra mailing list
> Cinelerra at lists.cinelerra-cv.org
> http://lists.cinelerra-cv.org/cgi-bin/mailman/listinfo/cinelerra


More information about the Cinelerra mailing list