Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RGB DPX 16-bit sequences (4950x3764, 900+GB) not initiating FFmpeg transcode #396

Open
digitensions opened this issue Feb 14, 2023 · 10 comments
Open

RGB DPX 16-bit sequences (4950x3764, 900+GB) not initiating FFmpeg transcode #396

digitensions opened this issue Feb 14, 2023 · 10 comments

Comments

@digitensions
Copy link
Contributor

Hi Jérôme and all,

I'm running some parallel transcoding tests at the moment across several storage devices. I'm having repeated issues with very large files reaching the end of the first RAWcooked analysis, and then stalling. This is mainly being noticed against the slower storage devices. The outputs reach over 100% with the last amount finding multiple files:
Analyzing files (100.32%), 5 file/s
Analyzing files (100.33%), 16 file/s
The files I assume are probably my required attachments. But at this point the FFmpeg command does not launch, and no further warnings/errors are output to the log. The RAWcooked launch scripts remain open though, blocking any further process from launching in GNU parallel.

The files are RGB 16-bit, 4950x3764 and generally between 800-950GB. We're running on our usual Linux server from Ubuntu 20.04 LTS, using FFmpeg version 4.2.7-0ubuntu0.1, and using RAWcooked snapshot 21.09.20221208. MediaInfoLib is 22.06.

Please let me know if you'd like samples of the files or reversibility data, etc.
Thanks so much!
@digitensions
Copy link
Contributor Author

I should add these pauses date back to 10th February and I don't think our IO would be the cause, but I'll check with iftop tomorrow.

Apart from this, some excellent MKV transcodes are cooking here! Thanks so much.

@JeromeMartinez
Copy link
Member

I'm having repeated issues with very large files reaching the end of the first RAWcooked analysis, and then stalling.

You mean that this is not always the case i.e. for a same dir sometimes it works, sometimes not?

Analyzing files (100.32%), 5 file/s

More than 100%!!! and slow...

Could you provide the output of ls -lR on the dir?
So I could try to reproduce the same kind of attachments / content without the files.

It will be long to debug :(.
But also I plan to rework this part (multithreading for not depending on I/O latency), with some luck it would remove this issue, but no ETA :(.

@digitensions
Copy link
Contributor Author

digitensions commented Feb 15, 2023 •
edited
Loading

Hi Jérôme, thanks for quick response.

I've been investigating the sibling folders as they're split from the same original sequence. There are error messages featuring in the logs for the RAWcooked, but MKV files are building:
[ffv1 @ 0x55a89be576c0] Cannot allocate worst case packet size, the encoding could fail speed = 0.00141x

I attach the ls output for a folder which has frozen.
Happy to send any sample DPX you may need.
Thanks,
Joanna

ls_lr_N_464631_06of12.txt

@JeromeMartinez
Copy link
Member

There are error messages featuring in the logs for the RAWcooked, but MKV files are building:
[ffv1 @ 0x55a89be576c0] Cannot allocate worst case packet size, the encoding could fail speed = 0.00141x

Not error message, only warning, due to size of image, "worst case" do not happen in practice (and if so, the encoding would fail so visible).

I attach the ls output for a folder which has frozen.

Very few and small attachments, classic layout, very weird.

I've been investigating the sibling folders as they're split from the same original sequence.

So same kind, but different content "only", weird!
I am afraid that I need the full content for reproducing, and/or I need to have more log. I bet I could not reproduce so maybe the way to go is to have more logging, I'll implement more logging so you can see when it is frozen where it is frozen.

BTW, if you try again with the same folder, is it fine, i.e. is this freeze easily reproducible? If so, even without using GNU Parallel?

@digitensions
Copy link
Contributor Author

Thanks Jérôme, good to know that the warning isn't critical.
More logging sounds good, I'll await a new snapshot.

I'll will try cooking this problem item directly now without Parallel and let you know how it goes.

Many thanks,
Joanna

@digitensions
Copy link
Contributor Author

digitensions commented Feb 15, 2023 •
edited
Loading

The folder is RAWcooked encoding using a direct command Jérôme, I'll monitor my IO for a while today also and see if we have issues there. Not sure if it's relevant but the ffmpeg command being used has a framerate of 24.000002, when all rest are straight 24.000000.

@digitensions
Copy link
Contributor Author

Morning, I can confirm that transcode completed manually over the weekend okay Jérôme. Any more I encounter with this issue I'll cook manually, it could be a conflict with GNU parallel. Many thanks!

@JeromeMartinez
Copy link
Member

I plan to refactor the analysis part, as it is not blocking your work it seems less urgent, I think I'll wait for this work before adding more logs and so on.
Let me know if it is too much often.

@stephenmcconnachie
Copy link
Contributor

stephenmcconnachie commented Feb 21, 2023 via email

@JeromeMartinez
Copy link
Member

as these workflows are now so critical

☺️

Please consider if that would help, and let me know?

For the moment I am blocked by MediaInfo related projects during the next months, but with no other big projects in the pipe (except... FFV1 fast encoder/decoder! But also related to RAWcooked).
I drop an email with more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@JeromeMartinez @stephenmcconnachie @digitensions