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.

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

[WIP] [FIX] #1499 Persistent Dtvcc struct for CEA-708 decoding in Rust #1501

Draft
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

ArchitBhonsle
Copy link
Contributor

@ArchitBhonsle ArchitBhonsle commented Mar 16, 2023

In raising this pull request, I confirm the following (please check boxes):

  • I have read and understood the contributors guide.
  • I have checked that another pull request for this purpose does not exist.
  • I have considered, and confirmed that this submission will be valuable to others.
  • I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
  • I give this submission freely, and claim no ownership to its content.
  • I have mentioned this change in the changelog.

My familiarity with the project is as follows (check one):

  • I have never used CCExtractor.
  • I have used CCExtractor just a couple of times.
  • I absolutely love CCExtractor, but have not contributed previously.
  • I am an active contributor to CCExtractor.

{pull request content here}

@ArchitBhonsle
Copy link
Contributor Author

@PunitLodha This builds but segfaults when ran on this sample. I'll try to diagnose this but could you go over the changes when you get the time?

@ArchitBhonsle
Copy link
Contributor Author

Using ugly debug statements I have pinned down the segfault to here. It's exactly where the rust function is called. Not inside it as I put a debug statement on the Rust side but that did not get triggered. Any ideas why?

@cfsmp3
Copy link
Contributor

cfsmp3 commented Mar 18, 2023

Using ugly debug statements I have pinned down the segfault to here. It's exactly where the rust function is called. Not inside it as I put a debug statement on the Rust side but that did not get triggered. Any ideas why?

I'd run it with valgrind, it will give you a good idea.

@ccextractor-bot

This comment was marked as off-topic.

@ArchitBhonsle
Copy link
Contributor Author

Is there a way to disable this longer check for a draft PR XD

@canihavesomecoffee
Copy link
Member

Is there a way to disable this longer check for a draft PR XD

No, but that'd be a good addition for the SP so that Drafts aren't tested anymore (unless @cfsmp3 sees value in testing draft PR's?)

@cfsmp3
Copy link
Contributor

cfsmp3 commented Mar 20, 2023

Is there a way to disable this longer check for a draft PR XD

No, but that'd be a good addition for the SP so that Drafts aren't tested anymore (unless @cfsmp3 sees value in testing draft PR's?)

Not much :-)

@ArchitBhonsle
Copy link
Contributor Author

It works?! It does not seem perfect (lacks the "footer" for one) but it does produce a file!
video.p1.svc01.smi.txt

@ArchitBhonsle
Copy link
Contributor Author

I had a nasty bug where the program just crashed when I added a single line Dtvcc::new. Kept thinking it was some sort of undefined behavior because of all the pointer magic but it was just because I allocated too much on the stack in my quest to "optimize".

@ccextractor-bot

This comment was marked as outdated.

Copy link
Member

@PunitLodha PunitLodha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll need to define all the 708 structs/enums in rust itself as the next step, before moving forward with any other changes.

src/lib_ccx/ccx_decoders_structs.h Outdated Show resolved Hide resolved
src/lib_ccx/general_loop.c Outdated Show resolved Hide resolved
src/lib_ccx/general_loop.c Outdated Show resolved Hide resolved
src/lib_ccx/general_loop.c Outdated Show resolved Hide resolved
pub decoders: Vec<&'a mut dtvcc_service_decoder>,
pub packet: Vec<u8>,
pub report: *mut ccx_decoder_dtvcc_report,
pub decoders: [Option<Box<dtvcc_service_decoder>>; CCX_DTVCC_MAX_SERVICES],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no longer a need to use bindings for any 708 related structs/enums, we can define them now in rust itself. We still need to use bindings for encoder, timing and report. But all others should be defined in rust.
This is going to be somewhat bigger and comprehensive change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should that be a separate PR since it seems to be independent of this one?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be in this PR as I think it will allow you to remove the additional Boxing required here, and also will make the code more idiomatic rust as we can stop relying on the C bindings

@ArchitBhonsle
Copy link
Contributor Author

ArchitBhonsle commented Mar 20, 2023

This commit conditionally switches between the two. Oh yes, I have not fixed the encoder assignment for mp4. Should I do that too?

@ccextractor-bot

This comment was marked as outdated.

@ArchitBhonsle
Copy link
Contributor Author

Wait a minute... does this fix #1500 ? I ran this on the link mentioned on the video mentioned here and it works. Here's the SMI output: video.p0.svc01.smi.txt (It's in lowercase!)

@PunitLodha
Copy link
Member

This commit conditionally switches between the two. Oh yes, I have not fixed the encoder assignment for mp4. Should I do that too?

Yes

@PunitLodha
Copy link
Member

Wait a minute... does this fix #1500 ? I ran this on the link mentioned on the video mentioned here and it works. Here's the SMI output: video.p0.svc01.smi.txt (It's in lowercase!)

That sounds great. Ig all 708 problems stem from the same issue

@ccextractor-bot

This comment was marked as outdated.

@ArchitBhonsle
Copy link
Contributor Author

ArchitBhonsle commented Apr 11, 2023

I just noticed that there is a difference between the 608 and 708 output, is this expected?

8e8229b88bc6b3cecabe6d90e6243922fc8a0e947062a7abedec54055e21c2bf.p1.svc01.smi.txt

8e8229b88bc6b3cecabe6d90e6243922fc8a0e947062a7abedec54055e21c2bf.smi.txt

Footer: When I made this comment I was specifically referring to the difference in timings but there's a slight difference in timings too. And 708 doesn't have a footer.

@ArchitBhonsle
Copy link
Contributor Author

Oh and I forgot to inform you. @PunitLodha I've removed the formatting changes from src/lib_ccx/ccx_decoders_structs.h now. So should be easier to go through.

@ArchitBhonsle
Copy link
Contributor Author

There is no longer a need to use bindings for any 708 related structs/enums, we can define them now in rust itself. We still need to use bindings for encoder, timing and report. But all others should be defined in rust.
This is going to be somewhat bigger and comprehensive change

@PunitLodha I mean the only other on dtvcc_service_decoder right? Which in turn contains dtvcc_window and dtvcc_tv_screen. All of them have a significant number of functions associated with them.

I'm sure porting them over to Rust would be better than calling them over FFI. I still think a PR started to specifically fix the persistence of the Dtvcc struct is the wrong place to do it as it blocks merging the PR which does seem to fix quite a bugs.

@ArchitBhonsle
Copy link
Contributor Author

Dammit another formatting change slipped in. Basically I made some changes to src/lib_ccx/mp4.c and src/rust/src/lib.rs in an attempt to fix the mp4 slow but I'm really not sure if that's correct.

@ccextractor-bot

This comment was marked as outdated.

@PunitLodha
Copy link
Member

I'm sure porting them over to Rust would be better than calling them over FFI. I still think a PR started to specifically fix the persistence of the Dtvcc struct is the wrong place to do it as it blocks merging the PR which does seem to fix quite a bugs.

Currently there's a lot of unnecessary unsafe code, which can be avoided if we move away from the bindings

@PunitLodha
Copy link
Member

Dammit another formatting change slipped in. Basically I made some changes to src/lib_ccx/mp4.c and src/rust/src/lib.rs in an attempt to fix the mp4 slow but I'm really not sure if that's correct.

Seems correct, just need to revert the formatting changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants