|
|
| Sarreq Teryx |
| Posted: Mar 9 2003, 10:47 AM |
 |
|
VirtualdubMod Alpha tester
  
Group: Vdubmod Alpha Testing Team
Posts: 175
Member No.: 41
Joined: 16-July 02

|
very minor, but is it possible for virtualdub(mod) to make b-frames another color in the compression histogram? or is that a vfw issue that they're colored the same as p-frames?
-------------------- And as I walk through the Valley of the Shadow of Death, Lord, thy balls and shaft, they comfort me, you annoint my head with oil, some salt, a dash of pepper, a sprigg of parsley......Lord?............Lord??? What dost thou intend to do with that fork??? |
 |
| ChristianHJW |
| Posted: Mar 9 2003, 12:01 PM |
 |
|
Advanced Member
  
Group: Moderators
Posts: 1768
Member No.: 2
Joined: 7-July 02

|
AVI container, as well as OGM, dont have any flags marking B frames. Again, matroska in its 'native' MPEG4 mode ( and only then, not in VFW/AVI compatibility ) will allow this feature ....
-------------------- Visit the unofficial Virtualdub support forum on http://forums.virtualdub.org - help to reduce the big number of emails Avery Lee is getting every day !! Support matroska as container and Gstreamer as the only truely open, x-platform multimedia platform .... |
 |
| Sarreq Teryx |
| Posted: Mar 9 2003, 04:27 PM |
 |
|
VirtualdubMod Alpha tester
  
Group: Vdubmod Alpha Testing Team
Posts: 175
Member No.: 41
Joined: 16-July 02

|
but while encoding, should that matter. wouldn't it be able to tell the difference before stuffing it into the avi/ogm?
-------------------- And as I walk through the Valley of the Shadow of Death, Lord, thy balls and shaft, they comfort me, you annoint my head with oil, some salt, a dash of pepper, a sprigg of parsley......Lord?............Lord??? What dost thou intend to do with that fork??? |
 |
| muf |
| Posted: Mar 9 2003, 09:08 PM |
 |
|
MCF team member
  
Group: Moderators
Posts: 179
Member No.: 46
Joined: 21-July 02

|
| QUOTE (Sarreq Teryx @ Mar 9 2003, 10:27 AM) | | but while encoding, should that matter. wouldn't it be able to tell the difference before stuffing it into the avi/ogm? |
Maybe implement some debugview functions ? You might be able to get codec-specific data like quantizers even, for xvid & divx4/5.
--------------------
 |
 |
| phaeron |
| Posted: Mar 10 2003, 03:59 AM |
 |
|

Virtualdub Developer
  
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02

|
| QUOTE | but while encoding, should that matter. wouldn't it be able to tell the difference before stuffing it into the avi/ogm?
|
The Windows Video Compression Manager (VCM) interface doesn't have a notion of B-frames, and neither does AVI. For that matter, I don't think DirectShow does either (only sync marks). Client applications don't care as long as the matching decoder can tell from the compressed data what frame type is used. The client can also check the compressed data directly to discover this information, but this violates the "black box" codec paradigm and requires special case code per format supported.
As a side note, having such special case code makes "fast rekey" possible -- being able to rederive the keyframe flags without having to decompress any of the data. That would speed up rekey speed from one-half decode rate to the speed of the hard disk.
| QUOTE | Maybe implement some debugview functions ? You might be able to get codec-specific data like quantizers even, for xvid & divx4/5.
|
I hope you're not talking about Win32 debug output. There are known deadlock issues with OutputDebugString() and synchronization objects under Windows NT platforms that make it inadvisable for data exchange. Polluting the debug channel for this will also royally piss off anyone who is using a debugger. |
 |
| muf |
| Posted: Mar 10 2003, 11:37 AM |
 |
|
MCF team member
  
Group: Moderators
Posts: 179
Member No.: 46
Joined: 21-July 02

|
| QUOTE (phaeron @ Mar 9 2003, 09:59 PM) | | I hope you're not talking about Win32 debug output. There are known deadlock issues with OutputDebugString() and synchronization objects under Windows NT platforms that make it inadvisable for data exchange. Polluting the debug channel for this will also royally piss off anyone who is using a debugger. |
Don't know really, I've never worked with debugview. It seems to be able to get codec data while encoding, and is used to gather statistics after a pass.
--------------------
 |
 |
| Sarreq Teryx |
| Posted: Mar 10 2003, 08:51 PM |
 |
|
VirtualdubMod Alpha tester
  
Group: Vdubmod Alpha Testing Team
Posts: 175
Member No.: 41
Joined: 16-July 02

|
| QUOTE (phaeron @ Mar 9 2003, 10:59 PM) | | QUOTE | but while encoding, should that matter. wouldn't it be able to tell the difference before stuffing it into the avi/ogm?
|
The Windows Video Compression Manager (VCM) interface doesn't have a notion of B-frames, and neither does AVI. For that matter, I don't think DirectShow does either (only sync marks). Client applications don't care as long as the matching decoder can tell from the compressed data what frame type is used. The client can also check the compressed data directly to discover this information, but this violates the "black box" codec paradigm and requires special case code per format supported.
As a side note, having such special case code makes "fast rekey" possible -- being able to rederive the keyframe flags without having to decompress any of the data. That would speed up rekey speed from one-half decode rate to the speed of the hard disk. |
so, that's an "it could be done, but would require mad amounts of extra programming per codec supported"? or did I read that wrong?
what's the black box codec pardigm exactly?
-------------------- And as I walk through the Valley of the Shadow of Death, Lord, thy balls and shaft, they comfort me, you annoint my head with oil, some salt, a dash of pepper, a sprigg of parsley......Lord?............Lord??? What dost thou intend to do with that fork??? |
 |
| phaeron |
| Posted: Mar 11 2003, 03:22 AM |
 |
|

Virtualdub Developer
  
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02

|
| QUOTE | so, that's an "it could be done, but would require mad amounts of extra programming per codec supported"? or did I read that wrong?
|
Yup. Essentially, what's required is code to detect that DivX/XviD/whatever is in use, and then special code for that format to pick out the frame type.
| QUOTE | what's the black box codec pardigm exactly?
|
"Black box" means you have a box that does X, but you don't know or care how it does X. In this case, Win32 codecs are designed so that an application can compress or decompress video without any knowledge of the compressed format -- compressed video is passed verbatim in and out of the codec as an opaque, unknown format by the application. The idea is that as long as a codec can be written to conform to the Video for Windows API, any application that uses that API can use that codec and its accompanying format, regardless of what kind of compression algorithm is used. When applications have to check for specific formats and go spelunking into the compressed frames, you lose generality, as now every application has to be retrofitted to support each new format that requires such spelunking. |
 |