Export Snapshot (macOS) and XPDF External bugs?

Matthias Rebbe matthias_livecode_150811 at m-r-d.de
Fri Oct 28 01:23:41 EDT 2022


Hi Paul,

regarding your export problem.

How many snapshots per video are created?
I just did a 3 tests here with a 123 minutes video (7418646 intervals with a timescale of 1000, .mp4 format) in 9.6.9RC1 and 9.6.8. and used a repeat loop to set the currentTime to create a snapshot on hard disk every 5,  3 and 1 minutes.
In all cases it worked here. No snapshot was rotated.

My export command was 
export snapshot from Player "myPlayer" to file ("~/downloads/livecodeexport/" & tCurrentTime & ".png") as PNG

Is your snapshot command similar? Or are you using a mask or an other format? Are there more then 120 snapshots per video file?

I tested here with a mac Studio on macOS 13.0 running LC both in x86 and native ARM mode.

Regards,
Matthias


> Am 27.10.2022 um 21:40 schrieb Paul Dupuis via use-livecode <use-livecode at lists.runrev.com>:
> 
> Combining two unrelated topics in one message:
> 
> 1) I am seeing a bug under macOS in the export snapshot (of a player object) command. This is under LC 9.6.7 (and I think 9.6.8). We have a routine that takes a list of time codes in a movie, loads the movie into a player object, set the currentTime to each time code, uses export snapshot of the player to grab the displayed frame, and returns an array of the images.
> 
> The possible bug is that occasionally one of the images returned will be rotated 90 degrees. We have NO code that rotates the image and the movie, from start to finish, does not not change the camera orientation.
> 
> I have not had the time/bandwidth to develop a reproducible recipe or test stack (yet). My question is: Has anyone seen anything like this? Is it a known bug?
> 
> 2) Unrelated to the above, we also have a routine that takes a list of PDF image coordinates (5 number, the page number, and a rect on the page in PDF coordinates), loads the PDF using the XPDF EXTERNAL (XPDF-1.0.45, NOT the widget), goes to the page, and grabs the image, and returns an array of the images.
> 
> The confirmed bug, is that the first time the XPDF Viewer is opened (via XPDFViewer_Open and then XPDFViewer_Set tName,"FILENAME",tFile to load the PDF file), the XPDF calls to grab the image:
>             put empty into tImageData
>             XPDFViewer_SelectImage tName,(item 1 of tRef),(item 2 of tRef),(item 3 of tRef),(item 4 of tRef),(item 5 of tRef)
>             XPDFViewer_GetSelectionImage tName, "tImageData"
>             put the result into tSize
>             set the width     of img "imageConvert" of stack "libHrAPI" to abs(item 1 of tSize)
>             set the height    of img "imageConvert" of stack "libHrAPI" to abs(item 2 of tSize)
>             set the imageData of img "imageConvert" of stack "libHrAPI" to tImageData
>             set the topLeft   of img "imageConvert" of stack "libHrAPI" to (0,0)
> return garbage in tImageData. The tize (tSize) is correct, but the image is not.
> 
> This has a WORK-AROUND as this only occurs the first time the XPDF viewer is opened. So, if I am asking for images, I have a conditional that closes the XPDF External viewer (via XPDFViewer_Close tName) and then opens the PDF again behind the scenes. This causes all the returned PDF images to be correct for the same code.
> 
> Again, I have not had the time/bandwidth to develop a reproducible recipe or test stack (yet). My question is: Has anyone seen anything like this one? Is it also a known bug?
> 
> Thank you in advance for any info of whether you have seen these possible bugs or know if the are related to an existing issue
> 
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



More information about the use-livecode mailing list