True if one works with ffmpeg 8, "mid stream changes", is a topic. not sure if we already have a ffastrans release with ffmpeg 8.
On the downside using the AV decoder reads the whole input file before the transcode process starts. So its the first thing to get rid of, when looking for more speed.
Depending on the settings, e.g. full decode, it also Pre encodea the whole source file into the cache folder, so you need a big cache for it to work.Depending on the source, it can also add audio channels that are not in the original.
Custom FFmpeg Encoding Error - Unsupported input (Error number -129 occurred)
Re: Custom FFmpeg Encoding Error - Unsupported input (Error number -129 occurred)
emcodem, wrapping since 2009 you got the rhyme?
Re: Custom FFmpeg Encoding Error - Unsupported input (Error number -129 occurred)
Yep, I would definitely suggest setting it to "No Decode" so that the indexer is invoked without any lossless caching.
About indexing, you know my stance on it, better safe than sorry hahahahahahahahahahahaha
You trust suppliers, I don't XD
Jokes aside, I know you know it but I'll write it down here for other users to reference: in FFAStrans 1.4.1.22 Stable (i.e the latest publicly available stable) we're including ffmpeg version N-118054-gf99fbbf6fb which is based on FFMpeg 7.x. It's not one of the tagged releases, but rather something between FFmpeg 7.0 "Dijkstra" and FFmpeg 7.1 "Péter". This is because we don't simply compile FFMpeg straight out of the source and include it as-is but rather we include some of the patches that were submitted but that never got merged for a reason or the other (like the DolbyED2 decoding ones etc). Unlike FFMpeg 6.1.1 which is the one the previous version was based on, in FFMpeg 7.x we do have the concept of dynamic frame properties, however when the filtergraph is built and those are passed through, the likeliness of the encode actually crashing is high 'cause the overwhelming majority of filters don't actually support them. This is why, when working on 1.4.2 (yes, it's a thing, it's not a mythical creature, it will come, people, we promise) we included -reinit_filter 0 in every step of the chain, from the full decoding to every single encoding node. What it does it essentially force the frame properties to stay constant by being initialized at the very beginning and never changing.
For those asking "why are frame properties changing within a bitstream", that's a very good question. Dynamic frame properties were supposed to be there for HDR, in particular if you have an HDR10+ source in PQ and you have dynamically changing metadata specifying the nits. Unlike the old clip properties (which were constant per clip and were read at the very beginning), frame properties are - as the name says - per frame and they can change on a frame by frame basis. This was to allow things like better scene adaptive tonemapping (similar to what libplacebo does in MPV) and so on. In an SDR BT709 stream, they don't make much sense, but here's the thing: they can happen. Suppose you have a bunch of feeds you recorded from several different sources like LiveU backpacks with journalists doing stand ups or some other files sent from somewhere else etc and all of those are in AVID Interplay and they're all, let's say, AVC Intra Class 100. You crate your sequence in AVID Media Composer and trigger the export. What AVID does, instead of re-encoding the entire thing, is looking at the scenes in which you've put an effect like a fade or in which you did some color correction or you've put some text etc and it will only re-encode that bit while appending the rest, which is why if the original files had different properties within one another you might end up with dynamically changing frame properties within the raw_video.h264 bitstream which is of course a problem.
About indexing, you know my stance on it, better safe than sorry hahahahahahahahahahahaha
You trust suppliers, I don't XD
Jokes aside, I know you know it but I'll write it down here for other users to reference: in FFAStrans 1.4.1.22 Stable (i.e the latest publicly available stable) we're including ffmpeg version N-118054-gf99fbbf6fb which is based on FFMpeg 7.x. It's not one of the tagged releases, but rather something between FFmpeg 7.0 "Dijkstra" and FFmpeg 7.1 "Péter". This is because we don't simply compile FFMpeg straight out of the source and include it as-is but rather we include some of the patches that were submitted but that never got merged for a reason or the other (like the DolbyED2 decoding ones etc). Unlike FFMpeg 6.1.1 which is the one the previous version was based on, in FFMpeg 7.x we do have the concept of dynamic frame properties, however when the filtergraph is built and those are passed through, the likeliness of the encode actually crashing is high 'cause the overwhelming majority of filters don't actually support them. This is why, when working on 1.4.2 (yes, it's a thing, it's not a mythical creature, it will come, people, we promise) we included -reinit_filter 0 in every step of the chain, from the full decoding to every single encoding node. What it does it essentially force the frame properties to stay constant by being initialized at the very beginning and never changing.
For those asking "why are frame properties changing within a bitstream", that's a very good question. Dynamic frame properties were supposed to be there for HDR, in particular if you have an HDR10+ source in PQ and you have dynamically changing metadata specifying the nits. Unlike the old clip properties (which were constant per clip and were read at the very beginning), frame properties are - as the name says - per frame and they can change on a frame by frame basis. This was to allow things like better scene adaptive tonemapping (similar to what libplacebo does in MPV) and so on. In an SDR BT709 stream, they don't make much sense, but here's the thing: they can happen. Suppose you have a bunch of feeds you recorded from several different sources like LiveU backpacks with journalists doing stand ups or some other files sent from somewhere else etc and all of those are in AVID Interplay and they're all, let's say, AVC Intra Class 100. You crate your sequence in AVID Media Composer and trigger the export. What AVID does, instead of re-encoding the entire thing, is looking at the scenes in which you've put an effect like a fade or in which you did some color correction or you've put some text etc and it will only re-encode that bit while appending the rest, which is why if the original files had different properties within one another you might end up with dynamically changing frame properties within the raw_video.h264 bitstream which is of course a problem.