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 <seandar...@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
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".