On Mon, 19 Aug 2013, Luca Barbato wrote:
On 19/08/13 01:19, Martin Storsjö wrote:
On Sun, 18 Aug 2013, Luca Barbato wrote:
Ensures http-streaming webm works correctly on all browsers.
---
libavformat/matroskaenc.c | 1 +
libavformat/version.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
I didn't look closely at this patchset yet, but I think this commit
message needs to be clarified a little...
If I understand it properly, with this patch in place, you should assume
that the cluster for the keyframe starts _after_ the data that gets
output from the av_write_frame(keyframe_packet) call. This is different
from most muxers (e.g. FLV), where the keyframe in the stream starts at
the start of what gets output from what gets output form that
av_write_frame call.
You cannot know when you get the next keyframe before getting it so all
you can do is flush once you got the keyframe.
Yes, you can't know when you'd get it, but the main point is that you
always get it after the write_frame call, not during this one.
That is, with FLV, you'd do "mark_keyframe_pos(cur_stream_pos);
av_write_frame(keyframe_packet);", while you should do
"av_write_frame(keyframe_packet); mark_keyframe_pos(cur_stream_pos);"
with WebM.
And works because you write down every packet as a stand alone entity
while in mkv you have clusters of packets, I could make optionally so
your cluster starts and ends every video packet but I'm not sure how
nice would be.
Nah, I don't think that would be necessary, but just briefly mentioning
this would probably be good.
Another thing that could be done however, is adding AVFMT_ALLOW_FLUSH to
.flags and making that flush the current cluster. Then the caller could
even more easily decide how/when to cut clusters by doing
av_write_frame(NULL) whenever they want to start a new cluster from fresh
right now. Then you'd know that the keyframe cluster will start at that
point in the stream from after the flush (even if the keyframe cluster is
only output much later). I could do a patch for that if you're ok with the
idea.
So the commit message should mention this in one way or another - it
isn't (unfortunately) just so simple that this patch makes everything
work magically - the caller still needs to do things in a certain (not
totally obvious) way.
If the information is _that_ important we could extend avio, but feels
wrong to many levels and we aren't even started thinking about
multi-stream and lovely stuff like opus.
Yes, passing the info proper info through avio isn't all that easy.
As I wrote to the vlc ml, we are trying to make pigs fly while better
solutions would be taken (e.g. fix the clients to properly cope with the
situation)
Yes, that would probably be another good thing to do.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
