To get mpegts metadata copied when segmenting.
---
libavformat/segment.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 1cb6454..0be77da 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -1
Fixes wrong number of segments output and undefined memory access.
---
libavformat/segment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index ce784da..1cb6454 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -6
This adds a new option -hls_flags single_file that creates one .ts file
for HLS and adds byteranges to the .m3u8 file, instead of creating one
.ts file for each segment.
This is helpful at least for storing large number of videos, as the
number of files per video is drastically reduced and copying
This adds a new option -hls_flags single_file that creates one .ts file
for HLS and adds byteranges to the .m3u8 file, instead of creating one
.ts file for each segment.
This is helpful at least for storing large number of videos, as the
number of files per video is drastically reduced and copying
This adds a new option -hls_flags single_file that creates one .ts file
for HLS and adds byteranges to the .m3u8 file, instead of creating one
.ts file for each segment.
This is helpful at least for storing large number of videos, as the
number of files per video is drastically reduced and copying
This adds a new option -hls_flags single_file that creates one .ts file
for HLS and adds byteranges to the .m3u8 file, instead of creating one
.ts file for each segment.
This is helpful at least for storing large number of videos, as the
number of files per video is drastically reduced and copying
and packaging pipe
fails to handle (it would probably do even better on the rest).
Thanks for all the features of ffmpeg that did work out-of-the-box :-)
BR,
Mika Raento
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Reads the fragment duration from the trun sample data, rather than
assuming that there are no gaps. Creates much better playlists for our
inputs.
---
tools/ismindex.c | 96 +---
1 file changed, 85 insertions(+), 11 deletions(-)
diff --git a/tool
Hi
I have a number of ISMV files that have discontinuities (missing
frames between fragments). Using these as input to ffmpeg doesn't work
very well - the discontinuities are not reflected in the dts or pts,
e.g., using ffprobe -show_packets. Hence there are audio/video sync
problems and with larg
For better or worse, ismindex doesn't use av_log anywhere, I'm
following the existing style in the file. Changing the whole file
should be a separate patch?
Mika
On 8 October 2014 09:33, Carl Eugen Hoyos wrote:
> Mika Raento iki.fi> writes:
>
>> +
On 8 October 2014 08:12, Mika Raento wrote:
> Reads the fragment duration from the trun sample data, rather than
> assuming that there are no gaps. Creates much better playlists for our
> inputs.
> ---
> tools/ismindex.c | 96
>
Reads the fragment duration from the trun sample data, rather than
assuming that there are no gaps. Creates much better playlists for our
inputs.
---
tools/ismindex.c | 95 ++--
1 file changed, 85 insertions(+), 10 deletions(-)
diff --git a/tool
I will send a patch that reads the MFRA. It's more a RFC than a patch,
I for example have not yet run the regression suite with it.
Mika
On 8 October 2014 08:54, Mika Raento wrote:
> Hi
>
> I have a number of ISMV files that have discontinuities (missing
> frames between
If present, an MFRA box and its TFRAs are read for fragment start times.
Without this change, timestamps for discontinuous fragmented mp4 are
wrong, and cause audio/video desync and are not usable for generating
HLS.
---
libavformat/isom.h | 14 +++
libavformat/mov.c | 116 +
Thanks a lot for the detailed comments, will address and resubmit. - mika
On 8 October 2014 16:03, Michael Niedermayer wrote:
> Hi
>
> On Wed, Oct 08, 2014 at 03:05:07PM +0300, Mika Raento wrote:
>> If present, an MFRA box and its TFRAs are read for fragment start times.
>
On 8 October 2014 16:03, Michael Niedermayer wrote:
> Hi
>
> On Wed, Oct 08, 2014 at 03:05:07PM +0300, Mika Raento wrote:
>> If present, an MFRA box and its TFRAs are read for fragment start times.
>>
>> Without this change, timestamps for discontinuous fragmented
On 8 October 2014 16:15, Michael Niedermayer wrote:
> On Wed, Oct 08, 2014 at 03:03:50PM +0200, Michael Niedermayer wrote:
> [...]
>> > @@ -3565,6 +3678,9 @@ static int mov_read_header(AVFormatContext *s)
>> > else
>> > atom.size = INT64_MAX;
>> >
>> > +if (pb->seekable) {
>> > +
If present, an MFRA box and its TFRAs are read for fragment start times.
Without this change, timestamps for discontinuous fragmented mp4 are
wrong, and cause audio/video desync and are not usable for generating
HLS.
---
libavformat/isom.h | 14 ++
libavformat/mov.c | 131 ++
fate passes with these changes, no new tests added. - mika
On 9 October 2014 08:53, Mika Raento wrote:
> If present, an MFRA box and its TFRAs are read for fragment start times.
>
> Without this change, timestamps for discontinuous fragmented mp4 are
> wrong, and cause audio/video de
On 9 October 2014 18:30, Michael Niedermayer wrote:
> On Thu, Oct 09, 2014 at 08:52:29AM +0300, Mika Raento wrote:
>> On 8 October 2014 16:03, Michael Niedermayer wrote:
> [...]
>> >> +if (avio_rb32(f) != mfra_size) {
>> >> +av_log(s, AV_LOG_DEB
If present, an MFRA box and its TFRAs are read for fragment start times.
Without this change, timestamps for discontinuous fragmented mp4 are
wrong, and cause audio/video desync and are not usable for generating
HLS.
---
libavformat/isom.h | 15 ++
libavformat/mov.c | 140 ++
know what may break
with my changes (and I'm thankful for the reviews that try to fix that
problem).
Mika
On 9 October 2014 22:49, Michael Niedermayer wrote:
> On Thu, Oct 09, 2014 at 09:44:43PM +0200, Michael Niedermayer wrote:
>> On Thu, Oct 09, 2014 at 06:57:59PM +0300, Mi
On 9 October 2014 23:37, Yusuke Nakamura wrote:
> 2014-10-10 4:49 GMT+09:00 Michael Niedermayer :
>
>> On Thu, Oct 09, 2014 at 09:44:43PM +0200, Michael Niedermayer wrote:
>> > On Thu, Oct 09, 2014 at 06:57:59PM +0300, Mika Raento wrote:
>> > > If present, an MF
Ah. My approach to matching truns to fragment times was way too naive.
Rewritten to look up the time by sequence number and to handle
multiple truns inside a single traf. Resubmitting.
Mika
On 9 October 2014 22:44, Michael Niedermayer wrote:
> On Thu, Oct 09, 2014 at 06:57:59PM +0300, M
If present, an MFRA box and its TFRAs are read for fragment start times.
Without this change, timestamps for discontinuous fragmented mp4 are
wrong, and cause audio/video desync and are not usable for generating
HLS.
---
libavformat/isom.h | 15 ++
libavformat/mov.c | 140 ++
e my code as-is, and hope somebody more knowledgeable
can fix it up later.
3. I can try to implement the algorithm described.
4. Somebody helps me with either implementation or by providing test cases.
Opinions?
Mika
On 10 October 2014 20:11, Yusuke Nakamura wrote:
> 2014-10-10 13:38 GMT
On 10 October 2014 23:08, Mika Raento wrote:
> Firstly, thank you for the detailed explanation.
>
> Secondly, how should we proceed?
>
> I am not confident I'm able to implement that correctly, especially
> with no test coverage.
>
> My current implementation impr
If present, an MFRA box and its TFRAs are read for fragment start times.
Without this change, timestamps for discontinuous fragmented mp4 are
wrong, and cause audio/video desync and are not usable for generating
HLS.
---
libavformat/isom.h | 15 ++
libavformat/mov.c | 146 ++
tfra entries.
Thanks again for your help.
Mika
On 11 October 2014 14:21, Michael Niedermayer wrote:
> On Sat, Oct 11, 2014 at 07:25:52AM +0300, Mika Raento wrote:
>> If present, an MFRA box and its TFRAs are read for fragment start times.
>>
>> Without this change, ti
on't think it'll
be easy to automatically detect what the creating program has been
doing.
I'll submit the version with fixed matching shortly.
Mika
On 11 October 2014 15:27, Mika Raento wrote:
> Interesting. The input.mov created with ./ffmpeg -i
> matrixbench_mpeg2.
If present, an MFRA box and its TFRAs are read for fragment start times.
Without this change, timestamps for discontinuous fragmented mp4 are
wrong, and cause audio/video desync and are not usable for generating
HLS.
---
libavformat/isom.h | 16 ++
libavformat/mov.c | 158 ++
On 11 October 2014 16:41, Carl Eugen Hoyos wrote:
> Mika Raento iki.fi> writes:
>
>> +if (ret < 0)
>> +av_log(c->fc, AV_LOG_ERROR,
>> + "failed to seek back after looking for mfra\n");
>> +else
>> +r
This introduces a new option to the mov demuxer: -use_mfra_for
(pts|dts). When it's given and moofs and a MFRA are present, the MFRA's
TFRAs are read for fragment start times.
Unfortunately some programs that produce fragmented mp4s use the TFRA
time field for dts and some for pts. There is no rea
Resubmission follows Carl's advice on braces.
On 11 October 2014 16:49, Carl Eugen Hoyos wrote:
> Mika Raento iki.fi> writes:
>
>> Somehow I'd gotten the impression that the opposite
>> was preferred, and indeed mov.c tends not to have
>> those braces. Ha
On 11 October 2014 20:20, Michael Niedermayer wrote:
> On Sat, Oct 11, 2014 at 06:43:48PM +0300, Mika Raento wrote:
>> This introduces a new option to the mov demuxer: -use_mfra_for
>> (pts|dts). When it's given and moofs and a MFRA are present, the MFRA's
>> TF
Oh, and the transcoder was giving discontinuous input because there
was packetloss in the original DVB stream it was getting.
On 11 October 2014 20:38, Mika Raento wrote:
> On 11 October 2014 20:20, Michael Niedermayer wrote:
>> On Sat, Oct 11, 2014 at 06:43:48PM +0300, Mika Rae
On 11 October 2014 23:02, Michael Niedermayer wrote:
> On Sat, Oct 11, 2014 at 08:38:14PM +0300, Mika Raento wrote:
>> On 11 October 2014 20:20, Michael Niedermayer wrote:
>> > On Sat, Oct 11, 2014 at 06:43:48PM +0300, Mika Raento wrote:
>> >> This introduces a
On 14 October 2014 23:48, Michael Niedermayer wrote:
> On Mon, Oct 13, 2014 at 01:45:18PM +0200, Michael Niedermayer wrote:
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavformat/isom.h |1 +
>> libavformat/mov.c | 29 +++--
>> 2 files changed, 28 insertions(+
On 14 October 2014 23:48, Michael Niedermayer wrote:
> On Mon, Oct 13, 2014 at 01:45:18PM +0200, Michael Niedermayer wrote:
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavformat/isom.h |1 +
>> libavformat/mov.c | 29 +++--
>> 2 files changed, 28 insertions(+
This fixes the abnormally high ts overhead in the files produced by the
HLS and segments muxers. See https://trac.ffmpeg.org/ticket/2857 . For
example makes it much more likely that it can produces streams that fit
under the 64kb App store limit.
---
libavformat/hlsenc.c | 10 ++
libavfor
If using MFRA for timestamps, the stream may start from a large offset
and/or have gaps. With this change we calculate the bitrate based on
frames we've seen.
---
libavformat/mov.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 80549ec.
https://trac.ffmpeg.org/ticket/4062 (new ticket)
Mika
On 27 October 2014 01:00, Michael Niedermayer wrote:
> On Wed, Sep 24, 2014 at 10:43:40AM +0300, Mika Raento wrote:
> > Dear all
> >
> > This mail is meant mainly as a note to other potential users, but
> > possibly as input
segment muxer PIDs were fixed in
https://github.com/FFmpeg/FFmpeg/commit/502fc3b3d4b36015562d19d74f27d0a4ff835c4e
by me
On 29 October 2014 10:17, Mika Raento wrote:
> Hi
>
> Thanks for the feedback.
>
> I'll try to capture at least some of these in tickets, and reply on t
other were missing (esp. in the beginning). Maybe I could make this simpler
if I'd relax that requirement (I don't know how much happier my users are
if they get audio but no video, rather than nothing).
Mika
On 29 October 2014 10:38, Mika Raento wrote:
> segment muxer PIDs
Created a feature request to support columnboxing input that changes
aspect-ratio mid-stream.
https://trac.ffmpeg.org/ticket/4065
On 29 October 2014 13:49, Mika Raento wrote:
> Tickets for sub2video and async not working with non-monotonic input,
> using -copyts:
>
> https://tra
Created a feature request to automatically scale subtitles for HD video
https://trac.ffmpeg.org/ticket/4066
On 29 October 2014 14:25, Mika Raento wrote:
> Created a feature request to support columnboxing input that changes
> aspect-ratio mid-stream.
>
> https://trac.ffmpeg.org
this would cause mfra to be ignored in files larger than 2G
---
libavformat/mov.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 6ba7b96..8bf16e7 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3819
this would cause mfra to be ignored in files larger than 2G
---
libavformat/mov.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 6ba7b96..506c1a6 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3820,3
On 14 November 2014 21:51, Michael Niedermayer wrote:
> On Fri, Nov 14, 2014 at 07:12:34PM +0200, Mika Raento wrote:
> > this would cause mfra to be ignored in files larger than 2G
> > ---
> > libavformat/mov.c | 22 ++
> > 1 file changed, 14
On 15 November 2014 09:00, Mika Raento wrote:
> On 14 November 2014 21:51, Michael Niedermayer wrote:
>
>> On Fri, Nov 14, 2014 at 07:12:34PM +0200, Mika Raento wrote:
>> > this would cause mfra to be ignored in files larger than 2G
>> > --
be synced).
Mika
On 29 October 2014 13:49, Mika Raento wrote:
> Tickets for sub2video and async not working with non-monotonic input,
> using -copyts:
>
> https://trac.ffmpeg.org/ticket/4062
> https://trac.ffmpeg.org/ticket/4064
>
> Hm. Lots of my issues seem to relate
51 matches
Mail list logo
