On Sun, 26 Feb 2012, Luca Barbato wrote:
On 2/26/12 12:08 AM, Martin Storsjö wrote:
On Sat, 25 Feb 2012, Luca Barbato wrote:
After discussing with martin looks like the mpegts write_header isn't
that compatible with my segmenting approach.
This may sound rude - sorry about that, no offense meant, but... If it
isn't compatible - why not change your segmenting approach instead of
changing the mpegts write_write header? The current mpegts muxer
behaviour works just fine for me.
Because if my segmenting approach is "create a new file every N seconds", it
should create a new file by writing the header, then the packets and then the
trailer.
I think most of the problems/misunderstanding comes from this assumption.
For generic segmenting, this perhaps is a sensible structure, but for
mpegts/HLS, I don't agree with it (even though there is no trailer to
write), and for other (such as smooth streaming) it most definitely isn't
right. My point therefore is that it isn't right to try to squeeze all
formats into this structure, since they don't fit.
What sould this "short term hack" for segmenting support within the
muxer be? The muxer already has everything you need, in the
resend_headers option.
Add the private options and the logic to cut the file basically.
Why would anything of this have to be in the mpegts muxer? As it is now,
the mpegts muxer just needs to know how to produce one single output
stream, and the caller can do the cutting, and this works just fine (as
shown in the sample branch I made).
Also, I'm against the thing you suggest as a "long term solution", since
I think this is the wrong approach.
Unrelated to the segment situation, the current api is wrong since doesn't
differentiate between init (that could take long and be slow) and write
headers (that should be quick).
I might be ok with that change, although I personally don't see the need
for it.
The problem, as I see it, is that the approach taken by your segmenting
muxer simply is wrong, or then I just don't understand it, since it
makes things way more complicated than they need to be.
It is straightforward. You create a new file for each segment, in order to do
that you just close the avio, set the format context to workaround the
init+write header, write the new header, the packets up to the next segment,
write the trailer making sure it doesn't dealloc more than you'd expect, move
to the next one.
If our format api gets overhauled as I like we would get
init
write header
write packets
write trailer
...
write header
write packets
write trailer
and so on.
If you want to segment mpegts (for HLS), you should not call
write_header/write_trailer. Each file in HLS is not a "individual" ts
file, they're one single stream cut into pieces. The difference is small
for mpegts, though, mostly philosophical.
That's why I prefer putting this different logic in the mpegts muxer.
That's why I don't think the logic should be in the mpegts muxer since it
easily can be done externally with the code that already is there.
The way I recommend doing it (the way I'm doing it in an external
segmenter of mine) is opening one single muxer, initializing it once,
and either closing/reopening the AVIOContext or using a custom
AVIOContext that writes the data into separate files. When switching to
a new segment file, you can set the resend_headers option to 1, to make
the muxer write all the necessary headers when writing the next packet.
Yes, that's the idea for the in-mpegts-muxer approach.
For what I've understood of your suggestion of splitting write_header
into init+write_header, the write_header part would (for mpegts) be
exactly the same as what setting the resend_headers option does today.
Yes.
Therefore, I don't understand why we would need to introduce this
concept on the general lavf level (in the longer term) as a separate
function, since I off-hand don't see a single muxer/format where it fits
in.
Every muxer would fit it, is just similar to avcodec.
In mpegts, the "headers" are written periodically within a stream
anyway. Calling write_header (even a splitted version of the function
which doesn't do init) for me is analoguous to starting a new individual
stream separate from the previous one. Setting the resend_headers option
just triggers the periodical "header" writing immediately but still
considering it the same stream as before. That's the way I view it.
Consider mkv or nut, segment should create files that can be read
independently from the others for really dumb players consuming a playlist
(e.g. a browser with some javascript magic)
Yes, for these kinds of files, you need to do the full writing cycle for
each of the files.
But this doesn't fit for all files - the segmenter needs to have a bit of
logic (or options) for choosing segmenting behaviour, e.g.: One single
write_header/write_trailer call for the full stream, for mpegts. One
single write_header/write_trailer call, don't include the output from
these into segments, for smooth streaming. Calling
write_header/write_trailer for each file, for mkv, wav and other "normal"
formats where each segment really should be a freestanding file playable
with players without any extra logic.
And since the segmenter needs this configurability anyway, I don't think
we need to squeeze mpegts into fitting into the third style.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
