Le septidi 7 floréal, an CCXXI, Stefano Sabatini a écrit : > There are a few filters which allow to collect data about a stream, > see ebur128 and the astats filter currently reviewed. The problem with > a two-steps process is that we didn't yet designed a mechanism to pass > global data (data collected at the end of the stream processing) to > the outside, right now we log it which may or may not be an optimal > way to send information around. Help in this area is welcome.
I believe it may be possible to handle things with very few changes to the
framework, only specialized filters.
The problem with multi-pass filters is it requires the decoded data twice,
and decoded data is huge, too huge to be kept in memory. If we trust the
surrounding application to provide the same data twice, that is not a
problem.
Consider the following, imagined, ffmpeg command:
ffmpeg -i music.flac -i music.flac -lavfi "
[0:a]
ebur128=metadata=1,
ascript=frame='l=metadata(\"lavfi.r128.I\") :
eof='sendcmd(\"volnorm\", \"set_volume\", l);
sendcmd(\"startstop\", \"start\")'
[dummy] ;
[1:a] startstop=start=0, volnorm [out]" \
-map "[dummy]" -f null - \
-map "[out]" music_normalized.flac
The startstop filter would just return EAGAIN until it gets the "start"
command. The dummy output could be replaced by a nullsink, but I am not sure
ffmpeg is at ease with sinks right now.
Regarding the export of data collected during the run, an extension of the
ffmetadata may be a simple short term solution.
Also, maybe we should consider moving the writers API from ffprobe to lavu.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
