totally gray, instead of movie image(s)

[rfg]

I have some .VOB files that I took from a rip of a DVD.  These seem to play quite OK, and normally, when I use either VLC or smplayer (this is on Windows 7, by the way).  However when I load either one or all of these .VOB files into avidemux, instead of displaying images from the video(s) I get a medium gray rectangle where the images should be... at least until I click on the PLAY button, after which the movie will start playing normally (from the current position on the time line) for a second or two, but then avidemux just freezes up.  (Strangely, and perhaps not coincidently, Kodi doesn't like to play these videos either.  It acts in all respects as if it were playing the files, but the display is all black.)

I do believe that the .VOB files in question were more probably badly mastered/authored.  (Running them through ffmpeg produces an error message in red saying something about Invalid frame dimensions.)  Still, as I have said, both VLC and smplayer can somehow cope with whatever the problem(s) is/are and play these files anyway.  So why can't avidemux?

I'll make a sample segment of one of these .VOB files available upon request via my FTP server, i.e. if anyone is motivated to actually look into this bug.  Just ask.

[Jan Gruuthuse]

1st of all vob is from the dvd era. The specification defines very clearly resolutions in this format.

The following formats are allowed for H.262/MPEG-2 Part 2 video[9][better source needed]:
At a display rate of 25 frames per second, interlaced (commonly used in regions with 50 Hz image scanning frequency):
    720x576 pixels (same resolution as D-1)
    704x576 pixels
    352x576 pixels (same as the China Video Disc standard)
    352x288 pixels
At a display rate of 29.97 frames per second, interlaced (commonly used in regions with 60 Hz image scanning frequency):
    720x480 pixels (same resolution as D-1)
    704x480 pixels
    352x480 pixels (same as the China Video Disc standard)
    352x240 pixels
The following formats are allowed for MPEG-1 video:
    352x288 pixels at 25 frame/s, progressive (Same as the VCD Standard)
    352x240 pixels at 29.97 frame/s, progressive (Same as the VCD Standard)

source: DVD-Video

If someone has taken liberties with this format, these are the culprits.
You could try to put these vob's through mkvtoolnix -- Matroska tools for Linux/Unix and Windows and repackage these video into mkv's (re-mux). Perhaps you're able to process these then correctly?
If mkv proposal would fail and if you still have access to these original dvd's: Try reprocessing these dvd's with program that uses the format correctly.
I can't speak for the developer. But my idea is that for the moment there is not enough time to explore this particular issue and look for a possible solution.

[AQUAR]

Interestingly, I was trying to recode some old Dutch DVD's into xvid.
I remuxed the sequential vobs with MKV-toolnix so avidemux can get along with them.
When I seek to an I frame - avidemux just shows a grey frame.
From the gray frame I can bidirectionally move one frame at a time and these frame will be rendered (I's P's and B's).

It's a PAL 25 frame / sec interlaced  4:3 video .
When deinterlacing with avidemux (Yadif mode=0, order=1 or dgbob mode=0, order=1) it also still results in an xvid/avi flagged as having a frame rate of 50 (or 100 if bobbing!).
The actual number of frames in the xvid shows it must be a 25 fps.
When looking at metadata using Avirate it informs double the number of frames @ twice the frame rate and of course the correct overall duration.
Maybe some issue in interpreting a field = a frame!
Also if you recode into mkv then avidemux will save it but with a message that the video is too short, presumably expecting to see those non-existent frames, still plays fine of course.

Simple work around is to add the "change FPS" filter at the end of the filter chain and set it so that input fps = output fps for the video in question (ie for the xvid above 25 fps > 25 fps).

Not sure if Mean ever looked into this?
     

[mean]

sample needed

[AQUAR]

Thanks Mean, I will provide a sample of the vob in mkv (using MKV toolnix to re package the streams and ADM 2.6 to cut/copy into mkv).
http://www.datafilehost.com/d/9d03169c

The grey frame seems to be due to frame referencing issues within the vob structure.
ADM 2.5 plays the frames out of order but ADM 2.6 deals with that fine.
On ADM 2.6, when seeking to an I frame it instead lands on a P frame, hence the gray frame.

FWIW - if I use tsmuxer on the vob then ADM 2.5 works fine but ADM 2.6 crashes on seek (time stamp issues?)!
In this case ADM 2.5 can be setup simply with the yadif deinterlacer (mode=0) to produce a "25 fps" xvid in avi (as I think it should be!).


Open to members suggestions how to extract these vob 's in a more compliant way (I'll try Mplayer as mentioned in the wiki!).

The meta data set's used to info the frame rate seems to give inconsistent values (beyond me!).

[mean]

If it is interlaced, what can happen is that the 1st field is I and the 2nd is P

[AQUAR]

That's an interesting field combination for making a frame.
Curious if the next frame at the start of the gop would comprises an I and a P field as well "in reverse".

Using the tsmuxer/ADM 2.5.6 plus filters Yadif-mode1 and swresize (for DAR!) has worked great for extracting and xvid recoding each episodes on the DVD.
Mediainfo shows all info is as expected for the recode.
Case anyone wonders about Yadif mode 1, its deinterlacing with bobbing so the xvid will be 50 fps (smoother movement!).

I will try a sample recode with adm2.6, using another compressor, to see if the frame rate thing is isolated to xvid (again just curious!).
The frame issue is seen on the windows ADM - maybe others can check the sample to see if its repeatable (Linux?).

[AQUAR]

On ADM 2.6, the frame rate issue with de-interlacing is consistent across compressors and containers used.
I guess it must be due to what ADM includes in the stream for these de-interlaced/recoded video's.

If you recode without de-interlacing, media info reports the frame rate as 25 fps but also "mistakenly" informs the original frame rate as 50 fps.
(appears that ADM just weaves the 2 field together when doing this unless you recode as interlaced/MBAFF!).
From an end user perspective it seems that ADM is interpreting fields as frames .

[mean]

It does

[AQUAR]

Thanks,

Something to note for people that recode DVB material using ADM 2.6.

[AQUAR]

Just curious!
I just deinterlaced with yadif using a more recent nightly and mediainfo now reports the correct frame rate on the recodes.
Maybe this issue has therefore been addressed?

I do note that this was on a 3:2 Telecined NTSC movie that can be nicely IVTC with the decomb filters (as long as you decimate with discard closer!).