Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

2017-11-27 Thread James Almer 
On 11/27/2017 8:52 PM, James Almer wrote:
> On 11/27/2017 8:18 PM, Michael Niedermayer wrote:
>> On Sun, Nov 26, 2017 at 05:51:03PM -0300, James Almer wrote:
>>> Every bitstream filter behaves as intended now, so there's no need to
>>> wait for the first packet of every stream.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>>  libavformat/avformat.h |  2 +-
>>>  libavformat/internal.h |  6 -
>>>  libavformat/mux.c  | 52 
>>> --
>>>  libavformat/options_table.h|  2 +-
>>>  libavformat/tests/fifo_muxer.c | 52 
>>> --
>>>  tests/ref/fate/fifo-muxer-tst  |  1 -
>>>  6 files changed, 12 insertions(+), 103 deletions(-)
>>
>> Is this intended to change any files ?
>>
>> this changes slightly:
>> ./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv
>>
>> not saying this is a issue in the patch or anything (i am in favor of
>> the simplification in fact), just that i saw this change
> 
> I can't access that file, but just in case it's related, this patch is
> meant to be applied after the first. Otherwise, as the first patch
> states, stream parameters that might be changed by ffmpeg.c while
> processing an input frame (specifically field_order) will not be taken
> into account during write_header.
> You might remember i have sent this patch alone before, and how it
> affected matroska files because of differing field_order values,
> including fate-rgb24-mkv.
> 
> For that matter, ffmpeg.c changing any output codecpar values while
> reading an input frame (that is, long after the output file and streams
> have been initialized) is a very hacky thing to do. This is something
> I'd expect avformat_find_stream_info() to do instead, since it decodes
> some frames to get all the info it needs, and not the API user (ffmpeg.c).

Just tested it, and it was indeed field_order in the output codecpar.
And it unfortunately happens with both patches applied.
Looks like the packet that gets processed by ffmpeg.c to fill
field_order is not necessarily the first to show up, and the only way to
effectively write the header after it is with the delayed header code as
it's implemented in av_interleaved_write_frame.

So yeah, patch 1 can be applied or dropped as preferred (it after all
does at least cover some cases, like fate-rgb24-mkv), but this one
should still be applied regardless of the above.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

2017-11-27 Thread James Almer 
On 11/27/2017 9:00 PM, Carl Eugen Hoyos wrote:
> 2017-11-28 0:52 GMT+01:00 James Almer :
>> On 11/27/2017 8:18 PM, Michael Niedermayer wrote:
> 
>>> this changes slightly:
>>> ./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv
>>>
>>> not saying this is a issue in the patch or anything (i am in favor of
>>> the simplification in fact), just that i saw this change
>>
>> I can't access that file
> 
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2263/
> Will remove it again.

Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

2017-11-27 Thread Carl Eugen Hoyos 
2017-11-28 0:52 GMT+01:00 James Almer :
> On 11/27/2017 8:18 PM, Michael Niedermayer wrote:

>> this changes slightly:
>> ./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv
>>
>> not saying this is a issue in the patch or anything (i am in favor of
>> the simplification in fact), just that i saw this change
>
> I can't access that file

http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2263/
Will remove it again.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

2017-11-27 Thread James Almer 
On 11/27/2017 8:18 PM, Michael Niedermayer wrote:
> On Sun, Nov 26, 2017 at 05:51:03PM -0300, James Almer wrote:
>> Every bitstream filter behaves as intended now, so there's no need to
>> wait for the first packet of every stream.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/avformat.h |  2 +-
>>  libavformat/internal.h |  6 -
>>  libavformat/mux.c  | 52 
>> --
>>  libavformat/options_table.h|  2 +-
>>  libavformat/tests/fifo_muxer.c | 52 
>> --
>>  tests/ref/fate/fifo-muxer-tst  |  1 -
>>  6 files changed, 12 insertions(+), 103 deletions(-)
> 
> Is this intended to change any files ?
> 
> this changes slightly:
> ./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv
> 
> not saying this is a issue in the patch or anything (i am in favor of
> the simplification in fact), just that i saw this change

I can't access that file, but just in case it's related, this patch is
meant to be applied after the first. Otherwise, as the first patch
states, stream parameters that might be changed by ffmpeg.c while
processing an input frame (specifically field_order) will not be taken
into account during write_header.
You might remember i have sent this patch alone before, and how it
affected matroska files because of differing field_order values,
including fate-rgb24-mkv.

For that matter, ffmpeg.c changing any output codecpar values while
reading an input frame (that is, long after the output file and streams
have been initialized) is a very hacky thing to do. This is something
I'd expect avformat_find_stream_info() to do instead, since it decodes
some frames to get all the info it needs, and not the API user (ffmpeg.c).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

2017-11-27 Thread Michael Niedermayer 
On Sun, Nov 26, 2017 at 05:51:03PM -0300, James Almer wrote:
> Every bitstream filter behaves as intended now, so there's no need to
> wait for the first packet of every stream.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/avformat.h |  2 +-
>  libavformat/internal.h |  6 -
>  libavformat/mux.c  | 52 
> --
>  libavformat/options_table.h|  2 +-
>  libavformat/tests/fifo_muxer.c | 52 
> --
>  tests/ref/fate/fifo-muxer-tst  |  1 -
>  6 files changed, 12 insertions(+), 103 deletions(-)

Is this intended to change any files ?

this changes slightly:
./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv

not saying this is a issue in the patch or anything (i am in favor of
the simplification in fact), just that i saw this change

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

2017-11-27 Thread James Almer 
On 11/27/2017 6:00 AM, Tobias Rapp wrote:
> On 26.11.2017 21:51, James Almer wrote:
>> Every bitstream filter behaves as intended now, so there's no need to
>> wait for the first packet of every stream.
>>
>> Signed-off-by: James Almer 
>> ---
>>   libavformat/avformat.h |  2 +-
>>   libavformat/internal.h |  6 -
>>   libavformat/mux.c  | 52
>> --
>>   libavformat/options_table.h    |  2 +-
>>   libavformat/tests/fifo_muxer.c | 52
>> --
>>   tests/ref/fate/fifo-muxer-tst  |  1 -
>>   6 files changed, 12 insertions(+), 103 deletions(-)
>>
>> [...]
> 
> I'm just curious: Will this fix ticket #6375?
> 
> Regards,
> Tobias

Unlikely. That's from ffmpeg.c buffering logic which I'm not changing here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

2017-11-27 Thread Tobias Rapp 

On 26.11.2017 21:51, James Almer wrote:

Every bitstream filter behaves as intended now, so there's no need to
wait for the first packet of every stream.

Signed-off-by: James Almer 
---
  libavformat/avformat.h |  2 +-
  libavformat/internal.h |  6 -
  libavformat/mux.c  | 52 --
  libavformat/options_table.h|  2 +-
  libavformat/tests/fifo_muxer.c | 52 --
  tests/ref/fate/fifo-muxer-tst  |  1 -
  6 files changed, 12 insertions(+), 103 deletions(-)

[...]


I'm just curious: Will this fix ticket #6375?

Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

2017-11-26 Thread James Almer 
Every bitstream filter behaves as intended now, so there's no need to
wait for the first packet of every stream.

Signed-off-by: James Almer 
---
 libavformat/avformat.h |  2 +-
 libavformat/internal.h |  6 -
 libavformat/mux.c  | 52 --
 libavformat/options_table.h|  2 +-
 libavformat/tests/fifo_muxer.c | 52 --
 tests/ref/fate/fifo-muxer-tst  |  1 -
 6 files changed, 12 insertions(+), 103 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 322210fae0..4f2798a871 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1449,7 +1449,7 @@ typedef struct AVFormatContext {
 #endif
 #define AVFMT_FLAG_FAST_SEEK   0x8 ///< Enable fast, but inaccurate seeks 
for some formats
 #define AVFMT_FLAG_SHORTEST   0x10 ///< Stop muxing when the shortest 
stream stops.
-#define AVFMT_FLAG_AUTO_BSF   0x20 ///< Wait for packet data before 
writing a header, and add bitstream filters as requested by the muxer
+#define AVFMT_FLAG_AUTO_BSF   0x20 ///< Add bitstream filters as requested 
by the muxer
 
 /**
  * Maximum size of the data read from input for determining
diff --git a/libavformat/internal.h b/libavformat/internal.h
index fcd47840a5..36a57214ce 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -120,12 +120,6 @@ struct AVFormatInternal {
 
 int avoid_negative_ts_use_pts;
 
-/**
- * Whether or not a header has already been written
- */
-int header_written;
-int write_header_ret;
-
 /**
  * Timestamp of the end of the shortest stream.
  */
diff --git a/libavformat/mux.c b/libavformat/mux.c
index b1244c67f3..ebb9102f11 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -458,25 +458,6 @@ static void flush_if_needed(AVFormatContext *s)
 }
 }
 
-static int write_header_internal(AVFormatContext *s)
-{
-if (!(s->oformat->flags & AVFMT_NOFILE) && s->pb)
-avio_write_marker(s->pb, AV_NOPTS_VALUE, AVIO_DATA_MARKER_HEADER);
-if (s->oformat->write_header) {
-int ret = s->oformat->write_header(s);
-if (ret >= 0 && s->pb && s->pb->error < 0)
-ret = s->pb->error;
-s->internal->write_header_ret = ret;
-if (ret < 0)
-return ret;
-flush_if_needed(s);
-}
-s->internal->header_written = 1;
-if (!(s->oformat->flags & AVFMT_NOFILE) && s->pb)
-avio_write_marker(s->pb, AV_NOPTS_VALUE, AVIO_DATA_MARKER_UNKNOWN);
-return 0;
-}
-
 int avformat_init_output(AVFormatContext *s, AVDictionary **options)
 {
 int ret = 0;
@@ -515,11 +496,18 @@ int avformat_write_header(AVFormatContext *s, 
AVDictionary **options)
 if ((ret = avformat_init_output(s, options)) < 0)
 return ret;
 
-if (!(s->oformat->check_bitstream && s->flags & AVFMT_FLAG_AUTO_BSF)) {
-ret = write_header_internal(s);
+if (!(s->oformat->flags & AVFMT_NOFILE) && s->pb)
+avio_write_marker(s->pb, AV_NOPTS_VALUE, AVIO_DATA_MARKER_HEADER);
+if (s->oformat->write_header) {
+int ret = s->oformat->write_header(s);
+if (ret >= 0 && s->pb && s->pb->error < 0)
+ret = s->pb->error;
 if (ret < 0)
 goto fail;
+flush_if_needed(s);
 }
+if (!(s->oformat->flags & AVFMT_NOFILE) && s->pb)
+avio_write_marker(s->pb, AV_NOPTS_VALUE, AVIO_DATA_MARKER_UNKNOWN);
 
 if (!s->internal->streams_initialized) {
 if ((ret = init_pts(s)) < 0)
@@ -739,12 +727,6 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 }
 }
 
-if (!s->internal->header_written) {
-ret = s->internal->write_header_ret ? s->internal->write_header_ret : 
write_header_internal(s);
-if (ret < 0)
-goto fail;
-}
-
 if ((pkt->flags & AV_PKT_FLAG_UNCODED_FRAME)) {
 AVFrame *frame = (AVFrame *)pkt->data;
 av_assert0(pkt->size == UNCODED_FRAME_PACKET_SIZE);
@@ -760,8 +742,6 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 ret = s->pb->error;
 }
 
-fail:
-
 if (ret < 0) {
 pkt->pts = pts_backup;
 pkt->dts = dts_backup;
@@ -894,11 +874,6 @@ int av_write_frame(AVFormatContext *s, AVPacket *pkt)
 
 if (!pkt) {
 if (s->oformat->flags & AVFMT_ALLOW_FLUSH) {
-if (!s->internal->header_written) {
-ret = s->internal->write_header_ret ? 
s->internal->write_header_ret : write_header_internal(s);
-if (ret < 0)
-return ret;
-}
 ret = s->oformat->write_packet(s, NULL);
 flush_if_needed(s);
 if (ret >= 0 && s->pb && s->pb->error < 0)
@@ -1282,14 +1257,8 @@ int av_write_trailer(AVFormatContext *s)
 goto fail;
 }
 
-if (!s->internal->header_written) {
-ret = s->internal->write_header_ret ?