Re: [FFmpeg-trac] #3009(avcodec:open): Support mvc

[FFmpeg]

#3009: Support mvc
-+-
 Reporter:  skifreak |Owner:  (none)
 Type:  enhancement  |   Status:  open
 Priority:  wish |Component:  avcodec
  Version:  git-master   |   Resolution:
 Keywords:  h264 mvc |   Blocked By:
  mpegts |
 Blocking:   |  Reproduced by developer:  1
Analyzed by developer:  1|
-+-
Comment (by philcerf):

 For the records:
 Looks, as if 3D profiles have also been specified for HEVC
 
(https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Version_3_and_higher_profiles),
 though I guess it's not really used yet (at least not by UHD BluRays)
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-trac] #10768(avformat:new): Divergent interpretation of YUV4MPEG2 "C" parameter

[FFmpeg]

#10768: Divergent interpretation of YUV4MPEG2 "C" parameter
-+-
 Reporter:  Mingye Wang  |Owner:  (none)
 Type:  defect   |   Status:  new
 Priority:  wish |Component:  avformat
  Version:  git-master   |   Resolution:
 Keywords:  YUV4MPEG2|   Blocked By:
  y4v avchroma   |
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
Comment (by Balling):

 >However, the original ​man page specifies that they are co-sited, which
 would translate to AVCHROMA_LOC_TOPLEFT.

 422 can be only center. Left is also center...

 DV chroma is more complex. And yes, different chroma licayion in top and
 bottom fields are possible.

 >ffmpeg says it is AVCHROMA_LOC_CENTER

 Well, it probably should depend on matrix. Bt.2020 mattix likes top-left,
 bt.709 left, jpeg (so full range BT.601) is center.
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-trac] #10770(undetermined:new): avcodec_open2 overwrites flags contrary to what the doc says

[FFmpeg]

#10770: avcodec_open2 overwrites flags contrary to what the doc says
-+-
 Reporter:  Jean-| Type:  defect
  Michaël Celerier   |
   Status:  new  | Priority:  normal
Component:   |  Version:
  undetermined   |  unspecified
 Keywords:   |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
 The avcodec_open2 documentation states, about the options parameter:

 {{{
  * @param options A dictionary filled with AVCodecContext and codec-
 private
  *options, which are set on top of the options already set
 in
  *avctx, can be NULL. On return this object will be filled
 with
  *options that were not found in the avctx codec context.
 }}}

 Yet given the following program, the final assert does not pass:
 AV_CODEC_FLAG_GLOBAL_HEADER gets overwritten in the codec context's flags.

 {{{
 extern "C" {
 #include 
 }

 #include 
 int main()
 {
   auto codec = avcodec_find_encoder_by_name("libx264");
   auto c = avcodec_alloc_context3(codec);

   c->width = 1280;
   c->height = 720;
   c->time_base = (AVRational){10, int(10 * 30)};
   c->framerate = AVRational{c->time_base.den, c->time_base.num};
   c->gop_size = 0;
   c->max_b_frames = 0;
   c->pix_fmt = AV_PIX_FMT_YUV420P;
   c->strict_std_compliance = FF_COMPLIANCE_NORMAL;
   c->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;

   AVDictionary* opt{};
   av_dict_set(&opt, "flags", "low_delay", 0);

   avcodec_open2(c, codec, &opt);
   assert(c->flags & AV_CODEC_FLAG_GLOBAL_HEADER);
 }
 }}}
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-trac] #10769(undetermined:new): Issue decoding EXR images compressed with DWAB using Imagemagick

[FFmpeg]

#10769: Issue decoding EXR images compressed with DWAB using Imagemagick
-+-
 Reporter:  Richard Van  |Owner:  (none)
  Den Boom   |
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
 |  undetermined
  Version:  5.1.3|   Resolution:
 Keywords:  exr dwab |   Blocked By:
  decode |
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
Comment (by Richard Van Den Boom):

 Images are created from PNG48 files using the following command:

 convert ${FILE}.png -compress dwab ${FILE}.exr
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-trac] #10769(undetermined:new): Issue decoding EXR images compressed with DWAB using Imagemagick

[FFmpeg]

#10769: Issue decoding EXR images compressed with DWAB using Imagemagick
-+-
 Reporter:  Richard Van  |Owner:  (none)
  Den Boom   |
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
 |  undetermined
  Version:  5.1.3|   Resolution:
 Keywords:  exr dwab |   Blocked By:
  decode |
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
Changes (by Richard Van Den Boom):

 * Attachment "Electra-004045.exr" added.

 Test sample 2
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-trac] #10769(undetermined:new): Issue decoding EXR images compressed with DWAB using Imagemagick

[FFmpeg]

#10769: Issue decoding EXR images compressed with DWAB using Imagemagick
-+-
 Reporter:  Richard Van  |Owner:  (none)
  Den Boom   |
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
 |  undetermined
  Version:  5.1.3|   Resolution:
 Keywords:  exr dwab |   Blocked By:
  decode |
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
Changes (by Richard Van Den Boom):

 * Attachment "Electra-01.exr" added.

 Test Sample 1
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-trac] #10769(undetermined:new): Issue decoding EXR images compressed with DWAB using Imagemagick

[FFmpeg]

#10769: Issue decoding EXR images compressed with DWAB using Imagemagick
-+-
 Reporter:  Richard Van  |Owner:  (none)
  Den Boom   |
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
 |  undetermined
  Version:  5.1.3|   Resolution:
 Keywords:  exr dwab |   Blocked By:
  decode |
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
Changes (by Richard Van Den Boom):

 * Attachment "ffmpeg-20231231-133839.log" added.

 Ffmpeg Report
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10769>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-trac] #10769(undetermined:new): Issue decoding EXR images compressed with DWAB using Imagemagick

[FFmpeg]

#10769: Issue decoding EXR images compressed with DWAB using Imagemagick
-+-
 Reporter:  Richard Van  | Type:  defect
  Den Boom   |
   Status:  new  | Priority:  normal
Component:   |  Version:  5.1.3
  undetermined   |
 Keywords:  exr dwab |   Blocked By:
  decode |
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
 Summary of the bug: I've created an image sequence by converting PNG
 images to EXR using ImageMagick 7.1.1. If I compress them using PIZ,
 ffmpeg 5.1.4 can read them well and convert the sequence to a video
 format. If I compress them using DWAB, I get [exr @ 0x1a80240]
 decode_block() failed. errors. I tried ffmpeg 6.1 with same results.
 It seemed to me that ffmpeg 5.1.4 was able to decode DWAB compressed EXR
 files. Am I mistaken?

 How to reproduce:
 {{{
 % ffmpeg -threads 24 -thread_queue_size 4096  -r 24  -f image2 -i
 Images/Electra_24fps/Electra-%06d.exr -pix_fmt yuv422p12 -c:v ffv1 -level
 3 -slices 24 -context 1 -coder 1 -slicecrc 1  -an -r 24
 -video_track_timescale 24  Electra-MASTER_FFV1-24fps.mkv

 ffmpeg version 5.1.4, but also with 6.1
 built on Slackware-current (self-built, not official)
 }}}

 Provided sample image and report.
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-trac] #10768(avformat:new): Divergent interpretation of YUV4MPEG2 "C" parameter

[FFmpeg]

#10768: Divergent interpretation of YUV4MPEG2 "C" parameter
-+-
 Reporter:  Mingye Wang  | Type:  defect
   Status:  new  | Priority:  wish
Component:  avformat |  Version:  git-
 Keywords:  YUV4MPEG2|  master
  y4v avchroma   |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
 **Summary of the bug:**
 The way ffmpeg interprets the "C" field of Y4M is quite different from
 everybody else (vp9/av1 dialect, original dialect) does it in some ways.

 **How to reproduce:**
 Someone could make a test example that exploits the different pixel
 position interpretation, but it's not for me today. Let's just step into
 the two source files in libavformat.

 **Disagreement 1.** What's a C422/C411?
 
[https://github.com/FFmpeg/FFmpeg/blob/e9c93009fc34ca9dfcf0c6f2ed90ef1df298abf7/libavformat/yuv4mpegdec.c#L110C56-L110C56
 yuv4mpegdec.c:pix_fmt_array] says a C422 and a C411 should be
 {{{AVCHROMA_LOC_UNSPECIFIED}}}. However, the original
 [https://manned.org/yuv4mpeg.5 man page] specifies that they are co-sited,
 which would translate to {{{AVCHROMA_LOC_TOPLEFT}}}.

 **Disagreement 2.** What's a C420paldv?
 
[https://github.com/FFmpeg/FFmpeg/blob/e9c93009fc34ca9dfcf0c6f2ed90ef1df298abf7/libavformat/yuv4mpegdec.c#L92
 yuv4mpegdec.c:pix_fmt_array] says a C420paldv should be a
 {{{AV_PIX_FMT_YUV420P, AVCHROMA_LOC_TOPLEFT}}}. However, this does not
 actually describe how PAL-DV siting (as required by the original man page)
 works: you actually have Y and R at top left, but B at "center" (see
 [https://chromium.googlesource.com/webm/libvpx/+/refs/heads/main/y4minput.c#310
 y4m_convert_42xpaldv_42xjpeg], also IEC 61834-2).

 (Of course there is really no way to just specify a split chroma location
 with a single `AVChromaLocation`. For the same reason,
 
[https://github.com/FFmpeg/FFmpeg/blob/e063c1d079086150580ed7a9ad076da122e27f76/libavcodec/h2645_vui.c#L80
 libavcodec/h2645_vui.c] fails to deal with the bottom field location.)

 The issue also persists to the encoding side:
 
[https://github.com/FFmpeg/FFmpeg/blob/e063c1d079086150580ed7a9ad076da122e27f76/libavformat/yuv4mpegenc.c#L107
 yuv4mpegenc.c] happily translates any 420 + topleft into {{{C420paldv}}}.
 This allows round-trip in ffmpeg, but could go wrong when you put in
 something that actually tries to do PAL-DV.

 **Disagreement 3.** What's a C420?
 The last major disagreement is on the definition of C420. This thing is
 not defined in the original standard.

 * ffmpeg says it is AVCHROMA_LOC_CENTER, the same as C420jpeg.
 *
 
[https://github.com/xiph/rav1e/blob/4a72d17dc87759718d265f1f48192eef440f31b5/src/bin/decoder/y4m.rs#L106
 rav1e] says it should be co-sited like the C422 and C411 in the original
 standard.
 *
 
[https://github.com/mozilla/aom/blob/46b7bb243b39929c02d6decc1bdb2e39e11540d6/y4minput.c#L812
 aom] says it should be the same as C420jpeg. But it's also derived from
 some
 [https://chromium.googlesource.com/webm/libvpx/+/refs/heads/main/y4minput.c#872
 libvpx code] that treats C420mpeg2 the same as C420jpeg, so maybe it's not
 a good source of wisdom.

 

 Now, the bottom line is that ffmpeg currently round-trips with itself,
 which might just be enough for a barely-defined format like y4m. These
 disagreements only affect interoperability with other implementations,
 which are not that interoperable with each other to start with.
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".