On Mon, 26 Apr 2021, Lynne wrote:
Apr 26, 2021, 02:36 by c...@passwd.hu:
On Sun, 25 Apr 2021, Lynne wrote:
This is the same patch sent in January, rebased on top of the ABI bump
patchset.
Two additions mirror exactly what AVFrame has - an opaque field
and an opaque_ref for user-side private data.
For justification on the void *opaque field, you can read the archives,
since the question was brought up in January.
As for the time_base field, for now, it will only be used to inform the user,
and will not alter the behavior of the libraries. That change will come as an
optional flag.
I would like to see some documentation and code which shows when the time_base
is respected and when it is not before it is added to AVPacket. After the bump
we usually have a 1-2 months of cooldown when the ABI can change, so there
really is no rush.
I didn't mean to say that it'll be done during the bump, but rather after it.
Once we add time_base, there are no ABI-breaking changes to support
what I was thinking of.
Or do you still want to see some code? It's not a small amount of work.
But if it is far from trivial, then does it really worth introducing it? I
am asking, because I am still not sure about the benefits or the issues it
is trying to solve.
You wrote earlier that you don't like that you have to pass packets to the
muxer in a timebase as set by the muxer's init function. Solving this by
adding a muxer open flag which saves the preferred time base of the user
and rescales all packets from the user's preferred time base to the real
time base before processing seems much more managable than introducing the
AVPacket->time_base support everywhere and as far as I see it solves this
problem just the same.
Are there similar problems elsewhere? If there are, then is it not more
managable to allow the user to specify a preferred input or output
timebase during init instead of allowing per-packet timebases? By adding
time_base to AVPacket you basically say that it is possible
that each packet of a stream have a different time base. But in realitly,
this never happens.
Regards,
Marton
_______________________________________________
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".
