Re: ffplay requesting YUY2 when -vcodec mjpeg

[Roger Pack]

weird, probably ffmpeg bug.
PR or funding welcome :)
Thanks for investigating!
-roger-

On 12/1/20, Kyle Van Riper <kyl...@gmail.com> wrote:
> Afternoon Roger,
>
> Just wanted to update you letting you know I was able to reorder the
> enumeration with my webcam, listing MJPEG rates first, and the problem no
> longer exists, matching the behavior of the Logitech C920 which also lists
> the MJPEG rates first.
>
> To summarize, it appears that if a webcam enumerates with RAW and MJPEG
> rates, if RAW rates appear first in the -list_options, the -vcodec mjpeg
> will fail (as the webcam receives a request for a RAW rate mistakenly).
> However, enumerating with the same rates, but having MJPEG list first in
> -list_options, will work without issue.
>
> Thanks for your time!
>
> On Thu, Nov 19, 2020 at 11:08 AM Kyle Van Riper <kyl...@gmail.com> wrote:
>
>> This behavior is independent of the resolution requested in my testing.
>>
>> On Wed, Nov 18, 2020 at 11:41 PM Roger Pack <roger...@gmail.com> wrote:
>>
>>> I wonder if the 640x360 param is not handled by ffmpeg right...
>>>
>>> On Tuesday, November 17, 2020, Kyle Van Riper <kyl...@gmail.com> wrote:
>>> > Thank you for your replies.
>>> >
>>> > I found that a Logitech C920 lists both raw and MJPEG and does not
>>> > have
>>> this problem. The difference is the MJPEG rates are listed first in the
>>> results of -list_options. I'm going to attempt the same and hopefully
>>> address this issue.
>>> > Thanks again!
>>> > On Mon, Nov 16, 2020 at 9:16 AM Roger Pack <roger...@gmail.com>
>>> wrote:
>>> >>
>>> >> Probably a bug. I could look at it with some funding I suppose, or
>>> you're welcome to dig into the code and purpose a patch. I. Might be
>>> able
>>> to fine up with a debug ffmpeg build eventually sometime if you'd like.
>>> >> Thanks.
>>> >>
>>> >> On Saturday, November 14, 2020, Kyle Van Riper <kyl...@gmail.com>
>>> wrote:
>>> >> > I can have the webcam enumerate with only MJPEG in its
>>> >> > -list_options
>>> and the same command will succeed. The webcam logs show it gets a
>>> request
>>> from the host for MJPEG as expected.
>>> >> >
>>> >> > However, in the scenario I pasted you, where the webcam enumerates
>>> with both RAW and MJPEG in -list_options, the above command results in
>>> the
>>> webcam logs showing it received a request for YUY2, so it sends YUY2 and
>>> thats why the packets are oddly large.
>>> >> > For some reason, if both RAW and MJPEG are in the -list_options,
>>> when -vcodec mjpeg is specified, the host still appears to request YUY2
>>> from the webcam.
>>> >> > On Sat, Nov 14, 2020 at 2:15 PM Roger Pack <roger...@gmail.com>
>>> wrote:
>>> >> >>
>>> >> >> Those packets seem oddly large for jpeg.... Maybe the webcam can't
>>> actually output jpeg but dshow isn't realizing that somehow? OK not
>>> exactly sure how to test that hypothesis...can you output from it in
>>> graphstudionext and verify it is outputting jpeg?
>>> >> >> It could be a bug in ffmpeg I'd have to do a special build for it
>>> so might not be easy...
>>> >> >>
>>> >> >>
>>> >> >> On Friday, November 13, 2020, Kyle Van Riper <kyl...@gmail.com>
>>> wrote:
>>> >> >> > H:\>ffplay -loglevel debug -stats -f dshow -vcodec mjpeg
>>> -video_size 640x360 -framerate 30 -i video="webcam" -x 640 -y 360
>>> >> >> > ffplay version 4.2.2 Copyright (c) 2003-2019 the FFmpeg
>>> >> >> > developers
>>> >> >> > built with gcc 9.2.1 (GCC) 20200122
>>> >> >> > configuration: --enable-gpl --enable-version3 --enable-sdl2
>>> --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
>>> --enable-libdav1d --enable-libbluray --enable-libfreetype
>>> --enable-libmp3lame --enable-libopencore-amrnb
>>> --enable-libopencore-amrwb
>>> --enable-libopenjpeg --enable-libopus --enable-libshine
>>> --enable-libsnappy
>>> --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx
>>> --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265
>>> --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
>>> --enable-gmp
>>> --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc
>>> --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom
>>> --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid
>>> --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2
>>> --enable-avisynth --enable-libopenmpt
>>> >> >> > libavutil 56. 31.100 / 56. 31.100
>>> >> >> > libavcodec 58. 54.100 / 58. 54.100
>>> >> >> > libavformat 58. 29.100 / 58. 29.100
>>> >> >> > libavdevice 58. 8.100 / 58. 8.100
>>> >> >> > libavfilter 7. 57.100 / 7. 57.100
>>> >> >> > libswscale 5. 5.100 / 5. 5.100
>>> >> >> > libswresample 3. 5.100 / 3. 5.100
>>> >> >> > libpostproc 55. 5.100 / 55. 5.100
>>> >> >> > Initialized direct3d renderer.
>>> >> >> > [dshow @ 0000018ba7d7ce80] Selecting pin Capture on video0B
>>> >> >> > f=0/0
>>> >> >> > dshow passing through packet of type video size 460800
>>> timestamp 6291763060000 orig timestamp 6291763053882 graph timestamp
>>> 6291763060000 diff 6118 webcam
>>> >> >> > [dshow @ 0000018ba7d7ce80] All info found
>>> >> >> > Input #0, dshow, from 'video= webcam ':
>>> >> >> > Duration: N/A, start: 629176.306000, bitrate: N/A
>>> >> >> > dshow passing through packet of type video size 460800
>>> timestamp 6291763390000 orig timestamp 6291763387215 graph timestamp
>>> 6291763390000 diff 2785 webcam
>>> >> >> > Stream #0:0, 1, 1/10000000: Video: rawvideo, 1 reference
>>> frame (YUY2 / 0x32595559), yuyv422, 640x360, 0/1, 30 fps, 30 tbr, 10000k
>>> tbn, 10000k tbc
>>> >> >> > [mjpeg @ 0000018ba7e04ac0] No JPEG data found in image
>>> >> >> > Last message repeated 1 times
>>> >> >> > dshow passing through packet of type video size 460800
>>> timestamp 6291763730000 orig timestamp 6291763720548 graph timestamp
>>> 6291763730000 diff 9452 webcam
>>> >> >> > [mjpeg @ 0000018ba7e04ac0] No JPEG data found in image
>>> >> >> >
>>> >> >> > the log continues with the last few lines repeating indefinitely
>>> >> >> > On Fri, Nov 13, 2020 at 5:38 PM Roger Pack
>>> >> >> > <roger...@gmail.com>
>>> wrote:
>>> >> >> >>
>>> >> >> >> Yeah there should be a lot more...
>>> >> >> >>
>>> >> >> >> On Friday, November 13, 2020, Kyle Van Riper
>>> >> >> >> <kyl...@gmail.com>
>>> wrote:
>>> >> >> >> > H:\>ffplay -loglevel debug -v quiet -stats -f dshow -vcodec
>>> mjpeg -video_size 640x360 -framerate 30 -i video="Webcam" -x 640 -y 360
>>> >> >> >> > ffplay version 4.2.2 Copyright (c) 2003-2019 the FFmpeg
>>> developers
>>> >> >> >> > built with gcc 9.2.1 (GCC) 20200122
>>> >> >> >> > configuration: --enable-gpl --enable-version3 --enable-sdl2
>>> --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
>>> --enable-libdav1d --enable-libbluray --enable-libfreetype
>>> --enable-libmp3lame --enable-libopencore-amrnb
>>> --enable-libopencore-amrwb
>>> --enable-libopenjpeg --enable-libopus --enable-libshine
>>> --enable-libsnappy
>>> --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx
>>> --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265
>>> --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
>>> --enable-gmp
>>> --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc
>>> --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom
>>> --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid
>>> --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2
>>> --enable-avisynth --enable-libopenmpt
>>> >> >> >> > libavutil 56. 31.100 / 56. 31.100
>>> >> >> >> > libavcodec 58. 54.100 / 58. 54.100
>>> >> >> >> > libavformat 58. 29.100 / 58. 29.100
>>> >> >> >> > libavdevice 58. 8.100 / 58. 8.100
>>> >> >> >> > libavfilter 7. 57.100 / 7. 57.100
>>> >> >> >> > libswscale 5. 5.100 / 5. 5.100
>>> >> >> >> > libswresample 3. 5.100 / 3. 5.100
>>> >> >> >> > libpostproc 55. 5.100 / 55. 5.100
>>> >> >> >> >
>>> >> >> >> > H:\>
>>> >> >> >> >
>>> >> >> >> > Is this what you were looking for? Not sure if I should
>>> >> >> >> > remove
>>> the -v quiet.
>>> >> >> >> > On Thu, Nov 12, 2020 at 10:22 PM Roger Pack <
>>> roger...@gmail.com> wrote:
>>> >> >> >> >>
>>> >> >> >> >> What's the output with loglevel debug?
>>> >> >> >> >> Thanks :)
>>> >> >> >> >>
>>> >> >> >> >> On Thursday, November 12, 2020, Kyle Van Riper <
>>> kyl...@gmail.com> wrote:
>>> >> >> >> >> > Thank you for reading this:
>>> >> >> >> >> > Using ffplay with a webcam that -list_options with:
>>> >> >> >> >> >
>>> pixel_format=yuyv422 min s=4096x2160 fps=15 max s=4096x2160 fps=30
>>> >> >> >> >> >
>>> pixel_format=nv12 min s=4096x2160 fps=15 max s=4096x2160 fps=30
>>> >> >> >> >> >
>>> vcodec=mjpeg min s=640x360 fps=15 max s=640x360 fps=60.0002
>>> >> >> >> >> >
>>> >> >> >> >> > When using the following command:
>>> >> >> >> >> > H:\>ffplay -v quiet -stats -f dshow -vcodec mjpeg
>>> -video_size 640x360 -framerate 30 -i video="Webcam"
>>> >> >> >> >> >
>>> >> >> >> >> > The webcam receives a request for YUY2 in the same way it
>>> does when -pixel_format yuyv422 is passed in place of -vcodec mjpeg. If
>>> the
>>> webcam only enumerates with MJPEG rates, then the ffplay command
>>> succeeds.
>>> >> >> >> >> > The ffplay command using -pixel_format yuyv422 works
>>> without needing to limit enumeration.
>>> >> >> >> >> > I am using windows 10 with ffplay version 4.2.2
>>> >> >> >> >> > Thank you for your time!
>>
>>
>