On Sun, 26 Feb 2012, Luca Barbato wrote:
On 2/26/12 3:05 PM, Martin Storsjö wrote:
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.
Agreed completely, segment isn't a cover all solution, is just a generic
splitter that can be useful for similar purposes.
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).
Just to get something like
avconv -i in -v:c libx264 ... -hsl_segment_time 10 -hsl_list list.m3u8
out%03d.ts
More or less.
I don't think that'd be all that much more convenient within the normal
mpegts muxer than using it via a specialized segmenter muxer. (That is, a
user wouldn't probably guess that combination of command line switches
without resorting to some manual, so doing it via a separate segmenter
shouldn't be an issue.)
I might be ok with that change, although I personally don't see the need
for it.
It should make the two libraries a little more similar api wise.
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.
agreed but then should we add that little more code in avconv or in
libavformat?
Which "little more code" do you suggest here? I think most of this should
be fixable with a bit more code within the current generic segmenter.
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.
We can augment the segment muxer or we can augment the specific muxer
somehow. Possibly having a stand alone muxer for hsl and smoothstreaming
might be the right solution.
Maybe, but I think we at least for now can use the generic segmenter and
just have slightly different behaviour in the small parts where it
differs, perhaps via different options. If it gets unwieldy with too much
code differing between the variants, it might make sense to split into
separate muxers.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
