Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
14th February 2011, 19:25 | #1041 | Link |
Registered User
Join Date: Aug 2008
Location: The Land Of Dracula (Romania - EU)
Posts: 934
|
it looks like everybody (JEEB, Komisar, X5-452) still use FFMS2 2.14.2 (svn-432)...x264.nl is using svn-431...
_
__________________
if you ask a question and somebody give you the correct answer don't forget to leave a "thank you" note... Visit The Land Of Dracula (Romania - EU)! Last edited by b66pak; 19th February 2011 at 11:54. |
20th February 2011, 21:03 | #1042 | Link |
Registered User
Join Date: Aug 2008
Location: The Land Of Dracula (Romania - EU)
Posts: 934
|
@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: Code:
Seems stream 0 codec frame rate differs from container frame rate: 47.95 (20000000/417083) -> 23.98 (20000000/834166) Code:
[21:56:09.312] ffms [info]: 1280x720p 1:1 @ 24000/1001 fps (vfr) Code:
Track # 1 Info - TrackID 1 - TimeScale 1000000000 _
__________________
if you ask a question and somebody give you the correct answer don't forget to leave a "thank you" note... Visit The Land Of Dracula (Romania - EU)! |
20th February 2011, 21:43 | #1043 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
Also, how about a sample file? |
|
20th February 2011, 21:53 | #1044 | Link |
Registered User
Join Date: Aug 2008
Location: The Land Of Dracula (Romania - EU)
Posts: 934
|
"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? _
__________________
if you ask a question and somebody give you the correct answer don't forget to leave a "thank you" note... Visit The Land Of Dracula (Romania - EU)! Last edited by b66pak; 20th February 2011 at 21:58. |
21st February 2011, 00:06 | #1045 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
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. Last edited by TheFluff; 21st February 2011 at 00:11. |
|
21st February 2011, 01:36 | #1046 | Link |
Registered User
Join Date: Aug 2008
Location: The Land Of Dracula (Romania - EU)
Posts: 934
|
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...
_
__________________
if you ask a question and somebody give you the correct answer don't forget to leave a "thank you" note... Visit The Land Of Dracula (Romania - EU)! |
21st February 2011, 19:55 | #1047 | Link |
Registered User
Join Date: Aug 2008
Location: The Land Of Dracula (Romania - EU)
Posts: 934
|
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: Code:
Track # 1 Info - TrackID 1 - TimeScale 1000 _
__________________
if you ask a question and somebody give you the correct answer don't forget to leave a "thank you" note... Visit The Land Of Dracula (Romania - EU)! |
22nd February 2011, 03:49 | #1049 | Link |
Registered User
Join Date: Aug 2008
Location: The Land Of Dracula (Romania - EU)
Posts: 934
|
kenuri-_9 posted an explanation here:
_
__________________
if you ask a question and somebody give you the correct answer don't forget to leave a "thank you" note... Visit The Land Of Dracula (Romania - EU)! Last edited by b66pak; 22nd February 2011 at 20:58. |
1st March 2011, 11:24 | #1050 | Link |
Registered User
Join Date: Aug 2008
Posts: 65
|
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. |
1st March 2011, 13:01 | #1051 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
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.
|
1st March 2011, 13:16 | #1052 | Link | |
Registered User
Join Date: Aug 2008
Posts: 65
|
Quote:
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? |
|
1st March 2011, 13:25 | #1053 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
|
|
14th March 2011, 05:59 | #1054 | Link |
Registered User
Join Date: Mar 2004
Posts: 889
|
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. |
14th March 2011, 07:17 | #1055 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
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. Last edited by TheFluff; 14th March 2011 at 07:40. |
|
14th March 2011, 07:52 | #1056 | Link |
Registered User
Join Date: Mar 2004
Posts: 889
|
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. |
14th March 2011, 08:02 | #1057 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
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. |
|
14th March 2011, 15:41 | #1058 | Link |
warpsharpened
Join Date: Feb 2007
Posts: 787
|
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. Last edited by TheRyuu; 15th March 2011 at 11:01. |
1st April 2011, 12:52 | #1060 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
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. Last edited by kemuri-_9; 1st April 2011 at 13:09. |
|
|