single frame preview not working (vobblanker & pgcedit)

[lark]

i authored a dvd that has 1 single frame (created from a bmp) with a long audio (1h20min or so) with muxman.

when i tried to preview the pgc in pgcedit, nothing happens (no preview window shows up). looking at the task manager the preview application is running, but the window is not shown.

i tried to view the title with vobblanker as well, but it just hangs (doesn't even redraw the main window) and has to be killed from the task manager :-(

i tried both with wav and ac3 audio, but both have the same result.

obviously such a dvd is not very realistic, but just makes me wonder, why preview doesn't work. perhaps worth mentioning, the dvd plays fine with sw player.

regards
t :)

[r0lZ]

Strange. I tried to author a BMP and AC3 audio with muxman, and the preview works fine.
Could you try to author a test DVD with the same BMP, and a short sound. If it still doesn't work, send it to pgcedit <at> tiscali <dot> be. Mpucoder may be interested, too.
Thanks.

BTW, mpucoder, it should be possible to set the 16:9 option when authoring a BMP, no?

[jeanl]

Send the vob file to me too! jeanldvd(at)free(dot)fr... I don't need the whole DVD, just the vob file. Did you try to launch PgcEditPreview by itself (double-clicking in the bin directory), and drag/dropping the VOB into it? I suspect it will hang too. If it does, send me the vob, I'll look into it...
jeanl

[sweetness]

Originally posted by r0lZ
it should be possible to set the 16:9 option when authoring a BMP, no?
yes it is. read here (http://forum.doom9.org/showthread.php?postid=619923#post619942).
but mpucoder changed some of the names see here (http://www.mpucoder.com/Muxman/mxp/segment.html), it's Only Panscan not Only Pan Scan

edit: you don't need the video file anymore read three post down. just change the Display Mode.

[lark]

sorry guys, looks like it's working. it's just very very VERY slow, when the audio is long. perhaps it seeks till the end of the VOB or something like that.

i tried 1st with 53s audio and that was quite fast.
next i tried with 1min48s audio and didn't notice any difference.
with 7min39s audio it takes a while.
with 1h50min34s audio, it took something like 35 min.

those were with pgcedit. i tried the small ones with vobblanker and they worked fine. when the audio was 36min10s, it took couple of minutes to open the preview (in vobblanker).

so perhaps instead of fixing a bug, small optimization would be needed...

regards
t :)

[jeanl]

mmm I think I know what that is... I think it's related to the fact that PgcEdit preview attempts to determine exactly where the end of each cell is in the vob. That's normally very fast, but in the case of a single image with lots of audio, it can take a very long time.
r0lZ, I can't think of an easy way around it. Can you? Maybe simply give up after a few seconds?
jeanl

[r0lZ]

with 1h50min34s audio, it took something like 35 min.Jeanl, even in it searches the end of the cell, it should not take 35 mins, to seek to the end of a 2 hours cell. Maybe there's something more...

[jeanl]

Originally posted by r0lZ
Jeanl, even in it searches the end of the cell, it should not take 35 mins, to seek to the end of a 2 hours cell. Maybe there's something more...
Well, preview tries to locate the end of the cell starting from the end, going backwards some, then moving forward. If that does not work it tries to go backwards a bit further. If that does not work it starts at the beginning of the cell, going forward, but even that isn't fast at all. You have to remember that it uses the DVD2AVI code which wasn't meant to be used that way. If I had to write it today, I could certainly do it in less than 35 mins, but we had to work with what we had... So I don't really think there's a bug/problem other than "bad design". But I'm willing to make a few experiments myself.
jeanl
EDIT: Come to think of it, the fastest way to locate the last video frames would probably implement a fake 32x playback, using the VOBU_SRI information in the navpacks to locate video x seconds later... Of course this would fail if the VOBU_SRI info wasn't accurate!

[lark]

what do we need the end of the cell for?
is it for the slider?
would it make sense to show the window with the 1st frame (or whatever was requested) asap
and then search for the end in the background?

please note that this was some extreme case that i found out.
for me fixing this is definitely NOT HIGH priority.

regards
t :)

[jeanl]

Originally posted by lark
what do we need the end of the cell for?
is it for the slider?
would it make sense to show the window with the 1st frame (or whatever was requested) asap
and then search for the end in the background?

Well, it was so DVD2AVI would not show you a video frame from the next cell, which is important, for example for menus. The way DVD2AVI works, if you tell it to go to a LBA that's still within the cell, but past the last I-frame (for example, in the middle of your audio), it will go to the next I-frame which will be in the next cell. r0lZ wanted to avoid that, and that meant locating exactly where the last I-frame was in the cell.

please note that this was some extreme case that i found out.
for me fixing this is definitely NOT HIGH priority.
regards
t :)
Yes, I understand. r0lZ and I never really liked the solution we have to do that. But it's better than nothing. I think a quick fix would be to detect that the cell is HUGE, and in such cases give up trying to locate the last I-frame and let the user know that the preview might show a frame that belongs to the next cell. Again, if we were writing this from scratch, we could do it easily, simply using the VOBU_SRI info, but modifying the DVD2AVI code to do that would be pure hell!

jeanl
EDIT: About searching in the background, we couldn't do that with DVD2AVI either...

[mpucoder]

I'm guessing you do not trust or use the ifo to find the cell end? There are some very good hints in the NAV pack as to length, and some good ways to optimize the search for the end. Use the SRI_FWD values. Search from sri_fwda240 (offset 0x4f5) down to sri_fwda1 for a value other than 0x3fffffff. Mask off (clear) the upper 2 bits (they are flags) and add that value to the current LBA and read that sector in. Repeat until there are no valid pointers and you're at the end of the cell.

[jeanl]

Originally posted by mpucoder
I'm guessing you do not trust or use the ifo to find the cell end? There are some very good hints in the NAV pack as to length, and some good ways to optimize the search for the end. Use the SRI_FWD values. Search from sri_fwda120 (offset 0x4f5) down to sri_fwda1 for a value other than 0x3fffffff. Mask off the upper 2 bits (they are flags) and add that value to the current LBA and read that sector in. Repeat until there are no valid pointers and you're at the end of the cell.
Oh I absolutely agree with you on that one! The SRI pointers are the way to go. But this would have required an extensive re-write of the DVD2AVI code which I was not up for! Like I said, if we had to do it today, we would do it very differently!
jeanl