Welcome Guest ( Log In | Register )


Important

The forums will be closing permanently the weekend of March 15th. Please see the notice in the announcements forum for details.

 
Mjpg Issue Running Vdub V1.9.4 And Later, mjpg input file renders green
« Next Oldest | Next Newest » Track this topic | Email this topic | Print this topic
Robastro
Posted: Feb 14 2010, 12:52 AM


Newbie


Group: Members
Posts: 1
Member No.: 27012
Joined: 13-February 10



Hi,
I'm trying to convert an AVI from a Microsoft LifeCam Cinema HD,
which is in 1280x720 MJPG format, to another compression codec.
This works great on the 32-bit 1.8.8 release of vdub running under
XP Pro (32 bit), but when I try the same AVI on vdub 1.9.4 and higher
(including 1.9.8), the input file is rendered in green.
I'm trying to move everything over to a Windows 7x64 box, but the
1.8.8 x64 version wont decode mjpg input files (reports needing a VFW
codec.)

I can run vdub 1.8.8 (32-bit version) on the Win7x64 box, so have a
workaround, but thought I'd report this green rendering issue as I'd
prefer to run a 64 bit version of vdub if possible.
I can upload a test AVI if it would help.

Cheers and thanks for a superb program which I've been using for many
years in amateur astronomy - I would be "lost in space" without it! smile.gif
--
Rob


 
     Top
Placio74
Posted: Feb 14 2010, 04:24 PM


VideoAudio


Group: Members
Posts: 1216
Member No.: 21485
Joined: 24-May 07



What codec is used to decode?
Look at File information.

What about internal decoding (DV & MJPEG)?
Options > Preferences... > AVI > Prefer internal video decoders over installed third-party codecs (MJPEG and DV)

--------------------
VideoAudio.pl - Serwis o technologii wideo & audio
 
     Top
phaeron
Posted: Feb 14 2010, 09:16 PM


Virtualdub Developer


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



Are you running 1.9.4+ 32-bit or 64-bit? If you're running 64-bit, it may be having to use the internal codec when the 32-bit version doesn't, causing a difference. I received a bug report on the green decoding (perhaps from you) and need to look into it. Ordinarily I'd suspect a non-compliant MJPEG stream, but this one's a bit unusual as all of the general shapes appear to decode correctly.

Updated:
Found and fixed one possible cause. Please try this version:

http://www.virtualdub.org/beta/VirtualDub-....9.9-test10.zip
http://www.virtualdub.org/beta/VirtualDub-...est10-AMD64.zip
http://www.virtualdub.org/beta/VirtualDub-...9-test10-src.7z


This post has been edited by phaeron on Feb 21 2010, 06:24 AM
 
    Top
jbellies
Posted: Aug 17 2010, 06:39 PM


Newbie


Group: Members
Posts: 8
Member No.: 20328
Joined: 29-November 06



I'd like to confirm that I had the same green display (and render) problem with MJPG video from a Pentax K-x camera using 1.9.8 stable, under XP SP3. There was a tiny corner of full colour in the upper left hand corner. Upgrading to 1.9.9 stable solved the problem. Thank you for Virtual Dub and for this forum.
 
     Top
oreillymj
Posted: Dec 21 2011, 01:04 PM


Newbie


Group: Members
Posts: 5
Member No.: 33862
Joined: 21-December 11



Phaeron,

I e-mailed you about the problem with the green MJPEG video from Pentax cameras. That is now fixed, but I have another problem which I think I mailed you about also.
1080p MJPEG video cannot be opened in Virtualdub because it gives the following error.

Virtualdub cannot decode 4:2:2 Motion JPEG frames with image widths or heights that are not multiples of 16.

Both 1920 and 1080 are divisible by 16.


 
     Top
fccHandler
Posted: Dec 21 2011, 06:49 PM


Administrator n00b


Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02



1080 is not a multiple of 16. I know at least with MPEG-2, hi-def videos are encoded at 1920 x 1088 but the bottom 8 lines are not displayed. If I remember correctly though, JPEG macroblocks are 8 x 8 so I'm not sure why VirtualDub would require height and width to be multiples of 16...

--------------------
May the FOURCC be with you...
 
     Top
phaeron
Posted: Dec 22 2011, 12:03 AM


Virtualdub Developer


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



This is a hold-over from an older version of the internal MJPEG codec. It used to do color conversion per macroblock, which prevented it from reasonably handling odd-size blocks. The current implementation uses the blitter library and so doesn't have this problem, but the size check is still there and is probably unnecessary. If you can post a short sample clip, I should be able to fix this problem.
 
    Top
ale5000
Posted: Dec 22 2011, 11:19 PM


Advanced Member


Group: Members
Posts: 1114
Member No.: 22180
Joined: 30-September 07



Sample file (MJPEG.avi - 1.23 MB): http://www.multiupload.com/NC0V9PEHV5

Another thing, it say "VirtualDub cannot decode 4:2:2 Motion JPEG frames with image widths or heights that are not multiples of 16"
but according to MediaInfo it should be "4:4:4".

--------------------
New VirtualDub forum
VirtualDub AIO (All-in-One installer for VirtualDub and plugins)
Codec Toolbox RS (A tool to read/change merit of codecs and many other things)
Input plugins for VirtualDub / ACM codecs / VFW codecs
 
     Top
fccHandler
Posted: Dec 23 2011, 04:58 AM


Administrator n00b


Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02



I've been studying the .avi posted by ale5000, and as far as I can tell it is neither 4:4:4 nor 4:2:2. I say it is 4:2:0. It has Horizontal and Vertical sampling factors of 2 for the Y component, and Horizontal and Vertical sampling factors of 1 for the Cb and Cr components. As I understand JPEG, this means that the Y is sampled twice (in both directions) for each Cb/Cr sample.

Just for fun, I used VirtualDub's hex editor to extract a single frame starting from offset 0x9136A with a length of 0x568F bytes, and uploaded it here:
http://fcchandler.home.comcast.net/boxxy.jpg


--------------------
May the FOURCC be with you...
 
     Top
phaeron
Posted: Dec 23 2011, 07:42 AM


Virtualdub Developer


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



Typo in error message, will fix.
 
    Top
oreillymj
Posted: Dec 25 2011, 11:48 PM


Newbie


Group: Members
Posts: 5
Member No.: 33862
Joined: 21-December 11



Yes, I had divided 1080 by 16 before and got 67.5.
For some reason Calc.exe decided round the result.

I've uploaded a 1080p clip from a Pentax K5

http://www.multiupload.com/MCH2GWZT3H
 
     Top
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:
10 replies since Feb 14 2010, 12:52 AM Track this topic | Email this topic | Print this topic

<< Back to Testing / Bug Reports