CiaranWoodward / smpteViewer

Small program (student project) to generate and view video carried by the SMPTE2022-6 protocol for testing purposes.
2 stars 0 forks source link

what about 4:2:0 10bit video? #1

Open miah-hl opened 6 years ago

miah-hl commented 6 years ago

i want to view a video using this project,but found that the sampling structure is unmatch.could you tell me how i can fix this?i am a newbee

CiaranWoodward commented 6 years ago

Hi there, thanks for getting in touch! Firstly, just a disclaimer: this is a project I wrote for a university coursework and is quite narrow in scope - it might need quite a bit of work to expand! At the moment it has a very minimal set of features.

Also could I confirm that you have a pcap file containing the SMPTE2022 data in ethernet packets? Are you able to share this?

Anyway, in order to add this functionality, you will be mainly interested in the imagePacker class, which takes SMPTE2022 ethernet frames and packs them together into a single image 'frame', packed into an OPENGL image buffer. As far as I am aware, opengl does not natively support 4:2:0 video, so you will need to mock it (by for instance, duplicating the previous row's chroma data on every second row). This image buffer is filled at the bottom of the getNextPixels method. You may also have to add a configuration to the init method in the same class. Currently, it is 10 bit video that is supported, but it is truncated to 8 bits for rendering.

Let me know how it goes, or if you need any more info.

miah-hl commented 6 years ago

Thanks for replies. I do have a pcap file containing the SMPTE2022 data in ethernet packets, which was sdi output of a camera packed by the specified SMPTE2022-6 gateway.The file is too big to upload directly, could you tell me your e-mail address? Now I want to display it through your project, but found the video source ( camera ) doesn't support the out format of 4:2:2 10bit video. It's 1920*1080 60i. And based on the SAV EAV I supposed it's 10bit format.

By the way, I can also get the pcap file of a displayer, which satisfy the request of 1920*1080 4:2:2 10bit. But it only can output progressive video rather than interlaced video,. It's 50p video. Maybe this wil be easier to display?

PS: The real capture package is 4 bytes longer than the project generated one. It's video_timestamp field before the actual SDI data (HBRMT_payload).

CiaranWoodward commented 6 years ago

Hi, my email address is [my github username] @gmail.com. I'm out of the country at the moment so won't be able to look at it straight away, but will have a look when I'm back.

I think the 4:2:2 1080p would be easier to adapt into this program to run, (probably only a change in the init method) but obviously requires significantly more bandwidth than what you are currently using, so not sure if it will be suitable.

Regarding the longer packet length, I expect there might be other issues like this, but it should only be a couple of lines of code to cope with it.

CiaranWoodward commented 6 years ago

Hi, I took a look at that file for you and made some commits to try and view it. 3 things: 1) The file was in pcapng format, but it needs to be in the old style pcap format. It's easy to convert, just open it in wireshark and save as wireshark/tcpdump - pcap format. 2) After looking at the data, there are some patterns that I'm not sure how to deal with - and I no longer have access to the specification so I'm not sure if you could explain? For HD video from my understanding, the SAV/EAV packets should happen at the same time in each channel, but I am sometimes seeing 0x3ff 0x000 0x000 in only one of the channels, followed by an invalid XYZ word. Does this make any sense to you? strangehistory because I'm not sure what to do with that packet, the output video is a little bit strange :P but some chunks of picture are correctly displayed so can't be that far off! badvideo 3) from the PCAP, there are some chunks of data missing altogether so if that happens I just drop the affected frames - there is enough data to work with though.