FFmpegSource

[b66pak]

it looks like everybody (JEEB, Komisar, X5-452) still use FFMS2 2.14.2 (svn-432)...x264.nl is using svn-431...
_

[b66pak]

@TheFluff x264.nl is using now "2011-02-19 00:59:01 SVN: ffmpegsource revision 448" but timescale/timebase is still returning HUGE values...can you investigate?

source:

Seems stream 0 codec frame rate differs from container frame rate: 47.95 (20000000/417083) -> 23.98 (20000000/834166)

x264 info:

[21:56:09.312] ffms [info]: 1280x720p 1:1 @ 24000/1001 fps (vfr)

resulting mp4 (x264 gpac muxer):

Track # 1 Info - TrackID 1 - TimeScale 1000000000

if i use ffmpegsource-2.15 for indexing i get the correct timescale/timebase 24000/1001...
_

[TheFluff]

Originally Posted by b66pak

@TheFluff x264.nl is using now "2011-02-19 00:59:01 SVN: ffmpegsource revision 448" but timescale/timebase is still returning HUGE values...can you investigate?

source:

Seems stream 0 codec frame rate differs from container frame rate: 47.95 (20000000/417083) -> 23.98 (20000000/834166)

x264 info:

[21:56:09.312] ffms [info]: 1280x720p 1:1 @ 24000/1001 fps (vfr)

resulting mp4 (x264 gpac muxer):

Track # 1 Info - TrackID 1 - TimeScale 1000000000

if i use ffmpegsource-2.15 for indexing i get the correct timescale/timebase 24000/1001...
_

I don't understand what you're saying at all nor what the problem is nor if it's likely that it's a problem in ffms2 or not. What is "source" and where is it printing that message? It looks like ffmpeg, but who knows? What do you mean by "if I use ffmpegsource-2.15 for indexing"?

Also, how about a sample file?

[b66pak]

"source" is the source file: a mkv with a near 24000/1001 fps encoded using directshowsource...see this for more info...
the report is from ffmpeg: it outline the timescale/timebase of the "source"...

if i use your latest fmpegsource-2.15 to index the "source" and make an avs and feed it to the latest x264.nl build i get a corrected timescale/timebase witch is very good! (20000000/834166 > 24000/1001)...

the question is why can't x264 do the same if its using the latest ffms? can you investigate?
_

[TheFluff]

Originally Posted by b66pak

"source" is the source file: a mkv with a near 24000/1001 fps encoded using directshowsource...see this for more info...
the report is from ffmpeg: it outline the timescale/timebase of the "source"...

if i use your latest fmpegsource-2.15 to index the "source" and make an avs and feed it to the latest x264.nl build i get a corrected timescale/timebase witch is very good! (20000000/834166 > 24000/1001)...

the question is why can't x264 do the same if its using the latest ffms? can you investigate?
_

I haven't looked at the file at all but judging from the description it seems pretty simple. There is no such thing as a CFR Matroska file; there is no real "timebase" in the container, and no container-level framerate either. All frames have timestamps in wallclock nanoseconds (by default; you can change the precision/timecode scale at mux-time if you want to). Hence FFMS2 reports the timebase for MKV's as 1/1000000 or something silly like that (assuming the default timecode scale) because pretty much what it is.

In order to get a "constant" framerate for MKV files that can be reported to things that aren't VFR-aware (like Avisynth), FFMS2 calculates a framerate based on the average frame duration, and then checks if it's "close enough" to a well-known NTSC fraction, and if it is, the otherwise huge fractional value gets corrected to the usual 24000/1001 or 30000/1001.

In this case, as you can see from what x264 says about the framerate, the behavior described above was triggered and the reported "constant" framerate is 24000/1001 (note how x264 says "vfr"; it knows the reported framerate may be complete bogus). The timebase is still 1000000/1, though, and apparently x264 decided to stick with that and pass it through to its MP4 muxer, since it cannot know if there are uneven frame durations or not.

The reason you get a timebase of 24000/1001 when doing it via Avisynth is that Avisynth doesn't store a separate timebase value at all; since it only supports CFR, all frames have the same duration and there's no reason to have a separate timebase. In other words, the framerate is the same as the timebase and the frame number is functionally equivalent with a PTS. x264 never sees the original timebase from the MKV at all when using Avisynth input.

If you know and can GUARANTEE that your source is CFR, you can always force a timebase in one way or another, but if you cannot, the only really correct way to handle it is to keep the original timebase. You could also write some more or less complex algorithm that inspects all frame durations, determines the smallest possible timebase and then converts all timestamps to that, but that will probably cause all sorts of other interesting issues later down the chain instead.


I hope you're sufficiently confused, since you did ask for it. What I'd really like to know though is what real-world problems this issue causes you.

[b66pak]

thank you for the explanation...the problem is that mp4 files with huge timescale/timebase can't be played on any device other than PCs (QTime excluded) and NMTs...
_

[b66pak]

here is a small sample...

on the same "source" mkv i forced the lavf demuxer (instead of ffms - default) and i get a more friendly timescale:

Track # 1 Info - TrackID 1 - TimeScale 1000

now i and really confused...ffms+x264 = big timescale in mp4...lavf+x264 = normal timescale in mp4...
_

[TheFluff]

I have no idea what x264 does or does not do with the lavf demuxer or what lavf might do internally with regards to the timebase of Matroska files. FFMS2 does not use lavf for Matroska.

[b66pak]

kenuri-_9 posted an explanation here:
_

[lintran]

I got problem with both 2.15 vanila and mt version when index this file.
My avs script
----------------------------------------------------------
LoadPlugin("D:\ffmpegsource-2.15\ffms2.dll")
FFVideoSource("D:\thisfile.mov",fpsnum=24000,fpsden=1001)
----------------------------------------------------------
When play .avs by MPC, it was broken when video nearly end.
But everything OK when using 2.14 version.
Could you please figure it out?
Thank you.

[TheFluff]

fpsnum and fpsden are broken in 2.15. They have been fixed in SVN, and I'll probably do a 2.15.1 release to fix them, but until then you can either a) not use them, b) downgrade to 2.14, or c) find someone to compile a SVN version for you.

[lintran]

Originally Posted by TheFluff

fpsnum and fpsden are broken in 2.15. They have been fixed in SVN, and I'll probably do a 2.15.1 release to fix them, but until then you can either a) not use them, b) downgrade to 2.14, or c) find someone to compile a SVN version for you.

Thank you. But do you mean fpsnum and fpsden are always broken in 2.15 or sometime or in some special cases?
Because it only broken with that file that i posted. I tried to test with many other h264 in.mov files (like Apple Trailers), everything are OK. So is it still safe to use?

[TheFluff]

Originally Posted by lintran

Thank you. But do you mean fpsnum and fpsden are always broken in 2.15 or sometime or in some special cases?
Because it only broken with that file that i posted. I tried to test with many other h264 in.mov files (like Apple Trailers), everything are OK. So is it still safe to use?

By broken I mean "it may crash near the end of the video". If it doesn't crash, the output should be fine. See http://code.google.com/p/ffmpegsourc...s/detail?id=41

[henryho_hk]

Can I .....
1) enable "Always skip in-loop H.264 deblocking" as in ffdshow?
2) control the number of threads in the ffmpeg-mt version"?

And the 2.15 version seems to parse/decode VC-1 m2ts files incorrectly (BBC Life Bluray Disc 1's 00026.m2ts which is a clip about color tuning). When I jump to frame 1917, the ffmpeg-mt version (both 32 and 64 bit) shows a grey frame followed by a few corrupted frames... and the vanilla ffmpeg version shows a non-corrupted frame, but of a wrong frame number. If I demux the m2ts file to VC1, both mt and non-mt versions seem to work fine.

[TheFluff]

Originally Posted by henryho_hk

Can I .....
1) enable "Always skip in-loop H.264 deblocking" as in ffdshow?
2) control the number of threads in the ffmpeg-mt version"?

And the 2.15 version seems to parse/decode VC-1 m2ts files incorrectly (BBC Life Bluray Disc 1's 00026.m2ts which is a clip about color tuning). When I jump to frame 1917, the ffmpeg-mt version (both 32 and 64 bit) shows a grey frame followed by a few corrupted frames... and the vanilla ffmpeg version shows a non-corrupted frame, but of a wrong frame number. If I demux the m2ts file to VC1, both mt and non-mt versions seem to work fine.

1) Not at the moment. Noted as a feature request, though. (edit: why do you want to do this anyway?)
2) Yes, use the "threads" parameter to ffvideosource().

As for the m2ts stuff: do you have Haali's media splitter installed? The issue you describe sounds suspiciously like you're trying to seek in a ts with libavformat's demuxer (don't do that unless you've set seekmode=-1 first, or it'll end in tears). In general, ffms2's support for ts/m2ts is pretty poor; you'll get better results if you remux the file to mkv with eac3to or gdsmux first.

[henryho_hk]

1) coz some BD bitrates are so high that there is little need to do any deblock.... and I want to save the CPU for other stuffs.
2) thanks.

m2ts .... I have Haali's splitter installed and so dss2() works (too bad that they dun make any x64 version). I do expect issues from libavf's demuxer but not MT and non-MT versions behaving differently.

[TheFluff]

Originally Posted by henryho_hk

1) coz some BD bitrates are so high that there is little need to do any deblock.... and I want to save the CPU for other stuffs.
2) thanks.

m2ts .... I have Haali's splitter installed and so dss2() works (too bad that they dun make any x64 version). I do expect issues from libavf's demuxer but not MT and non-MT versions behaving differently.

If the bitrate is so high that there's no need to deblock the deblocking filter will actually not get used, so there's not really any significant amount of CPU power to save here.

The MT issues may be ffmpeg or it may be something else, it is a mystery. I don't build it myself so I won't debug it for you. If you upload a small sample where seeking isn't frameaccurate with the vanilla ffmpeg I'll take a look, though.

[TheRyuu]

ffms2-mt-r452.7z
ffms2-mt-r452-avs64.7z

There was a rather large merge a few days ago that brings ffmpeg-mt up to date (first one since 12/2010 I believe). And I guess ffmpegsource got a fix or two since 2.15.

Edit: Added avs64 build.

[zys4416]

Could anyone answer the #987 question? Because I get the same problem now. Thanks a lot!

[kemuri-_9]

FFMS2 does output I420 and not YV12.
megui sucks at handling this, use something else.

I could spit out techno babble here about how the difference between the two doesn't matter (which it doesn't for everything except the VFW interface),
but that won't change the issue that megui doesn't handle it well.