FranceBB
25th August 2022, 17:37
Hi there,
as you know at work we're largely based on Avisynth and ever since the introduction of frame properties I tried not to use them at all 'cause I hated them.
Unfortunately, we live in a democracy, so my colleagues voted in favor of frame properties and I've been outnumbered / outvoted, so now I must support them.
Before this whole madness, I used to use propclearall() right after indexing and call it a day, but now I can't do that.
So, the guys at the end of the filter-chain now expect frame properties to be populated all the time no matter what, so I came up with the following approach:
if there are NO frame properties, I try to use some of the clip properties to assume frame properties (but it's largely based on guess-work) while if I have SOME frame properties, I'll preserve those but I'll also try to see whether I have all the ones I need and I will fill the gap either by using what I've got as frame properties OR by using the same guess-work I would have used if I didn't have anything in the first place.
The result of this is a series of conditional and try-catch statement that try to prevent the function from erroring out.
Before I show you the whole thing, a remark: even though it's here, I made this only for our own internal use cases in the supply chain, therefore you'll see that the interlacing check doesn't really make sense for a normal user. This is because technically in Avisynth there was no way to know the field order and the exact interlacing from the clip properties alone, so we came up with the idea long ago to use AssumeFieldBased() to carry frames in a progressive fashion and AssumeFrameBased() to carry interlaced fields so that we could cross-check the clip properties to know whether it was interlaced TFF, interlaced BFF or progressive 'cause there were no frame properties in the past and now this thing has come back to bite us, but anyway, this is just the reason why the interlacing check wouldn't make sense for a normal user.
As to the rest, please check it and let me know if I missed something.
I tested it and it seems to be working, but you know, you never know...
Also I'm sure I could have saved space by applying better coding methods and practices, but still, I hope you get what I was trying to do.
Now, with no further due, here's the thing: https://github.com/FranceBB/ClipPropertiesParser/blob/main/_ffas_helpers.avsi
Example:
video=DGDecode_MPEG2Source("colorbars_no_data.d2v")
audio=WAVSource("colorbars_no_data.wav")
AudioDub(video, audio)
_ffas_helpers()
https://user-images.githubusercontent.com/18946343/186724269-0091b1d4-d38c-42f6-8e30-f62d3fdd33d6.png
if we didn't have the property parser, however...
video=DGDecode_MPEG2Source("colorbars_no_data.d2v")
audio=WAVSource("colorbars_no_data.wav")
AudioDub(video, audio)
https://user-images.githubusercontent.com/18946343/186724566-33c82580-a3cc-46c4-aca8-264ccaff0a13.png
as you know at work we're largely based on Avisynth and ever since the introduction of frame properties I tried not to use them at all 'cause I hated them.
Unfortunately, we live in a democracy, so my colleagues voted in favor of frame properties and I've been outnumbered / outvoted, so now I must support them.
Before this whole madness, I used to use propclearall() right after indexing and call it a day, but now I can't do that.
So, the guys at the end of the filter-chain now expect frame properties to be populated all the time no matter what, so I came up with the following approach:
if there are NO frame properties, I try to use some of the clip properties to assume frame properties (but it's largely based on guess-work) while if I have SOME frame properties, I'll preserve those but I'll also try to see whether I have all the ones I need and I will fill the gap either by using what I've got as frame properties OR by using the same guess-work I would have used if I didn't have anything in the first place.
The result of this is a series of conditional and try-catch statement that try to prevent the function from erroring out.
Before I show you the whole thing, a remark: even though it's here, I made this only for our own internal use cases in the supply chain, therefore you'll see that the interlacing check doesn't really make sense for a normal user. This is because technically in Avisynth there was no way to know the field order and the exact interlacing from the clip properties alone, so we came up with the idea long ago to use AssumeFieldBased() to carry frames in a progressive fashion and AssumeFrameBased() to carry interlaced fields so that we could cross-check the clip properties to know whether it was interlaced TFF, interlaced BFF or progressive 'cause there were no frame properties in the past and now this thing has come back to bite us, but anyway, this is just the reason why the interlacing check wouldn't make sense for a normal user.
As to the rest, please check it and let me know if I missed something.
I tested it and it seems to be working, but you know, you never know...
Also I'm sure I could have saved space by applying better coding methods and practices, but still, I hope you get what I was trying to do.
Now, with no further due, here's the thing: https://github.com/FranceBB/ClipPropertiesParser/blob/main/_ffas_helpers.avsi
Example:
video=DGDecode_MPEG2Source("colorbars_no_data.d2v")
audio=WAVSource("colorbars_no_data.wav")
AudioDub(video, audio)
_ffas_helpers()
https://user-images.githubusercontent.com/18946343/186724269-0091b1d4-d38c-42f6-8e30-f62d3fdd33d6.png
if we didn't have the property parser, however...
video=DGDecode_MPEG2Source("colorbars_no_data.d2v")
audio=WAVSource("colorbars_no_data.wav")
AudioDub(video, audio)
https://user-images.githubusercontent.com/18946343/186724566-33c82580-a3cc-46c4-aca8-264ccaff0a13.png