[FFmpeg-trac] #9846(ffmpeg:new): DNxHR doesn't work with LB in Shutter Encoder

[FFmpeg]

#9846: DNxHR doesn't work with LB in Shutter Encoder
--------------------------------------+----------------------------------
             Reporter:  Soto Soto     |                    Owner:  (none)
                 Type:  defect        |                   Status:  new
             Priority:  normal        |                Component:  ffmpeg
              Version:  unspecified   |               Resolution:
             Keywords:  ffmpeg dnxhr  |               Blocked By:
             Blocking:                |  Reproduced by developer:  0
Analyzed by developer:  0             |
--------------------------------------+----------------------------------
Comment (by Soto Soto):

 Replying to [comment:1 mkver]:
 > 1. The component that you selected is ffmpeg. Here, this means the
 ffmpeg commandline tool (as opposed to Shutter Encoder using the
 libavcodec library on its own) and not the FFmpeg project. Are you sure
 that Shutter Encoder uses the ffmpeg tool instead of the libavcodec
 library?
 According to Paul Pacifico, the developer of Shutter Encoder, FFmpeg is
 the backend of their software. I contacted Paul through reddit and
 redirected me here. This is the link to my conversation with Paul:
 [https://www.reddit.com/r/shutterencoder/comments/w6m85d/comment/ihh3obk]
 > 2. If so, then you can somehow forward the actually used command line to
 us? (Is it more than just "-c:v dnxhd -profile:v dnxhr_lb"?)
 According to Shutter Encoder's console window, I saved a text from the
 last time I did the render and it seems that the command is (redacted file
 outputs and changed file names for this example):
 {{{
 -threads 0 -hwaccel none -i "[REDACTED]\clip.mp4" -c:v dnxhd -profile:v
 dnxhr_lb -pix_fmt yuv422p -filter_complex
 "[0:v]scale=480:270:force_original_aspect_ratio=decrease,pad=480:270:(ow-
 iw)*0.5:(oh-ih)*0.5" -map "[out]" -c:a pcm_s161e -ar 48000 -map a?
 -sws_flags bicubic -metadata
 creation_time="2022-07-23T22:16:59.922821300Z" -y
 "[REDACTED]\clip_Proxy.mov"
 }}}
 There's more to this but it may be too much to put in here so I'll link it
 here[https://imgur.com/a/aemeRYb]
 > 3. Furthermore, we will also need the input file (or any file) to
 actually reproduce the problem. Given that DNXHD is an intra-only codec,
 it should be enough to send the part of the file that actually contains
 the packet that is decoded to the frame whose encoding triggers the
 assert.
 I can provide another file I just recorded, tested with Shutter Encoder
 and still drops the error. NOTE: this link will expire in two days.
 [https://we.tl/t-fxYATPx84B]
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9846#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker