On Wed, Dec 05, 2018 at 00:11:53 +0100, Carl Eugen Hoyos wrote: > 2018-12-04 23:24 GMT+01:00, sean darcy <[email protected]>: > > > 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 _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
