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. |
20th May 2015, 21:28 | #61 | Link | ||
Registered User
Join Date: Dec 2009
Posts: 63
|
Quote:
Code:
BlankClip(length=21474000, width=320, height=240, pixel_type="yv12", fps=24000, fps_denominator=1001, audio_rate=0) 21473965 when fps=23.976 21474017 when fps=23.97602 21474017 when fps=23.9760239760 frame duration is calculated like this and stored as integer (fractional part is rounded, we lose it): Code:
__int64 m_avgframe = (__int64)(10000000ll / fps + 0.5) Code:
10000000/23.976 = 417083.75 -> 417084 10000000/23.97602 = 417083.402 -> 417083 10000000/23.9760239760 = 417083.333 -> 417083 Not pretty much tested, I need to test it a little more before sharing, and I'm not sure I didn't broke something somewhere, overflowing due to different data types and so one. But at least it seems to work fine with this huge video, adding Info() to the first (source) script and ShowFrameNumber() to another script, that uses DSS2 to open the first script, showing that both total frames count and current frame number is the same. Quote:
A first few kb of a video file most probably will be useless to me, because I don't know how to parse one or another container\format, headers, and DSS2 doesn't do such work.. Only if a problem can be reproduced with such a sample - then it can be useful to me. |
||
21st May 2015, 17:06 | #62 | Link | ||
Registered User
Join Date: Nov 2005
Posts: 583
|
Quote:
I tried to replicate the result using the 1003 frame extract, but had the opposite: DSS2mod reported 1003 frames but 3 less for FFVS. Quote:
DSS2 appears to have read the wrong fps from the mkv container, while FFVS was somehow smart enough to avoid it. Many thanks and best regards. |
||
24th May 2015, 15:25 | #63 | Link | |
Registered User
Join Date: Dec 2009
Posts: 63
|
Here is my findings about higher total frames count, even when fps is set exactly. All those files have the first frame's timecode not starting from zero, this extra-time results in some extra-frames added by DSS2 at the beginning, which are actually a dub of the first "real" frame. Something like this: 1-1-1-1-2-3-4-5 - the first three number one is what I'm talking about. Discarding them may results in out-of-sync, or opposite - I don't know, most probably it depends on how audio part is handled. So I decided to make it optional by adding a new key "tc_offset" (int), negative values will use the first frame's time code as the offset (aka Auto mode). Zero - means no offset, currently it is default value, everything works like before. And positive values - user-specified offset in DS-time format, for example 400000 means 40ms.
And as said before, fps handling has changed. To set fps there is now two keys: "fps" (float) and new "fps_den" (int). If "fps_den"(ominator), not set or equal 0, "fps" is treated as float and passed as an argument to AssumeFPS. AssumeFPS makes nice numerator/denominator values from it, and then DSS2 uses it. But when both "fps" and "fps_den" is set and >0, "fps" treated as fps_numerator, decimal part is truncated. AssumeFPS not involved in this case, because both numerator/denominator are known. Test build, src diff also included if any interested in it. If there is something weird or wrong as you think - please let me know, I'm not a big expert in DS and C++ programming . About 30.303fps detection in one of the samples - AvgTimePerFrame is 330000 (33ms) and the first frame's start-end timecodes also == 330000. Isn't it 30.303fps? FFmpeg also report for this file: Quote:
|
|
25th May 2015, 18:51 | #64 | Link | ||
Registered User
Join Date: Nov 2005
Posts: 583
|
Quote:
A demuxed/remuxed clip (without audio) created from the sample sent showed FFVS dropping 4 frames at the end. 4 new frames were added at the beginning to maintain 1000 frame count. Old DSS2mod has no issue. Apparently demuxong/remuxing didn't help with the issue. Quote:
This is the original ffmpeg report: Code:
Metadata: duration 4882.51 moovPosition 48.00 width 1920.00 height 1080.00 videocodecid avc1 audiocodecid mp4a avcprofile 100.00 avclevel 40.00 aacaot 2.00 videoframerate 29.97 audiosamplerate 44100.00 audiochannels 2.00 tags: ©too Lavf53.24.2 trackinfo: length 14632800.00 timescale 2997.00 language und sampledescription: sampletype avc1 length 215318528.00 timescale 44100.00 language und Metadata: moovPosition : 48 avcprofile : 100 avclevel : 40 aacaot : 2 videoframerate : 30 audiochannels : 2 ©too : Lavf53.24.2 length : 215318528 timescale : 44100 sampletype : mp4a Duration: 01:21:22.51, start: 0.000000, bitrate: N/A Stream #0:0, 41, 1/1000: Video: h264 (High), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 30.30 fps, 29.97 tbr, 1k tbn, 59.94 tbc Stream #0:1, 58, 1/1000: Audio: aac (LC), 44100 Hz, stereo, fltp |
||
29th May 2015, 08:20 | #65 | Link |
Registered User
Join Date: Nov 2005
Posts: 583
|
Greetings forclip.
1. What is the convention followed when dealing with video delay? It would appear delay is ignored when demuxing, and by FFVS2.20 as well, is it not? 2. Is frame insertion the default now? How to disable it? 3. Frame insertion doesn't seems to work for mkv when no audio track present. 4. Dropped frames at the end for ts, the number equal to the number of inserted frames. No such problem for mkv. 5. Adding AssumeFPS(30000,1001) does not rectify wrong fps issue. Beethoven clip still reporting 1000/33 fps. Many thanks and best regards. |
29th May 2015, 22:00 | #66 | Link |
Registered User
Join Date: Dec 2009
Posts: 63
|
1.1 The splitter\decoder decides.
2. When tc_offset=0 everything works like before, and it is set to 0 by default. That means if the first actual frame's timestamp > 0, DSS2 will add as much repeated frames before it as much can fit in this gap (between 0 and actual timestamp) - this is from the original DSS2. When "tc_offset=-1" the gap handled in another way, no duplicated frames will be added - this is new feature. 3., 1.2 That means the first frame's time code == 0, or the gap is less than one frame duration. Really, there is no point to apply a delay in case there is only one track. Delay - relative to what in this case? At least MKVMerge (7.6.0 at hands) ignores the Delay field, it adds "--sync" "0:10000" (10 seconds delay) to CLI, but I can't see any delay in resulting file and the playback starts right after opening this file in a player. 4. For now I only have tested with this (broken?) sample, and it seems Duration reported by LAV less than actual duration, so few frames at the end can't be accessed with DSS1\2. Reported duration is 4503600000, but even after a frame with timecode 4503649222 there is ~44 frames available, up to 4513449222 (with some drops at the end). Now your new samples (thanks!). 40.ts - reported duration is 11980000000 and there is no frames available after 11980003333, so duration is fine and total frames count (29950) for this duration is correct. The first frame arrives with 403333 timestamp, meaning one extra frame added by DSS2 with tc_offset=0 (default), or not added with tc_offset=-1 - in this case total frames count = 29949. This is correct. m1.ts - reported duration is 100000000, but there is two frames available up to 100800000 - they are unaccessible for us, total frames count (250) is wrong. And the same thing with tc_offset: if we removed extra frames (tc_offset=-1), total frames count also becomes less by its number. So incorrect Duration reported for some files - probably the only problem. I don't think I can do anything.. Only by introducing some kind of indexing to see the real frames count\duration?! But there is FFMS2\L-SMASH\DGIndex already exist, the point of DSS2 existing (at least for me) - is to avoid indexing step. But without it we are limited to what DS reported to us. 5. You don't need to add AssumeFPS to DSS2, it will not change how DSS2 handle fps. You need to set actual fps by using "fps" (or "fps" and "fps_den") key - only this way you can tell DSS2 how to handle your file. If fps auto detection doesn't work for your file and results in incorrect fps - you need to set correct value by yourself! When previously I said that AssumeFPS is now internally used, I doesn't meant that it is used like this: Code:
DSS2(...) AssumeFPS(fps) Code:
BlankClip().AssumeFPS(fps) numerator = FrameRateNumerator() denominator = FrameRateDenominator() DSS2(..., fps=numerator, fps_den=denominator) |
31st May 2015, 14:34 | #67 | Link | |
Registered User
Join Date: Nov 2005
Posts: 583
|
Greetings ofrclip. Many thanks for the detail explanation.
1. Does FFVS behave like DSS2mod in a system with just LAV and FFdshow(low merit)? Quote:
Code:
DSS2(..., fps=30000, fps_den=1001) 3. FFVS vs DSS2: Well, either DSS2 got it wrong, or FFVS had trouble with both the ts clips, dropping frames at the start and repeating frames at the end. Couldn't get the 2.22 beta built to work here, suggestions appreciated. Many thanks and best regards. Last edited by mariner; 1st June 2015 at 07:05. Reason: Wrong srceen cap. |
|
31st May 2015, 22:06 | #68 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Myrsloik just fixed some first-frame bugs in the latest test build, check it out or wait a couple days for the final release. That might change the behavior you're seeing with FFVS.
|
2nd June 2015, 22:21 | #69 | Link | ||
Registered User
Join Date: Dec 2009
Posts: 63
|
Quote:
Quote:
Or both. Try with other source-filters: LWLibavVideoSource, DGDecNV (requires an Nvidia video card), DGDecIM (beta, requires QuickSync, but also works in software decoding mode; I have no idea if SW-mode is limited to Intel-only CPU, probably not, but I'm on Intel and for me it works anyway).. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|