Digamos que tengo un archivo de audio que se está decodificando con ffmpeg . El formato de origen es algo así como AAC , donde el audio se divide en paquetes. Cuando se busca un tiempo en particular, está claro que el tiempo no caerá, la mayoría de las veces, en el borde del paquete sino en algún lugar dentro de la duración del paquete. ¿Tengo que buscar dentro del paquete yo mismo o av_seek_frame lo hace todo por sí mismo y configura la decodificación para que el siguiente cuadro decodificado comience en la posición que he solicitado?
Si utilizo la función av_seek_frame con el indicador AVSEEK_FLAG_BACKWARD , asumo que el próximo paquete devuelto por av_read_frame será el paquete que contenga la posición de tiempo que busco. ¿Está bien?
Si decodifico este paquete con avcodec_decode_audio4 , ¿el cuadro devuelto contendrá los datos de audio en el momento de inicio del paquete o desde el momento en que pasé a av_seek_frame ? En el último caso, ¿cómo puedo averiguar la marca de tiempo del cuadro/paquete para estimar la cantidad de muestras que se omitirán en el cuadro decodificado? El PTS después de la búsqueda es cero y el DTS tampoco parece útil.
¿Es posible buscar con precisión un momento determinado usando ffmpeg ?
No hay búsqueda exacta de cuadro o muestra de audio en ffmpeg, eso es un problema de nivel de aplicación. La razón es bastante simple: libavformat realiza la búsqueda y no sabe qué hay dentro de los paquetes que devuelven los demuxers individuales. Solo tiene una gota de datos con marca de tiempo X y duración Y. No sabe nada sobre esos datos, tendría que decodificar los datos para hacer algo significativo con ellos, que es libavcodec, no libvformat.
Entonces, para responder a sus preguntas: av_seek_frame busca los límites del paquete, AVSEEK_FLAG_BACKWARD significa que el paquete estará estrictamente antes del ts dado; para el audio, eso significa que lo más probable es que el paquete contenga su marca de tiempo. Sin embargo, este no es siempre el caso, porque algunos demuxers buscan en función de un índice, y no todos los paquetes pueden tener una entrada de índice. Es posible que deba llamar a av_read_frame() varias veces antes de llegar al paquete que contiene su marca de tiempo especificada después de la búsqueda.
Aparte de llamar a avcodec_flush(), libavcodec no sabe nada acerca de la búsqueda, por lo que la salida de la siguiente llamada a avcodec_decode_audio4 comenzará al comienzo del paquete de entrada. Para la búsqueda de muestras específicas, las aplicaciones tienen que cortar las muestras principales por sí mismas.
Sí, el código fuente confirma que av_seek_frame busca hasta los límites del paquete.
Para buscar dentro de los paquetes, uso AVStream::cur_dts timestamp, que av_seek_frame actualiza para indicar el límite que ha buscado. Con ese valor, uno puede averiguar el número restante de muestras para omitir dentro del paquete. Eso resuelve el problema.