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
> :
>
> 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 heightof 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@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
