[FFmpeg-user] DTS-HD copy same with or without dca_core

[sean darcy]

On 12/5/18 3:33 AM, Moritz Barsnick wrote:
> On Wed, Dec 05, 2018 at 00:11:53 +0100, Carl Eugen Hoyos wrote:
>> 2018-12-04 23:24 GMT+01:00, sean darcy <seandarcy2 at gmail.com>:
>>
>>> ffmpeg -i /opt/2T1/video/plex/Movies/Shows/WSS-Dance_t02.mkv -map v -map
>>> 0:1 -bsf:a dca_core -c:a copy -c:v libx265 -crf 26 -preset slower -dn
>>> -sn -nostdin /opt/2T1/video/plex/Movies/Shows/wss-dance-265.mp4
>>
>> Please run "ffmpeg -i wss-dance-265.mp4"
> 
> In other words: You (sean) are trusting the info ffmpeg's muxer is
> printing when creating the file. The actual output file, if you check
> it afterwards, should be DCA Core. (I just tested the bitstream filter,
> it seems to work just fine with the first DTS-HD MA 5.1 48 kHz sample
> from here: https://thedigitaltheater.com/dts-trailers/)
> 
> I assume this is an issue with bitstream filters not modifying stream
> property information, and thus the muxer not knowing about the change.
> For video bitstreams, there is a thread / patchset on ffmpeg-devel
> regarding exactly this:
> 
> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/236990.html
> 
> (And I don't know how to change this in the dca_core bitstream filter,
> though it shouldn't be difficult.)
> 
> In other words: Don't trust ffmpeg's printout when muxing, instead look
> at the resulting file.
> 
> Moritz

Thanks for the heads up.

dca_core did work:

ffmpeg -hide_banner -i wss-dance-265.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'wss-dance-265.mp4':
   Metadata:
     major_brand     : isom
     minor_version   : 512
     compatible_brands: isomiso2mp41
     title           : Dance
     encoder         : Lavf58.22.100
   Duration: 02:52:55.80, start: 0.000000, bitrate: 3231 kb/s
     Chapter #0:0: start 0.000000, end 380.380000
     Metadata:
       title           : Chapter 01
     Chapter #0:1: start 380.380000, end 616.658000
     Metadata:
       title           : Chapter 02
     Chapter #0:2: start 616.658000, end 2129.127000
     Metadata:
       title           : Chapter 03
     Chapter #0:3: start 2129.127000, end 2336.000000
     Metadata:
       title           : Chapter 04
     Chapter #0:4: start 2336.000000, end 2823.362000
     Metadata:
       title           : Chapter 05
     Chapter #0:5: start 2823.362000, end 2953.367000
     Metadata:
       title           : Chapter 06
     Chapter #0:6: start 2953.367000, end 3537.325000
     Metadata:
       title           : Chapter 07
     Chapter #0:7: start 3537.325000, end 3705.744000
     Metadata:
       title           : Chapter 08
     Chapter #0:8: start 3705.744000, end 6836.204000
     Metadata:
       title           : Chapter 09
     Chapter #0:9: start 6836.204000, end 6956.199000
     Metadata:
       title           : Chapter 10
     Chapter #0:10: start 6956.199000, end 7254.998000
     Metadata:
       title           : Chapter 11
     Chapter #0:11: start 7254.998000, end 7366.901000
     Metadata:
       title            : Chapter 12
     Chapter #0:12: start 7366.901000, end 8037.821000
     Metadata:
       title           : Chapter 13
     Chapter #0:13: start 8037.821000, end 8216.875000
     Metadata:
       title           : Chapter 14
     Chapter #0:14: start 8216.875000, end 10375.797000
     Metadata:
       title           : Chapter 15
     Stream #0:0(eng): Video: hevc (Main) (hev1 / 0x31766568), 
yuv420p(tv, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 1712 kb/s, 23.98 
fps, 23.98 tbr, 24k tbn, 23.98 tbc (default)
     Metadata:
       handler_name    : VideoHandler
     Stream #0:1(eng): Audio: dts (DTS) (mp4a / 0x6134706D), 48000 Hz, 
5.1(side), fltp, 1536 kb/s (default)
     Metadata:
       handler_name    : SoundHandler
     Stream #0:2(eng): Data: bin_data (text / 0x74786574)
     Metadata:
       handler_name    : SubtitleHandler
At least one output file must be specified


I looked at the proposed bsf patches on devel. AFAICT, they don't deal 
with the audio bsf's.

Also, with "-map v -map 0:1 -dn -sn" why do I get output Stream #0:2 ?

sean