Pixel format conversion from yuvj420p to yuv420p #606
Replies: 5 comments 3 replies
-
I don't understand what you mean, could you clarify? From what I understand:
Which step is producing the warning? How do you plan to feed the frames to libvpx if the conversion is "removed"? |
Beta Was this translation helpful? Give feedback.
-
I faced a similar issue, the warning is thrown on the first encoding thread, so if the second encoding thread starts (a second client appears), the script crashes. |
Beta Was this translation helpful? Give feedback.
-
Hi, I am also facing this below mentioned warning. Is there any way to hide those warning printing in [swscaler @ 0x7f7f7cde3000] deprecated pixel format used, make sure you did set range correctly |
Beta Was this translation helpful? Give feedback.
-
Possibly a separate issue, but I'm getting messed up colors when streaming using the webcam.py example unless I switch the pixel format to This is using This is using I'm on a Pi using the h264_omx encoder. Again possibly a separate issue, but changing |
Beta Was this translation helpful? Give feedback.
-
I recently try to use this great library and encounter these warnings, while server decoding client's yuvj420p format video. Since the warning is happened at decoding progress, I cannot bypass the warning by the above-mentioned solution and also hard to change the client's stream pixel format, which results in huge number of warning logs at every frame. And since jlaine discovered the deadlock issue in PyAV, and had disabled the log handler in PyAV in #480, the log message cannot be ignored through setting log levels in PyAV. Is there anyway, other than redirect the shell output to /dev/null, to drop the warning message in this case? |
Beta Was this translation helpful? Give feedback.
-
I'm tapping an RTSP stream that is broadcasting with pixel format
yuvj420p
, I can verify this with both ffmpeg directly and pyav.In the h264 and vp8 codec sources, we currently explicitly check for the pixel format to be
yuv420p
and run a conversion, if not. In ffmpeg 4.x, this results in a lovely deprecated warning, which has come up here before in other topics.The problem that I'm having is that the warning happens every frame, and is completely crushing the performance of the application.
I can resolve the issue by either commenting out the pixel format conversion or changing the conversion check to always format to
yuvj420p
instead here. This removes the warning and the video stream still transports successfully (at least in my testing with Chrome).My question is then, would this change to
yuvj420p
be warranted permanently, or is there a work around that you can suggest such that I can specify the pixel format of the codec for my use case?Here's a simple modified server.py with a public AXIS RTSP stream that should allow you to reproduce things:
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions