Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 10:07:26PM -0300, James Almer wrote:
> On 9/7/2016 6:14 AM, Michael Niedermayer wrote:
> >>  libavformat/utils.c  |4 +++-
> >> >  tests/ref/fate/copy-trac4914 |4 ++--
> >> >  tests/ref/fate/copy-trac4914-avi |4 ++--
> >> >  3 files changed, 7 insertions(+), 5 deletions(-)
> >> > 2dc146e807cbdbdbca653a22d827920e8c05b3c8  
> >> > 0001-avformat-Export-ticks_per_frame-in-st-codec.patch
> >> > From ae128325081392610475b62d0c20165e0cb9536f Mon Sep 17 00:00:00 2001
> >> > From: Michael Niedermayer 
> >> > Date: Tue, 6 Sep 2016 18:10:41 +0200
> >> > Subject: [PATCH] avformat: Export ticks_per_frame in st->codec
> >> > 
> >> > Suggested-by: Hendrik Leppkes
> >> > Signed-off-by: Michael Niedermayer 
> > applied
> > 
> > with this we have restored the functionality to prior bug/regression
> > so it should serve better as a reference.
> 
> Should be backported to the 3.1 branch.

done locally


> 
> Regarding this whole time_base/ticks_per_frame issue, couldn't we maybe
> add both fields (merged or as is) to codecpar as Clément suggested, but
> as internal/hack/nonpublic instead at least until we find a proper way
> to solve the stream copy case?

> I know adding private-but-not-really fields suck, but so does being stuck
> here because AVI is a crappy format.
> 

> Alternatively, since until now ffmpeg.c's stream copy has been using the
> initialized AVCodecContext from AVStream, can't we alloc, initialize and
> use a separate one, much like it's done for actual transcoding? Would
> that be enough for the decoder to set the two fields?

currently the 2 fields are filled in by avformat_find_stream_info()
parsing and or decoding headers and packets and these can require many
packets. The 2 fields really arent special, avformat_find_stream_info()
fills in alot of little bits and pieces from informative over occasional
useful to critical things.
What avformat_find_stream_info() does could be moved into applications
But that would duplicate the code in many user applications and make
it impossible to centrally fix bugs or add features. It could be moved
under a different API too of course. This would raise the question of
"Why" we again reimplement the API. Theres also a general lack of
discussions about design changes and API deprecations on ffmpeg-devel,
which may be part of the problem

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

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Clément Bœsch]

On Wed, Sep 07, 2016 at 10:07:26PM -0300, James Almer wrote:
> On 9/7/2016 6:14 AM, Michael Niedermayer wrote:
> >>  libavformat/utils.c  |4 +++-
> >> >  tests/ref/fate/copy-trac4914 |4 ++--
> >> >  tests/ref/fate/copy-trac4914-avi |4 ++--
> >> >  3 files changed, 7 insertions(+), 5 deletions(-)
> >> > 2dc146e807cbdbdbca653a22d827920e8c05b3c8  
> >> > 0001-avformat-Export-ticks_per_frame-in-st-codec.patch
> >> > From ae128325081392610475b62d0c20165e0cb9536f Mon Sep 17 00:00:00 2001
> >> > From: Michael Niedermayer 
> >> > Date: Tue, 6 Sep 2016 18:10:41 +0200
> >> > Subject: [PATCH] avformat: Export ticks_per_frame in st->codec
> >> > 
> >> > Suggested-by: Hendrik Leppkes
> >> > Signed-off-by: Michael Niedermayer 
> > applied
> > 
> > with this we have restored the functionality to prior bug/regression
> > so it should serve better as a reference.
> 
> Should be backported to the 3.1 branch.
> 

> Regarding this whole time_base/ticks_per_frame issue, couldn't we maybe
> add both fields (merged or as is) to codecpar as Clément suggested, but
> as internal/hack/nonpublic instead at least until we find a proper way
> to solve the stream copy case?

There might be another way. If this is moved to lavf/utils, the code will
have access to AVStream->internal->avctx, which is (still) legit. AFAICT,
this will require a function such as avformat_remux_copy_timebase().

But is this what we really want?

Also, we need to clarify the use of copy_tb. Currently, according to the
doc, 0=demuxer, 1=decoder, -1=auto but 2 is not documented (maybe it's
time to move the cli options to an AVOption system to have constants).

> I know adding private-but-not-really fields suck, but so does being stuck
> here because AVI is a crappy format.
> 

This is not only for avi, see eed7e08 cf9500a ba96a2a

> Alternatively, since until now ffmpeg.c's stream copy has been using the
> initialized AVCodecContext from AVStream, can't we alloc, initialize and
> use a separate one, much like it's done for actual transcoding? Would
> that be enough for the decoder to set the two fields?

And re-do the probe somehow to fill its parameters?

> I'm throwing shit at the wall to see what sticks, because i barely know
> half of what this whole problem entails. But i do know that the more we
> bikeshed the less chances it will be resolved in a timely and adequate
> manner.

Yes, and this is really hindering any progress with the merge (ETA: ~300
commits, twice as worse as a few weeks ago).

> For that matter, libav clearly didn't have this issue. Does that means
> avconv is creating broken files in these specific cases with stream copy?

AFAIK, yes

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[James Almer]

On 9/7/2016 6:14 AM, Michael Niedermayer wrote:
>>  libavformat/utils.c  |4 +++-
>> >  tests/ref/fate/copy-trac4914 |4 ++--
>> >  tests/ref/fate/copy-trac4914-avi |4 ++--
>> >  3 files changed, 7 insertions(+), 5 deletions(-)
>> > 2dc146e807cbdbdbca653a22d827920e8c05b3c8  
>> > 0001-avformat-Export-ticks_per_frame-in-st-codec.patch
>> > From ae128325081392610475b62d0c20165e0cb9536f Mon Sep 17 00:00:00 2001
>> > From: Michael Niedermayer 
>> > Date: Tue, 6 Sep 2016 18:10:41 +0200
>> > Subject: [PATCH] avformat: Export ticks_per_frame in st->codec
>> > 
>> > Suggested-by: Hendrik Leppkes
>> > Signed-off-by: Michael Niedermayer 
> applied
> 
> with this we have restored the functionality to prior bug/regression
> so it should serve better as a reference.

Should be backported to the 3.1 branch.

Regarding this whole time_base/ticks_per_frame issue, couldn't we maybe
add both fields (merged or as is) to codecpar as Clément suggested, but
as internal/hack/nonpublic instead at least until we find a proper way
to solve the stream copy case?
I know adding private-but-not-really fields suck, but so does being stuck
here because AVI is a crappy format.

Alternatively, since until now ffmpeg.c's stream copy has been using the
initialized AVCodecContext from AVStream, can't we alloc, initialize and
use a separate one, much like it's done for actual transcoding? Would
that be enough for the decoder to set the two fields?

I'm throwing shit at the wall to see what sticks, because i barely know
half of what this whole problem entails. But i do know that the more we
bikeshed the less chances it will be resolved in a timely and adequate
manner.

For that matter, libav clearly didn't have this issue. Does that means
avconv is creating broken files in these specific cases with stream copy?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Tue, Sep 06, 2016 at 06:26:59PM +0200, Michael Niedermayer wrote:
> On Tue, Sep 06, 2016 at 05:45:46PM +0200, Hendrik Leppkes wrote:
> > On Tue, Sep 6, 2016 at 5:10 PM, Michael Niedermayer
> >  wrote:
> > > On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote:
> > >> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
> > >>  wrote:
> > >> > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
> > >> >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> > >> >> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> > >> >> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> > >> >> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> > >> >> > > >> From: Clément Bœsch 
> > >> >> > > >>
> > >> >> > > >> These adjusted codec fields do not seem to be in use anymore 
> > >> >> > > >> and prevent
> > >> >> > > >> the convert of ffmpeg*.c to codecpar.
> > >> >> > > >
> > >> >> > > >  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy 
> > >> >> > > > out.mxf
> > >> >> > > > fails, no output anymore
> > >> >> > > >
> > >> >> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> > >> >> > > > the output now has 600fps
> > >> >> > >
> > >> >> > > Even with this code in place the resulting stream in the avi is 
> > >> >> > > reported
> > >> >> > > as 100 fps.
> > >> >> >
> > >> >> > that seems to be a regression since
> > >> >> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
> > >> >> >
> > >> >> > IIRC the intended timebase is 1/50 for this kind of content
> > >> >> > (allowing the support of interlaced and field duplicated content to
> > >> >> >  appear later)
> > >> >> >
> > >> >> >
> > >> >> > > And with or without the code, the resulting files play the
> > >> >> > > same with the players i tried.
> > >> >> >
> > >> >> > Higher framerates / finer timebases need noticably more space to
> > >> >> > be stored in avi, thats not the case for other formats and thats
> > >> >> > one reason why avi is treated as a special case.
> > >> >> >
> > >> >> > ill try to look tomorrow why its 100fps since the previous
> > >> >> > codecpar patches. Though 100fps is not nearly as bad as 600fps
> > >> >> > 600 has ~6 times the overhead
> > >> >>
> > >> >> This regression is caused by ticks_per_frame beiing incorrect
> > >> >>
> > >> >> Ill send a patch to fix this
> > >> >
> > >> > patch attached
> > >> >
> > >>
> > >> We don't have time_base in codecpar, so why do we need ticks per frame 
> > >> in it?
> > >
> > > We need both in some form probably
> > > For this regression ticks_per_frame ATM is enough.
> > > For time_base theres code to copy/access it bypassing codecpar
> > >
> > > The way it seems to be currently is that there are fields which
> > > are needed and either they are
> > > in codecpar or
> > > theres some tricks to access them from code sheduled to be removed
> > >  (which will work only as long as the code isnt removed)
> > > or things just dont work.
> > >
> > >
> > >>
> > >> Which time_base does it modify the interpretation of? The field should
> > >> be bundled with that, then.
> > >
> > > the AVCodecContext one, ticks_per_frame is already in AVCodecContext
> > > the AVCodecContext ticks_per_frame though is not exported after codecpar
> > > while the codec timebase still is just not vissibly through codecpar
> > >
> > 
> > Maybe that part should be fixed then, wherever we export that to
> > AVCodecContext, also set its ticks_per_frame properly?
> > It just feels bad to export a property here that standing alone
> > doesn't mean anything.
> > 
> > So fix the export of ticks_per_frame for AVCodecContext, and if later
> > on we decide we really do need time_base in AVCodecParameters, and
> > can't fix whatever needs it differently, we can then include both in
> > there.
> 
> attached
> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Dictatorship naturally arises out of democracy, and the most aggravated
> form of tyranny and slavery out of the most extreme liberty. -- Plato

>  libavformat/utils.c  |4 +++-
>  tests/ref/fate/copy-trac4914 |4 ++--
>  tests/ref/fate/copy-trac4914-avi |4 ++--
>  3 files changed, 7 insertions(+), 5 deletions(-)
> 2dc146e807cbdbdbca653a22d827920e8c05b3c8  
> 0001-avformat-Export-ticks_per_frame-in-st-codec.patch
> From ae128325081392610475b62d0c20165e0cb9536f Mon Sep 17 00:00:00 2001
> From: Michael Niedermayer 
> Date: Tue, 6 Sep 2016 18:10:41 +0200
> Subject: [PATCH] avformat: Export ticks_per_frame in st->codec
> 
> Suggested-by: Hendrik Leppkes
> Signed-off-by: Michael Niedermayer 

applied

with this we have restored the functionality to prior bug/regression
so it should serve better as a reference.


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop 

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Tue, Sep 06, 2016 at 05:45:46PM +0200, Hendrik Leppkes wrote:
> On Tue, Sep 6, 2016 at 5:10 PM, Michael Niedermayer
>  wrote:
> > On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote:
> >> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
> >>  wrote:
> >> > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
> >> >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> >> >> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> >> >> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> >> >> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> >> >> > > >> From: Clément Bœsch 
> >> >> > > >>
> >> >> > > >> These adjusted codec fields do not seem to be in use anymore and 
> >> >> > > >> prevent
> >> >> > > >> the convert of ffmpeg*.c to codecpar.
> >> >> > > >
> >> >> > > >  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy 
> >> >> > > > out.mxf
> >> >> > > > fails, no output anymore
> >> >> > > >
> >> >> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> >> >> > > > the output now has 600fps
> >> >> > >
> >> >> > > Even with this code in place the resulting stream in the avi is 
> >> >> > > reported
> >> >> > > as 100 fps.
> >> >> >
> >> >> > that seems to be a regression since
> >> >> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
> >> >> >
> >> >> > IIRC the intended timebase is 1/50 for this kind of content
> >> >> > (allowing the support of interlaced and field duplicated content to
> >> >> >  appear later)
> >> >> >
> >> >> >
> >> >> > > And with or without the code, the resulting files play the
> >> >> > > same with the players i tried.
> >> >> >
> >> >> > Higher framerates / finer timebases need noticably more space to
> >> >> > be stored in avi, thats not the case for other formats and thats
> >> >> > one reason why avi is treated as a special case.
> >> >> >
> >> >> > ill try to look tomorrow why its 100fps since the previous
> >> >> > codecpar patches. Though 100fps is not nearly as bad as 600fps
> >> >> > 600 has ~6 times the overhead
> >> >>
> >> >> This regression is caused by ticks_per_frame beiing incorrect
> >> >>
> >> >> Ill send a patch to fix this
> >> >
> >> > patch attached
> >> >
> >>
> >> We don't have time_base in codecpar, so why do we need ticks per frame in 
> >> it?
> >
> > We need both in some form probably
> > For this regression ticks_per_frame ATM is enough.
> > For time_base theres code to copy/access it bypassing codecpar
> >
> > The way it seems to be currently is that there are fields which
> > are needed and either they are
> > in codecpar or
> > theres some tricks to access them from code sheduled to be removed
> >  (which will work only as long as the code isnt removed)
> > or things just dont work.
> >
> >
> >>
> >> Which time_base does it modify the interpretation of? The field should
> >> be bundled with that, then.
> >
> > the AVCodecContext one, ticks_per_frame is already in AVCodecContext
> > the AVCodecContext ticks_per_frame though is not exported after codecpar
> > while the codec timebase still is just not vissibly through codecpar
> >
> 
> Maybe that part should be fixed then, wherever we export that to
> AVCodecContext, also set its ticks_per_frame properly?
> It just feels bad to export a property here that standing alone
> doesn't mean anything.
> 
> So fix the export of ticks_per_frame for AVCodecContext, and if later
> on we decide we really do need time_base in AVCodecParameters, and
> can't fix whatever needs it differently, we can then include both in
> there.

attached

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
From ae128325081392610475b62d0c20165e0cb9536f Mon Sep 17 00:00:00 2001
From: Michael Niedermayer 
Date: Tue, 6 Sep 2016 18:10:41 +0200
Subject: [PATCH] avformat: Export ticks_per_frame in st->codec

Suggested-by: Hendrik Leppkes
Signed-off-by: Michael Niedermayer 
---
 libavformat/utils.c  | 4 +++-
 tests/ref/fate/copy-trac4914 | 4 ++--
 tests/ref/fate/copy-trac4914-avi | 4 ++--
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 7d23c4a..76cbff4 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3825,8 +3825,10 @@ FF_DISABLE_DEPRECATION_WARNINGS
 st->codec->height = st->internal->avctx->height;
 }
 
-if (st->codec->codec_tag != MKTAG('t','m','c','d'))
+if (st->codec->codec_tag != MKTAG('t','m','c','d')) {
 st->codec->time_base = st->internal->avctx->time_base;
+st->codec->ticks_per_frame = st->internal->avctx->ticks_per_frame;
+}
 st->codec->framerate = st->avg_frame_rate;
 
  

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Hendrik Leppkes]

On Tue, Sep 6, 2016 at 5:10 PM, Michael Niedermayer
 wrote:
> On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote:
>> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
>>  wrote:
>> > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
>> >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
>> >> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
>> >> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
>> >> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
>> >> > > >> From: Clément Bœsch 
>> >> > > >>
>> >> > > >> These adjusted codec fields do not seem to be in use anymore and 
>> >> > > >> prevent
>> >> > > >> the convert of ffmpeg*.c to codecpar.
>> >> > > >
>> >> > > >  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
>> >> > > > fails, no output anymore
>> >> > > >
>> >> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
>> >> > > > the output now has 600fps
>> >> > >
>> >> > > Even with this code in place the resulting stream in the avi is 
>> >> > > reported
>> >> > > as 100 fps.
>> >> >
>> >> > that seems to be a regression since
>> >> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
>> >> >
>> >> > IIRC the intended timebase is 1/50 for this kind of content
>> >> > (allowing the support of interlaced and field duplicated content to
>> >> >  appear later)
>> >> >
>> >> >
>> >> > > And with or without the code, the resulting files play the
>> >> > > same with the players i tried.
>> >> >
>> >> > Higher framerates / finer timebases need noticably more space to
>> >> > be stored in avi, thats not the case for other formats and thats
>> >> > one reason why avi is treated as a special case.
>> >> >
>> >> > ill try to look tomorrow why its 100fps since the previous
>> >> > codecpar patches. Though 100fps is not nearly as bad as 600fps
>> >> > 600 has ~6 times the overhead
>> >>
>> >> This regression is caused by ticks_per_frame beiing incorrect
>> >>
>> >> Ill send a patch to fix this
>> >
>> > patch attached
>> >
>>
>> We don't have time_base in codecpar, so why do we need ticks per frame in it?
>
> We need both in some form probably
> For this regression ticks_per_frame ATM is enough.
> For time_base theres code to copy/access it bypassing codecpar
>
> The way it seems to be currently is that there are fields which
> are needed and either they are
> in codecpar or
> theres some tricks to access them from code sheduled to be removed
>  (which will work only as long as the code isnt removed)
> or things just dont work.
>
>
>>
>> Which time_base does it modify the interpretation of? The field should
>> be bundled with that, then.
>
> the AVCodecContext one, ticks_per_frame is already in AVCodecContext
> the AVCodecContext ticks_per_frame though is not exported after codecpar
> while the codec timebase still is just not vissibly through codecpar
>

Maybe that part should be fixed then, wherever we export that to
AVCodecContext, also set its ticks_per_frame properly?
It just feels bad to export a property here that standing alone
doesn't mean anything.

So fix the export of ticks_per_frame for AVCodecContext, and if later
on we decide we really do need time_base in AVCodecParameters, and
can't fix whatever needs it differently, we can then include both in
there.

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Tue, Sep 06, 2016 at 11:32:24AM -0300, James Almer wrote:
> On 9/6/2016 9:57 AM, Clément Bœsch wrote:
> >> We don't have time_base in codecpar, so why do we need ticks per frame in 
> >> it?
> >> > 
> >> > Which time_base does it modify the interpretation of? The field should
> >> > be bundled with that, then.
> > When do we have a mismatch of st->time_base and that "codec time base"?
> 
> st->time_base can be anything. Matroska for example is always 1/1000,
> and mpegps 1/9.

> "Codec time_base" seems to be codec frame_rate * ticks_per_frame, so
> usually the same as frame_rate, except for codecs like h264 and mpeg2
> where it's twice that.

this only works when codecs use the frame or field rate as basis for
their timebase

With some codecs that is syntactically not even possible
MPEG4 (ISO/IEC 14496-2) stores its timebase as 1/N not M/N for vfr
with for example 3/1001 that would be different (1/3) than the
frame rate (3/1001) (which may be variable)


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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote:
> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
>  wrote:
> > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
> >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> >> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> >> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> >> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> >> > > >> From: Clément Bœsch 
> >> > > >>
> >> > > >> These adjusted codec fields do not seem to be in use anymore and 
> >> > > >> prevent
> >> > > >> the convert of ffmpeg*.c to codecpar.
> >> > > >
> >> > > >  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
> >> > > > fails, no output anymore
> >> > > >
> >> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> >> > > > the output now has 600fps
> >> > >
> >> > > Even with this code in place the resulting stream in the avi is 
> >> > > reported
> >> > > as 100 fps.
> >> >
> >> > that seems to be a regression since
> >> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
> >> >
> >> > IIRC the intended timebase is 1/50 for this kind of content
> >> > (allowing the support of interlaced and field duplicated content to
> >> >  appear later)
> >> >
> >> >
> >> > > And with or without the code, the resulting files play the
> >> > > same with the players i tried.
> >> >
> >> > Higher framerates / finer timebases need noticably more space to
> >> > be stored in avi, thats not the case for other formats and thats
> >> > one reason why avi is treated as a special case.
> >> >
> >> > ill try to look tomorrow why its 100fps since the previous
> >> > codecpar patches. Though 100fps is not nearly as bad as 600fps
> >> > 600 has ~6 times the overhead
> >>
> >> This regression is caused by ticks_per_frame beiing incorrect
> >>
> >> Ill send a patch to fix this
> >
> > patch attached
> >
> 
> We don't have time_base in codecpar, so why do we need ticks per frame in it?

We need both in some form probably
For this regression ticks_per_frame ATM is enough.
For time_base theres code to copy/access it bypassing codecpar

The way it seems to be currently is that there are fields which
are needed and either they are
in codecpar or
theres some tricks to access them from code sheduled to be removed
 (which will work only as long as the code isnt removed)
or things just dont work.


> 
> Which time_base does it modify the interpretation of? The field should
> be bundled with that, then.

the AVCodecContext one, ticks_per_frame is already in AVCodecContext
the AVCodecContext ticks_per_frame though is not exported after codecpar
while the codec timebase still is just not vissibly through codecpar

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Clément Bœsch]

On Tue, Sep 06, 2016 at 11:32:24AM -0300, James Almer wrote:
> On 9/6/2016 9:57 AM, Clément Bœsch wrote:
> >> We don't have time_base in codecpar, so why do we need ticks per frame in 
> >> it?
> >> > 
> >> > Which time_base does it modify the interpretation of? The field should
> >> > be bundled with that, then.
> > When do we have a mismatch of st->time_base and that "codec time base"?
> 
> st->time_base can be anything. Matroska for example is always 1/1000,
> and mpegps 1/9.
> "Codec time_base" seems to be codec frame_rate * ticks_per_frame, so
> usually the same as frame_rate, except for codecs like h264 and mpeg2
> where it's twice that.

But you could deduce one from another if you have ticks per frame? That
means we could have only AVStream.{time_base,ticks_per_frame} and we will
be able to deal with all the situations were lavf/mux* need such info, and
thus not need to transmit anything in AVCodecParameters?

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[James Almer]

On 9/6/2016 9:57 AM, Clément Bœsch wrote:
>> We don't have time_base in codecpar, so why do we need ticks per frame in it?
>> > 
>> > Which time_base does it modify the interpretation of? The field should
>> > be bundled with that, then.
> When do we have a mismatch of st->time_base and that "codec time base"?

st->time_base can be anything. Matroska for example is always 1/1000,
and mpegps 1/9.
"Codec time_base" seems to be codec frame_rate * ticks_per_frame, so
usually the same as frame_rate, except for codecs like h264 and mpeg2
where it's twice that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Clément Bœsch]

On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote:
> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
>  wrote:
> > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
> >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> >> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> >> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> >> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> >> > > >> From: Clément Bœsch 
> >> > > >>
> >> > > >> These adjusted codec fields do not seem to be in use anymore and 
> >> > > >> prevent
> >> > > >> the convert of ffmpeg*.c to codecpar.
> >> > > >
> >> > > >  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
> >> > > > fails, no output anymore
> >> > > >
> >> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> >> > > > the output now has 600fps
> >> > >
> >> > > Even with this code in place the resulting stream in the avi is 
> >> > > reported
> >> > > as 100 fps.
> >> >
> >> > that seems to be a regression since
> >> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
> >> >
> >> > IIRC the intended timebase is 1/50 for this kind of content
> >> > (allowing the support of interlaced and field duplicated content to
> >> >  appear later)
> >> >
> >> >
> >> > > And with or without the code, the resulting files play the
> >> > > same with the players i tried.
> >> >
> >> > Higher framerates / finer timebases need noticably more space to
> >> > be stored in avi, thats not the case for other formats and thats
> >> > one reason why avi is treated as a special case.
> >> >
> >> > ill try to look tomorrow why its 100fps since the previous
> >> > codecpar patches. Though 100fps is not nearly as bad as 600fps
> >> > 600 has ~6 times the overhead
> >>
> >> This regression is caused by ticks_per_frame beiing incorrect
> >>
> >> Ill send a patch to fix this
> >
> > patch attached
> >
> 
> We don't have time_base in codecpar, so why do we need ticks per frame in it?
> 
> Which time_base does it modify the interpretation of? The field should
> be bundled with that, then.

When do we have a mismatch of st->time_base and that "codec time base"?

What if the ticks_per_frame was at AVStream level?

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Hendrik Leppkes]

On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
 wrote:
> On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
>> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
>> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
>> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
>> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
>> > > >> From: Clément Bœsch 
>> > > >>
>> > > >> These adjusted codec fields do not seem to be in use anymore and 
>> > > >> prevent
>> > > >> the convert of ffmpeg*.c to codecpar.
>> > > >
>> > > >  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
>> > > > fails, no output anymore
>> > > >
>> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
>> > > > the output now has 600fps
>> > >
>> > > Even with this code in place the resulting stream in the avi is reported
>> > > as 100 fps.
>> >
>> > that seems to be a regression since
>> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
>> >
>> > IIRC the intended timebase is 1/50 for this kind of content
>> > (allowing the support of interlaced and field duplicated content to
>> >  appear later)
>> >
>> >
>> > > And with or without the code, the resulting files play the
>> > > same with the players i tried.
>> >
>> > Higher framerates / finer timebases need noticably more space to
>> > be stored in avi, thats not the case for other formats and thats
>> > one reason why avi is treated as a special case.
>> >
>> > ill try to look tomorrow why its 100fps since the previous
>> > codecpar patches. Though 100fps is not nearly as bad as 600fps
>> > 600 has ~6 times the overhead
>>
>> This regression is caused by ticks_per_frame beiing incorrect
>>
>> Ill send a patch to fix this
>
> patch attached
>

We don't have time_base in codecpar, so why do we need ticks per frame in it?

Which time_base does it modify the interpretation of? The field should
be bundled with that, then.

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> > > >> From: Clément Bœsch 
> > > >>
> > > >> These adjusted codec fields do not seem to be in use anymore and 
> > > >> prevent
> > > >> the convert of ffmpeg*.c to codecpar.
> > > > 
> > > >  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
> > > > fails, no output anymore
> > > > 
> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> > > > the output now has 600fps
> > > 
> > > Even with this code in place the resulting stream in the avi is reported
> > > as 100 fps.
> > 
> > that seems to be a regression since
> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
> > 
> > IIRC the intended timebase is 1/50 for this kind of content
> > (allowing the support of interlaced and field duplicated content to
> >  appear later)
> > 
> > 
> > > And with or without the code, the resulting files play the
> > > same with the players i tried.
> > 
> > Higher framerates / finer timebases need noticably more space to
> > be stored in avi, thats not the case for other formats and thats
> > one reason why avi is treated as a special case.
> > 
> > ill try to look tomorrow why its 100fps since the previous
> > codecpar patches. Though 100fps is not nearly as bad as 600fps
> > 600 has ~6 times the overhead
> 
> This regression is caused by ticks_per_frame beiing incorrect
> 
> Ill send a patch to fix this

patch attached

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
From 66b4f6da72ca7867b9d1c6c7936161cf1482a73b Mon Sep 17 00:00:00 2001
From: Michael Niedermayer 
Date: Tue, 6 Sep 2016 13:39:36 +0200
Subject: [PATCH] avcodec: Add ticks_per_frame to AVCodecParameters

Fixes regressions in stream copy timebase handling
(for example with AVI output being incorrectly 100fps)

Signed-off-by: Michael Niedermayer 
---
 libavcodec/avcodec.h| 8 
 libavcodec/utils.c  | 3 +++
 tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
 tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +-
 tests/ref/fate/concat-demuxer-simple1-lavf-mxf  | 2 +-
 tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10  | 2 +-
 tests/ref/fate/concat-demuxer-simple2-lavf-ts   | 2 +-
 7 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index e2dad5d..3ec8814 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4091,6 +4091,14 @@ typedef struct AVCodecParameters {
  * Audio only. Number of samples to skip after a discontinuity.
  */
 int seek_preroll;
+/**
+ * For some codecs, the time base is closer to the field rate than the frame rate.
+ * Most notably, H.264 and MPEG-2 specify time_base as half of frame duration
+ * if no telecine is used ...
+ *
+ * Set to time_base ticks per frame. Default 1, e.g., H.264/MPEG-2 set it to 2.
+ */
+int ticks_per_frame;
 } AVCodecParameters;
 
 /**
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 0f6d0e7..da24f92 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -4043,6 +4043,7 @@ static void codec_parameters_reset(AVCodecParameters *par)
 par->sample_aspect_ratio = (AVRational){ 0, 1 };
 par->profile = FF_PROFILE_UNKNOWN;
 par->level   = FF_LEVEL_UNKNOWN;
+par->ticks_per_frame = 1;
 }
 
 AVCodecParameters *avcodec_parameters_alloc(void)
@@ -4098,6 +4099,7 @@ int avcodec_parameters_from_context(AVCodecParameters *par,
 par->bits_per_raw_sample   = codec->bits_per_raw_sample;
 par->profile   = codec->profile;
 par->level = codec->level;
+par->ticks_per_frame   = codec->ticks_per_frame;
 
 switch (par->codec_type) {
 case AVMEDIA_TYPE_VIDEO:
@@ -4153,6 +4155,7 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
 codec->bits_per_raw_sample   = par->bits_per_raw_sample;
 codec->profile   = par->profile;
 codec->level = par->level;
+codec->ticks_per_frame   = par->ticks_per_frame;
 
 switch (par->codec_type) {
 case AVMEDIA_TYPE_VIDEO:
diff --git a/tests/ref/fate/concat-demuxer-extended-lavf-mxf b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
index b894938..677a354 100644
--- a/tests/ref/fate/concat-demuxer-extended-lavf-mxf
+++ b/tests/ref/fate/concat-demuxer-extended-lavf-mxf
@@ -1 +1 @@
-0aa1ca6ff6e2e5aa926454d22fdaecd5 

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> > >> From: Clément Bœsch 
> > >>
> > >> These adjusted codec fields do not seem to be in use anymore and prevent
> > >> the convert of ffmpeg*.c to codecpar.
> > > 
> > >  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
> > > fails, no output anymore
> > > 
> > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> > > the output now has 600fps
> > 
> > Even with this code in place the resulting stream in the avi is reported
> > as 100 fps.
> 
> that seems to be a regression since
> 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
> 
> IIRC the intended timebase is 1/50 for this kind of content
> (allowing the support of interlaced and field duplicated content to
>  appear later)
> 
> 
> > And with or without the code, the resulting files play the
> > same with the players i tried.
> 
> Higher framerates / finer timebases need noticably more space to
> be stored in avi, thats not the case for other formats and thats
> one reason why avi is treated as a special case.
> 
> ill try to look tomorrow why its 100fps since the previous
> codecpar patches. Though 100fps is not nearly as bad as 600fps
> 600 has ~6 times the overhead

This regression is caused by ticks_per_frame beiing incorrect

Ill send a patch to fix this


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn


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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> >> From: Clément Bœsch 
> >>
> >> These adjusted codec fields do not seem to be in use anymore and prevent
> >> the convert of ffmpeg*.c to codecpar.
> > 
> >  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
> > fails, no output anymore
> > 
> > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> > the output now has 600fps
> 
> Even with this code in place the resulting stream in the avi is reported
> as 100 fps.

that seems to be a regression since
6f69f7a8bf6a0d013985578df2ef42ee6b1c7994

IIRC the intended timebase is 1/50 for this kind of content
(allowing the support of interlaced and field duplicated content to
 appear later)


> And with or without the code, the resulting files play the
> same with the players i tried.

Higher framerates / finer timebases need noticably more space to
be stored in avi, thats not the case for other formats and thats
one reason why avi is treated as a special case.

ill try to look tomorrow why its 100fps since the previous
codecpar patches. Though 100fps is not nearly as bad as 600fps
600 has ~6 times the overhead

Thanks

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

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[James Almer]

On 9/5/2016 10:04 PM, James Almer wrote:
> On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
>> On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
>>> From: Clément Bœsch 
>>>
>>> These adjusted codec fields do not seem to be in use anymore and prevent
>>> the convert of ffmpeg*.c to codecpar.
>>
>>  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
>> fails, no output anymore
>>
>> ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
>> the output now has 600fps
> 
> Even with this code in place the resulting stream in the avi is reported
> as 100 fps. And with or without the code, the resulting files play the
> same with the players i tried.
> mpc-hc suffers from choppy playback with both files due to tons of dropped
> frames per second, and WMP directly refuses to play it. Only ffplay and
> mpv play both fine.

So apparently libavformat's av_dump_format() reports the stream time base
as fps as well, at least with these files, which explains the odd 100 and
600 fps.
libav's av_dump_format() in contrast correctly reports the fps as 25 in
both.

Both check st->avg_frame_rate to print the fps values.

> 
>>
>> ./ffmpeg -i ~/tickets/236/fcp_export8.mov -codec copy -map 0 out.mov
>> something goes terribly wrong with the timecode tracks
>> "fps 2997 is too large"
>>
>> If you want more cases that this breaks, it should be easy to find
>> i think fate does not test stream copy very well
>>
>> [...]
>>
>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[James Almer]

On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
>> From: Clément Bœsch 
>>
>> These adjusted codec fields do not seem to be in use anymore and prevent
>> the convert of ffmpeg*.c to codecpar.
> 
>  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
> fails, no output anymore
> 
> ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> the output now has 600fps

Even with this code in place the resulting stream in the avi is reported
as 100 fps. And with or without the code, the resulting files play the
same with the players i tried.
mpc-hc suffers from choppy playback with both files due to tons of dropped
frames per second, and WMP directly refuses to play it. Only ffplay and
mpv play both fine.

> 
> ./ffmpeg -i ~/tickets/236/fcp_export8.mov -codec copy -map 0 out.mov
> something goes terribly wrong with the timecode tracks
> "fps 2997 is too large"
> 
> If you want more cases that this breaks, it should be easy to find
> i think fate does not test stream copy very well
> 
> [...]
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Mon, Sep 05, 2016 at 05:49:10PM +0200, Clément Bœsch wrote:
> On Mon, Sep 05, 2016 at 05:41:25PM +0200, Michael Niedermayer wrote:
> > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> > > From: Clément Bœsch 
> > > 
> > > These adjusted codec fields do not seem to be in use anymore and prevent
> > > the convert of ffmpeg*.c to codecpar.
> > 
> >  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
> > fails, no output anymore
> > 
> > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> > the output now has 600fps
> > 
> > ./ffmpeg -i ~/tickets/236/fcp_export8.mov -codec copy -map 0 out.mov
> > something goes terribly wrong with the timecode tracks
> > "fps 2997 is too large"
> > 
> > If you want more cases that this breaks, it should be easy to find
> > i think fate does not test stream copy very well
> 
> Thanks. Such fate tests are likely not very hard to add and would be very
> welcome.

ok, ill see if i can add tests for these

thx

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Clément Bœsch]

On Mon, Sep 05, 2016 at 05:41:25PM +0200, Michael Niedermayer wrote:
> On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> > From: Clément Bœsch 
> > 
> > These adjusted codec fields do not seem to be in use anymore and prevent
> > the convert of ffmpeg*.c to codecpar.
> 
>  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
> fails, no output anymore
> 
> ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> the output now has 600fps
> 
> ./ffmpeg -i ~/tickets/236/fcp_export8.mov -codec copy -map 0 out.mov
> something goes terribly wrong with the timecode tracks
> "fps 2997 is too large"
> 
> If you want more cases that this breaks, it should be easy to find
> i think fate does not test stream copy very well

Thanks. Such fate tests are likely not very hard to add and would be very
welcome.

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> From: Clément Bœsch 
> 
> These adjusted codec fields do not seem to be in use anymore and prevent
> the convert of ffmpeg*.c to codecpar.

 ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy out.mxf
fails, no output anymore

./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
the output now has 600fps

./ffmpeg -i ~/tickets/236/fcp_export8.mov -codec copy -map 0 out.mov
something goes terribly wrong with the timecode tracks
"fps 2997 is too large"

If you want more cases that this breaks, it should be easy to find
i think fate does not test stream copy very well

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

Never trust a computer, one day, it may think you are the virus. -- Compn


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