|
|
| phaeron |
| Posted: Nov 30 2004, 06:06 AM |
 |
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
I never claimed that the earlier versions of VirtualDub were consistent in this regard; I only claim that it makes more sense now. Another reason for the blank frame at the end is that the old Microsoft VidEdit program did it, for similar reasons to why VirtualDub does it now. (VidEdit would still be very useful, if it weren't a 16-bit program.)
|
|
| Cyberman |
| Posted: Nov 30 2004, 08:11 AM |
|
|
Advanced Member
Group: Members
Posts: 2035
Member No.: 3477
Joined: 3-April 03
|
| QUOTE (i4004 @ Nov 30 2004, 12:39 AM) | | QUOTE (Cyberman @ Nov 29 2004, 11:39 AM) | I see. So the last frame is a dud? Would it be possible to mark it as such?
Perhaps removing the number from it, or displaying a "X" or something |
let's see if you can come up with a good enough reason to do that.
 |
Well, it may not be a matter of high importance(though it DID fool me), but it sure isn´t a matter of high cost, is it?
The empty frame could fool people into believing that there is another frame, but it´s not displayed - or that it couldn´t be retrieved, because it´s a B-Frame, or something else.
How much work could it be to set a big red X into that frame?
IMO, the cost justify the result.
--------------------
Matroska/MKV ? |
|
| bond |
| Posted: Jan 3 2005, 11:50 PM |
|
|
Unregistered
|
sorry for the late reply but for me the problem is still not solved in 1.6.2 
for example when i encode with b-frames in the vfw x264 h.264 encoder i get
- for 2 b-frames in a row -> two zero length frames in the output stream
- for 1 b-frame -> 1 zero length frame
- for 0 b-frames -> 0 zero length frames |
|
| phaeron |
| Posted: Jan 4 2005, 04:34 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Unofficial VirtualDub Support Forums»VirtualDub»Testing / Bug Reports»Problems At The Ends Of Mpeg-4 Encodes
| QUOTE |
for example when i encode with b-frames in the vfw x264 h.264 encoder i get
|
H.264 is not MPEG-4.
VirtualDub supports B-frames in only a couple select codecs for which it has special code -- specifically, DivX and XviD. In order for it to support others it needs to be able to detect when the codec has an output lag and produces frames at the start that should be deleted. Furthermore, for B-frames to work fully correctly, you can't have a B-frame backwards predicted from an I-frame (which I believe XviD violates).
|
|
| i4004 |
| Posted: Jan 4 2005, 11:20 AM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
| QUOTE | | H.264 is not MPEG-4. |
well, it is also called "mpeg4 part 10"
http://www.google.com/search?num=100&hl=en...part+10&spell=1
so it is a version of mpeg4, but not compatible with mpeg4 part 2.
regarding this issue, i still fail to understand why is this important?
reencoding mpeg4 and few frames missing?
muxing,editing?
why do that on a finished, encoded mpeg4 file (unless one has some crappy p2p files...  ).
also, x264 is still rather underdeveloped compared to atame's codec: if codec is still developing, what's the purpose of making a special code for it, if it can change any day?
--------------------
my signature:
 |
|
| bond |
| Posted: Jan 5 2005, 02:20 AM |
|
|
Unregistered
|
| QUOTE |
VirtualDub supports B-frames in only a couple select codecs for which it has special code -- specifically, DivX and XviD. In order for it to support others it needs to be able to detect when the codec has an output lag and produces frames at the start that should be deleted. |
the x264 vfw wrapper was written by syskin (main xvid dev) also by using code of the xvid vfw wrapper
but as you said he didnt do anything special about the b-frame issue (so i assume thats the cause), sorry for posting before talking to syskin
| QUOTE | | H.264 is not MPEG-4. |
actually h.264 is indeed part of mpeg-4 (mpeg-4 avc / iso 14496-10) as i4004 wrote, but of course i understand what you meant |
|
| phaeron |
| Posted: Jan 6 2005, 12:14 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
#$&(*#$... are they just throwing everything into MPEG-4?
B-frame support actually is important, not because of the dropped frames, but because of encoding lag. If the client application doesn't know that B-frame encoding is occurring, it will interleave and output a video stream that is lagged behind the audio stream. Some decoders work around this by implementing a delay queue in the decoder, but this is a poor solution because it confuses any application that attempts random access -- particularly since it means that from the client's perspective, decoding frame N can result in different results!
|
|
| i4004 |
| Posted: Feb 13 2005, 09:37 PM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
| QUOTE | | it will interleave and output a video stream that is lagged behind the audio stream. |
yeap. i just did it.
x264+1b-frame=40ms offset.
--------------------
my signature:
|
|
| stephanV |
| Posted: Feb 13 2005, 10:00 PM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
notice that at the beginning of a x264 stream there are N dropped frames (indicated with a [D] in VirtualDub) where N is the value of the number of b-frames used. You can safely remove these "D-frames" and your audio should be in synch again.
Interestlingly enough, AviSynth b0rks on these empty chunks... (thats what they are if im right)
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| phaeron |
| Posted: Feb 13 2005, 11:40 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Hmmm.... zero-byte chunks are both a really good and a really bad choice for this mechanism. They're really bad from the standpoint that they make no sense to a player; they're really good from the standpoint that they never make any sense at the start of a compressed stream and thus can safely be dropped.
What's the link to the latest x264 VFW? I want to try implementing B-frame support for this codec as well but the one doesn't insert drops at the start and can't read its own output....
|
|
| i4004 |
| Posted: Feb 14 2005, 12:20 AM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
doom9 forum thread with links to x264 builds
'akupenguin' is on this forum too, so you can contact him if you have some doubts about anything related to x264.
i'm now encoding some toon. i mean, not much action or motion in the toon, but avg. bitrate vdub shows is 17kB/s.
good lord! that's less than 160kbit/s!
edit/ link changed to doom9 forum thread providing x264 builds
--------------------
my signature:
|
|
| phaeron |
| Posted: Feb 14 2005, 04:16 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Okay, I just stepped through the disassembly for x264vfw!DriverProc and it seems that this driver fails all decompression functions. What are you guys actually using to play the output?
|
|
| i4004 |
| Posted: Feb 14 2005, 09:04 AM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
recent versions of ffdshow (since 05-01-2005 i think) needed for b-frame decoding.
http://s92912755.onlinehome.us/ffdshow%20mjpeg/1.png
(note the 'decoder' tab on vfw front-end dialog)
perhaps one more thing worth saying; first time you play x264 with b-frames(via ffdshow), it jerks on the beginning; if you hit stop, and try again , it doesn't (something with caching of decoder?)
--------------------
my signature:
|
|
| akupenguin |
| Posted: Feb 14 2005, 10:44 AM |
|
|
Unregistered
|
x264 doesn't support decoding at all. (That's not specific to the vfw frontend.)
ffdshow implements a delay in the decoder to accomodate B-frame reordering -- but only activates it when it gets to the first B-frame. That's the jerk you're seeing. When you stop and play again, it doesn't forget that the stream contains B-frames, so the next time it's smooth. |
|
| i4004 |
| Posted: Feb 15 2005, 02:10 PM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
just tried more recent version of ffdshow
http://www.free-codecs.com/download/FFDShow.htm
(2005-02-12) and it seems the jerk on the beginning is no more.
--------------------
my signature:
|
|
