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. |
19th May 2017, 05:40 | #22 | Link |
the Interrogator
Join Date: Oct 2001
Location: DownUnder
Posts: 664
|
Mainly referring to downstream cutting i.e. at the very end of a clip, where it should be no big deal to truncate frames from any given frame through to the end of the clip.
Last edited by JimmyBarnes; 19th May 2017 at 05:51. |
19th May 2017, 05:50 | #23 | Link |
the Interrogator
Join Date: Oct 2001
Location: DownUnder
Posts: 664
|
At Last, the solution!
OK, everything is always easier in hindsight...
Being a longtime WinXP x86 user who'd only recently upgraded to Win10 x64, I assumed that when 32- and 64-bit versions of a program were on offer, the 64-bit one should be used. So when I originally installed x264vfw and it offered both 32- and 64-bit versions, I chose only the 64-bit one (I keep a log). As sneaker_ger suggested, I reinstalled x264vfw, but this time both 32- and 64-bit versions. Now VDubMod 1.5.10.2 opens AVI with x264 without problems, the video stream can be viewed, cut points nominated and the result saved using Direct Stream Copy - just as it used to do under WinXP. Clearly VDM is a 32-bit prog which can't use 64-bit codecs. Curiously VDFM still won't do Direct Stream Copy, but I don't need it now... Thanks to everyone for their contributions. |
19th May 2017, 07:50 | #25 | Link | |||
Unavailable
Join Date: Mar 2009
Location: offline
Posts: 1,480
|
Quote:
Quote:
Quote:
|
|||
19th May 2017, 08:58 | #26 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
The real reason AVI should not be used for an advanced codec like H.264 is that it just doesn't support B-Frames properly (as mariush said, even XVID already had this problem and they used even worse hacks to encode "packed B-Frames" in AVI), you don't get correct timestamps and decoders need to implement all sorts of hacks to somehow "guess" timestamps for H.264 in AVI (which sometimes works, but sometimes doesn't, resulting sync problems). The real question is why would you prefer AVI when you can use something much better suited to store H.264?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
19th May 2017, 12:01 | #28 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
there is a footnote 41 "B-frames in an AVI file are a problem only for the ancient Video-for-Windows API, not for the AVI container itself." I've no idea who wrote it, but do you think this article is wrong? Can you name usage case when h264 in avi is wrong, given that all the following is met: * CFR * encoding and decoding is done with something that knows what to do, e.g. ffmpeg.exe asking because of curiosity.
__________________
VirtualDub2 |
|
19th May 2017, 17:03 | #32 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
If you cut through references you end up with stray/missing slices. That's just the way it is. So if softwares specifically designed to edit H.264 re-encode on such cut points you can assume they do it for a good reason. If VirtualDub that was designed around VfW does not do that it should raise your eyebrows. Playback behavior on such points can be erratic.
|
19th May 2017, 19:40 | #33 | Link | |
the Interrogator
Join Date: Oct 2001
Location: DownUnder
Posts: 664
|
Quote:
Look, I got the answer to my problem, its clear this has become a a discussion on the merits or otherwise of MKV / AVI. You are convinced your POV is correct just as I am mine, there is no point continuing such a discussion. Last edited by JimmyBarnes; 19th May 2017 at 19:45. |
|
19th May 2017, 21:01 | #34 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
AVI also doesn't support formats like AAC, and has a larger overhead than MKV. Cutting at keyframes is done because cutting anywhere else would effectively result in a corrupted stream. They got around this in the past by cutting at the keyframe then re-encoding to the cutpoint, then appending it to the original stream. It's messy and not really a direct steam copy. Even x264 through the VFW interface was a hack and not supported by the x264 development team. Support came through unofficial hack. Only reason to use AVI in 2012, let alone 2017, is for old stand alone players that don't support MKV or MP4, but even these would support at least MP4 if they support h264.
Virtualdubmod is ancient from a software perspective, and VFW is deprecated and will never be updated apart from it being removed entirely; I thought it already had. I would consider updating your whole lot of tools. Why the need to make all the cuts in the video? Reasons for your specific needs would be helpful. Why the need for encoding then cutting through direct stream copy? Why not cut when doing the initial encode? |
19th May 2017, 21:07 | #35 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
|
19th May 2017, 21:21 | #36 | Link |
Registered sausage
Join Date: May 2012
Posts: 78
|
Code:
<pengvado> <Dark_Shikari> if a fansubber or DVD rip group uploaded an H.264-in-AVI file they'd get laughed off the internet <Dark_Shikari> Probably <pengvado> but asp-in-avi wouldn't be laughed at <Dark_Shikari> of course not, ASP in AVI is normal unless you want softsubs <pengvado> and asp-in-avi requires exactly the same ugly hacks <Dark_Shikari> Probably because its been that way so long that everyone is accustomed to it <pengvado> which just goes to show that our campaign to use a new codec as an excuse to tell people to upgrade their container is working Last edited by Andouille; 19th May 2017 at 21:24. |
27th May 2017, 09:34 | #38 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
I ran a few little encodes with the vfw version of x264 and VirtualDub. They were each encoded with the default x264 settings. I only changed the output options or checked the zero latency option. My test encodes had 418 frames. When I used the "write to a file" option, the first keyframe was at frame zero, and the next at frame 98. I cut the first 50 frames and saved a new AVI using direct stream copy. I did the same for the other test encodes. For the encode written directly to a file, nothing was cut and the new AVI still had 418 frames. The result was exactly the same for the encode with the VirtualDub hack enabled and using the vfw output method, whatever that does. The first 50 frames couldn't be cut. For the vfw encode without the VirtualDub hack enabled, the first 48 frames weren't encoded. It looks like they were replaced with null frames. The next keyframe was now at frame 147, so I moved my cut point up to frame 110. After saving with direct stream copy the new AVI should have had 380 frames. It had 369, so obviously VirtualDub simply moved the cut point up to the next available keyframe. The zero latency option seems to just disable B frames, so the bitrate increases quite a bit, but still didn't let me cut at frame 50. I'd be interested to learn the incantation you're using when encoding that permits cutting anywhere. I've nothing against the AVI container but I use MKV myself because I don't think a single hardware player in our house supports h264 in an AVI, but they're happy to play it in an MKV or MP4. That's reason enough for me even if AVI had magic properties that allowed cutting on non-keyframes without ill effects, but the keyframe cutting problem is mostly a minor inconvenience and easy enough to work around. Last edited by hello_hello; 27th May 2017 at 09:39. |
|
27th May 2017, 15:42 | #39 | Link | |
Retried Guesser
Join Date: Jun 2012
Posts: 1,373
|
Good testing there hello_hello. By the way, according to the developers, x264 optimized for zero latency reduces all the following sources of latency:
Quote:
|
|
28th May 2017, 11:30 | #40 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
raffriff42,
It seems to be the same zero latency, at least to a certain extent. I read the post you linked to and while I don't understand it all fully yet, some of the relevant x264 settings obviously changed when zero latency was enabled. B Frames disabled, Slices enabled, Threads reduced, Lookahead threads increased. Nothing that'd make it possible to cut on any frame. A small SD test encode using the default settings. x264 set High Profile, Level 3 each time. An old 4 core CPU with no hyper-threading used for encoding. Without the zero latency checked: cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 With the zero latency option checked: cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=4 / lookahead_threads=4 / sliced_threads=1 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=crf / mbtree=0 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 |
Thread Tools | Search this Thread |
Display Modes | |
|
|