>Since you add an option in a later patch: Can you explain the >reasoning for the whole patchset better? >If DolbyE can be auto-detected (I assume so), this should be >done and no further option should be needed. > >Carl Eugen
A common use case is stream copying : you want to be able to forward the input dolbyE to the output. But the mxf mux, for example, does not support dolby_e (up to now). In the future, if we come to support muxing dolby_e in s337m, then yes, that would be nice, we would be able to remux a dolby_e and fix its position/guard band, that would be a very interesting repairing workflow, but that would require much hard work (DolbyE recommanded position is dependant on video raster etc.). Second thing is that, even if we were able to support stream copying, the fact is that users have tons of script like this : ffmpeg -i input.mxf -vcodec copy output.mxf I mean broadcasters are often missing the "audio codec copy" parameter because they think "my audio is uncompressed 16 bits, stream copying is bitexact the same as transcoding". I am afraid I have myself many scripts like this... So, it is necessary to default to not-probe/decode dolby_e to not break scripts. And most of the time, the fact is that users just want to pass trough the data as they indeed need to be agnostic. This was the reason to choose to 1) add an AVOption, and 2) makes it default to disabled Nicolas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
