On Thu Sep 14 07:06:18 2023 +0000, Zebediah Figura wrote:
> Hi Ziqing, I've been doing some research, and I believe patch 2/6
> (committed as 320383c594c4) is incorrect. GStreamer's "codec-data" field
> is an AVCDecoderConfigurationRecord, as defined by ISO/IEC 14496-15
> (which you can see at [1]). MF_MT_MPEG_SEQUENCE_HEADER, on the other
> hand, seems to contain the raw SPS/PPS NALUs, start codes and all.
> Since Microsoft uses Annex B everywhere, it shouldn't need the
> codec-data anyway, so I'm curious now why this was added—was there a
> need for it, or did you just add it on the assumption that the two
> attributes mapped to each other?
> [1] https://doc-kurento.readthedocs.io/en/latest/knowledge/h264.html#gstreamer-…
This was added because mp4mux is requiring it: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/…
Without codec_data set, mp4mux element fails. And according to my test, setting codec_data to MF_MT_MPEG_SEQUENCE_HEADER is OK, becuase I finally successfully generate a mp4 file which is able to be played by video player.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3636#note_45303
On Thu Aug 31 18:29:16 2023 +0000, Matteo Bruni wrote:
> That's 100% it :rolling_eyes:
> But yeah, that's what I mean when I say that d3d QXL test results ought
> to be ignored.
That sounds like a bug in QXL. Is there a QEmu bug report for this issue?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3694#note_45290