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.
A long term solution would be split write_header from init_muxer (I'd slate
that after 0.9 though) a short term solution might be just add the segmenting
options in the muxer itself.
Since it should be quick but not the quickest and it is partially an hack,
who's against this short term approach?
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.
Also, I'm against the thing you suggest as a "long term solution", since I
think this is the wrong approach.
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.
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.
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.
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. 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.
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.
For other formats, such as ismv in smooth streaming, things are way
different. There, you can either write all the fragments into one
single ismv file (which needs serverside support for serving as
fragments), or you can write the fragments into individual files for
serving by a plain normal web server. There, the
segmentation/fragmentation process is like this:
- First you write the header of the file (ftyp+moov) by calling
write_header - if writing data to one single ismv file, you write it
there, but if you write individual fragment files, this data should not be
written into any fragment at all.
- Then you write packets for the next fragment - these are buffered within
the muxer
- When you want to cut to a new fragment, you call av_write_frame(ctx,
NULL), to flush the buffered packets. This outputs one moof+mdat atom
pair, which you write into the fragment file. (For one big ismv file, just
write it to the file.)
- Repeat the last two steps for each fragment, writing into a new fragment
file each time.
- When you're finished, you call write_trailer. This writes mfra atoms for
the end of the stream - this shouldn't be written to any fragment file
either, but should be written to the ismv file.
In this case, you woulnd't be using write_header at all while writing the
packets and fragments. The fragment files are just small subsets of the
full ismv file, excluding the header (ftyp+moov) and trailer (mfra) of the
file.
Hypothetically, if you want to do a segmenting muxer which produces a
playlist of let's say wav files, you need to do the full write_header +
write_trailer for each file, to produce normal wav files that are playable
on their own.
Thus, my point is that segmenting data into separate files is a very
format specific process. Trying to generalize it is fine and admirable,
but please don't change the mpegts muxer to try to fit a different
process, when there are enough provisions for doing it just right in the
current state.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
