PiCapture Color channels reversed?

Viewing 15 posts - 1 through 15 (of 18 total)
  • Author
    Posts
  • #1224
    John Bassett
    Participant

    Here’s the setup: I’m using a Canon HF100 through the HDMI output to go into the HDMI input on the Lintest board. I’ve finally got most everything working except the blue and red channels appear to be reversed. I can swap the channels using an ffmpeg colorchannelmixer filter and make it right, but that slows the process down where livestreaming is no longer possible. I saw the thread that there’s a pivideo “command” option where the black levels can be increased, but is there any such thing in pivideo or raspivid or somewhere else in the system to swap the color channels around? Or would I be better off punting back to component cables? Please advise…

    #1225
    mwlinder
    Keymaster

    This is an issue that we haven’t seen before. Do you have any idea where in the chain that the Red/Blue data is swapped? How does the output look on a TV?

    There isn’t a simple way to reverse this data without a firmware change, but that could be a possible solution if we can’t figure out what is causing the problem. Could you please send a raspistill capture that shows the problem?

    #1227
    John Bassett
    Participant

    Ok, I’ve got some data for you. A couple things to set this up. First, the camera’s native function is at 1080i. When plugging in to the HDMI port, the card only detects a 480i signal. (The problem there is an EDID issue, and I’ve got a workaround for it, but I’ll come back to that.) Anyway, I took a raspistill image, and this was the result: raspistill image

    Note the colors on the lintest card look correct, the ethernet into the pi looks white, and the other cable on the right looks blue. This looks normal.

    I’m currently streaming with raspivid:
    https://www.youtube.com/user/jmbezekiel/live

    Note the red port on the card is blue, the blue port on the card is red, the green port on the card is yellow, the white cable is still white, but the blue cable on the right looks orange.

    Command used to launch the stream:
    raspivid -o – -t 0 -vf -hf -fps 30 -b 6000000 -md 6 | ffmpeg -re -ar 44100 -ac 2 -acodec pcm_s16le -f s16le -ac 2 -i /dev/zero -f h264 -r 30 -i – -vcodec copy -acodec aac -ab 128k -g 50 -strict experimental -f flv rtmp://a.rtmp.youtube.com/live2/key-key-key-key

    #1228
    John Bassett
    Participant

    Another output of the livestream (going to shut the livestream down): https://www.youtube.com/watch?v=gKcFNWZ4AeI

    If I dump the output of raspivid straight to a file, I get a similar result, so that takes ffmpeg and youtube out of the chain. Its got to be something in the way raspivid is interpreting the data it gets, as if a channel gets flipflopped somewhere.

    -rwxr-xr-x 1 root root 116520 Apr 28 07:19 raspistill
    -rwxr-xr-x 1 root root 78820 Apr 28 07:19 raspivid
    -rwxr-xr-x 1 root root 63932 Apr 28 07:19 raspividyuv
    -rwxr-xr-x 1 root root 60452 Apr 28 07:19 raspiyuv

    Hm…. should I try raspividyuv instead?

    #1229
    John Bassett
    Participant

    Also, the output on a TV looks correct, and comes through at 1080i— that was part of what tipped me off that there was an EDID issue at play. To get around the 480/1080i issue going to the pi, I dumped the EDID data off the monitor under linux, and load that in with pivideo so it looks like the same monitor. It doesn’t seem to affect the colorspace any, but since the lintest card reports to the camera that it can handle 1080i, the camera sends a 1080i signal instead of a 480i, and the lintest card processes it as a mode 5 1080i signal (instead of mode 6/480i).

    #1230
    mwlinder
    Keymaster

    Thanks for the additional information – this is very helpful. From the picture you sent it appears that the problem is not related to the colors at all what is the result of a mismatch between the resolution that Picapture is receiving and what the raspberry pi is expecting.

    The first step is to make sure that you can get a clean capture with raspivid. You can use the video mode LEDs or the pivideo software to determine the detected resolution. You should be getting a good full screen preview before anything else. The command “pivideo -q all -v” will provide useful feedback about how the PiCapture board is interpreting the input.

    Please note that although there is a “special” mode to capture 1080i at half resolution, interlaced formats are not supported by the HD1. The repeated, small blocks of video in the example you sent appear to be typical of a mode mismatch.

    The next version of the HD1 firmware (currently under test) will support setting custom EDID blocks that can exclude 1080i for devices that do not support 1080p and so go to 1080i.

    #1231
    mwlinder
    Keymaster

    Thanks for the additional information – this is very helpful. From the picture you sent it appears that the problem is not related to the colors at all what is the result of a mismatch between the resolution that Picapture is receiving and what the raspberry pi is expecting.

    The first step is to make sure that you can get a clean capture with raspivid. You can use the video mode LEDs or the pivideo software to determine the detected resolution. You should be getting a good full screen preview before anything else. The command “pivideo -q all -v” will provide useful feedback about how the PiCapture board is interpreting the input.

    Please note that although there is a “special” mode to capture 1080i at half resolution, interlaced formats are not supported by the HD1. The repeated, small blocks of video in the example you sent appear to be typical of a mode mismatch.

    The next version of the HD1 firmware (currently under test) will support setting custom EDID blocks that can exclude 1080i for devices that do not support 1080p and so go to 1080i.

    #1233
    John Bassett
    Participant

    Sounds good, thanks for the update. This camera in particular is interlaced only, I don’t believe it will output in progressive scan. That said, if you’ve got a beta of new firmware, I would be happy to help test it out. Just let me know what I can do to help.

    #1234
    mwlinder
    Keymaster

    The new firmware won’t help with interlaced signals, it simply allows use of an EDID block that can prevent 1080i.
    The SD1 has the ability to deinterlace 480i signals.

    #1235
    John Bassett
    Participant

    Gotcha. The short answer sounds like the hf100 wont work well (without sacrificing resolution). I’ve got a couple other cameras which might support 1080p even though the sensor quality isn’t as good.

    Thanks for the great support, I really do appreciate that you answer quickly!

    #1236
    John Bassett
    Participant

    I ran another set of tests tonight, and the interlacing isn’t the issue.

    Change of test: now using the HDMI output off a Flip UltraHD camera, 720p output. Plug it into the piCaptureHD1, it shows one flashing light, one solid (720p). According to the documentation chart, that should be mode 5. Sure enough, pivideo -q all shows mode5. So far so good.

    From there, I played a video that I had recorded with the Flip. I uploaded the original here.

    I also took an image with raspistill -md 5 -o testX-1.jpg, and it came out like this:
    image

    Colors are right, a little washed out, but nothing that can’t be corrected with the right settings.

    I then ran the following command:
    raspivid -o – -t 0 -vf -hf -fps 30 -b 12000000 -md 5 -awbg 1.0,1.0 -awb off -ex off | ffmpeg -re -ar 44100 -ac 2 -acodec pcm_s16le -f s16le -ac 2 -i /dev/zero -f h264 -r 30 -i – -vcodec copy -acodec aac -ab 128k -g 50 -strict experimental -f flv test1x.flv

    The resulting video is here.

    Again, note the blue and red channels appear to be reversed.

    Thoughts? The version of raspivid is 1.3.12, if that helps.

    #1237
    mwlinder
    Keymaster

    If raspivid/raspistill produces a good output then the PiCapture board must be working properly. The color issue has to be introduced somewhere later in the chain. If you used an actual RPi camera you would very likely see just the same problem.

    #1238
    mwlinder
    Keymaster

    If raspivid/raspistill produces a good output then the PiCapture board must be working properly. The color issue has to be introduced somewhere later in the chain. If you used an actual RPi camera you would very likely see just the same problem.

    #1239
    John Bassett
    Participant

    I don’t disagree… the image coming off raspistill is correct, so that would suggest the hardware is sound. However, what’s coming out of raspivid is definitely not correct. What does it suggest if raspistill is good, but raspivid is not? ffmpeg is doing a straight copy on the output codec- so its not manipulating the video structure, its just dumping it into the output codec. The video looks like same using youtube, mplayer, or vlc, so that’s not it. What’s left? Am I doing something weird with the raspivid command?

    #1240
    mwlinder
    Keymaster

    I may have misunderstood, but it appeared that each of your examples involved additional processing after raspivid- is this incorrect?

    Please try running raspivid all by itself – I strongly suspect that since raspistill is OK video will be as well. Just use the -o option to either preview or send to a file, without piping it to anything else.

Viewing 15 posts - 1 through 15 (of 18 total)
  • You must be logged in to reply to this topic.
John BassettColor channels reversed?