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 <clem...@stupeflix.com> > > >> > > >> 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
