[FFmpeg-trac] #7055(undetermined:new): Using decimate allows EIA-608 captions to pass through to MP4 files even when the -sn option is used

[FFmpeg]

#7055: Using decimate allows EIA-608 captions to pass through to MP4 files even
when the -sn option is used
-------------------------------------+-------------------------------------
             Reporter:  navilor      |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  unspecified  |  undetermined
             Keywords:  decimate cc  |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by navilor):

 > Why? Do you believe it is a good idea to use a de-interlacer for the
 inverse telecine process? (It usually is not a good idea because it
 permanently damages your video while the inverse telecine process should
 be lossless.)

 The output of the file can have some interlacing artifacts. The same thing
 happens with pullup. I added yadif only after I found interlacing
 artifacts in the output file.

 > Sorry for being unclear: If -r is needed (it should not but this likely
 an effect of using decimate incorrectly), the correct syntax would be -r
 24000/1001.
 Please try to simplify the command line and please provide command line
 including complete, uncut console output to make this a valid ticket.

 Thank you for the clarification. I will update my script accordingly

 I have been in the streaming media industry for ten years. The reason the
 command line structure is like that is that streaming media requires a few
 things.

 1) Constant frame rate.
 2) A perfect GOP.
 3) A bitrate based encode.

 Things that are nice to have are.
 4) Finding a better bitrate for your content.
 5) Hitting your target bitrate.
 6) Audio encoding without A/V drift.
 7) Proper encoding for your target audiences.

 In the end my content has perfect PTS/DTS time stamps, an exact GOP, the
 audio and video do not drift, and the bitrate is precise based off of a
 CRF 23 encode where the "bitrate" is extracted via FFprobe for two pass
 average bitrate encoding.

 I detail the reasoning for my command line structure in my personal blog.
 Effectively I cannot trust that the content that is provided to me is
 clean and will convert nicely. One of my posts on my blog is featured in
 an article by Jan Ozer. It is also referenced in his book Video Encoding
 by the Numbers in Chapter 7: Choosing Data Rate.

 [https://videoblerg.wordpress.com/2017/11/10/ffmpeg-and-how-to-use-it-
 wrong/]

 I have, over time, created a 1,600 line heavily documented bash shell
 script that analyzes incoming content and creates a command line that will
 compensate for most forms of bad content.

 I will work on simplifying the command line and hope to have a reply with
 one soon.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/7055#comment:9>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker