Re: [FFmpeg-trac] #11200(avformat:new): FFmpeg unintelligently meddled input timestamps during "-c copy" (was: FFmpeg setting all timestamps to end)
#11200: FFmpeg unintelligently meddled input timestamps during "-c copy" -+- Reporter: hachi|Owner: (none) Type: enhancement | Status: new Priority: normal |Component: avformat Version: git-master | Resolution: Keywords: timestamp| Blocked By: Non-monotonic DTS | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Changes (by MasterQuestionable): * cc: MasterQuestionable (added) * component: undetermined => avformat * summary: FFmpeg setting all timestamps to end => FFmpeg unintelligently meddled input timestamps during "-c copy" * version: unspecified => git-master * keywords: timestamp DTS Non-monotonous => timestamp Non-monotonic DTS * type: defect => enhancement Comment: ͏ Try "-copyts" whatsoever..? ͏ https://trac.ffmpeg.org/ticket/11034#comment:1 ͏ Such peculiar timestamps indicated input seemingly broken. ͏ Caution that FFmpeg currently may not handle non-perfectly-valid files in the most sensible way: ͏ https://trac.ffmpeg.org/ticket/11056#comment:18 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11200#comment:3> 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".
Re: [FFmpeg-trac] #11199(avcodec:new): Unusual GIF decoding failure (display OK in browser)
#11199: Unusual GIF decoding failure (display OK in browser)
-+-
Reporter: |Owner: (none)
MasterQuestionable |
Type: defect | Status: new
Priority: normal |Component: avcodec
Version: git-master | Resolution:
Keywords: gif | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+-
Description changed by MasterQuestionable:
Old description:
> ͏ "Error submitting packet to decoder: Invalid data found when
> processing input"
> ͏ When: `ffmpeg -i "DecFail.gif" "x.gif"`
>
> ͏ [https://ffmpeg.org/ffmpeg.html#Stream-copy ͏"-c copy"] no error;
> but doesn't fix the image.
>
> ͏ Extra:
> [[
> {{{
> > exiftool -U -ee3 -g3:5:2 -api "RequestAll=0" -api "ByteUnit=Binary"
> "DecFail.gif"
> ExifTool
> ExifTool Version Number : 12.96
> Error : File format error
> System:Other
> File Name : DecFail.gif
> Directory : .
> File Size : 8.0 KiB
> File Permissions: -rw-rw-rw-
> System:Time
> File Modification Date/Time : 2024:09:17 05:02:38+00:00
> File Access Date/Time : 2024:09:17 05:02:38+00:00
> File Creation Date/Time : 2024:09:17 05:02:38+00:00
> GIF:Other
> File Type : GIF
> File Type Extension : gif
> MIME Type : image/gif
> GIF:Image
> GIF Version : 89a
> Transparent Color : 0
> Frame Count : 2
> Duration: 0.07 s
> GIF-ScreenDescriptor:Image
> Image Width : 96
> Image Height: 96
> Has Color Map : Yes
> Color Resolution Depth : 8
> Bits Per Pixel : 8
> Background Color: 0
> GIF-Animation:Image
> Animation Iterations: Infinite
> Composite:Image
> Image Size : 96x96
> Megapixels : 0.009
>
> > exiftool "-*=" "-CommonIFD0=" "DecFail.gif" -o "x.gif"
> Error: Format error in file - DecFail.gif
> 0 image files updated
> 1 files weren't updated due to errors
> }}}
> ]]
New description:
͏ "Error submitting packet to decoder: Invalid data found when
processing input"
͏ When: `ffmpeg -v debug -hide_banner -nostdin -nostats -i
"DecFail.gif" "x.gif"`
͏ [https://ffmpeg.org/ffmpeg.html#Stream-copy ͏"-c copy"] no error; but
doesn't fix the image.
͏ Extra:
[[
{{{
> exiftool -U -ee3 -g3:5:2 -api "RequestAll=0" -api "ByteUnit=Binary"
"DecFail.gif"
ExifTool
ExifTool Version Number : 12.96
Error : File format error
System:Other
File Name : DecFail.gif
Directory : .
File Size : 8.0 KiB
File Permissions: -rw-rw-rw-
System:Time
File Modification Date/Time : 2024:09:17 05:02:38+00:00
File Access Date/Time : 2024:09:17 05:02:38+00:00
File Creation Date/Time : 2024:09:17 05:02:38+00:00
GIF:Other
File Type : GIF
File Type Extension : gif
MIME Type : image/gif
GIF:Image
GIF Version : 89a
Transparent Color : 0
Frame Count : 2
Duration: 0.07 s
GIF-ScreenDescriptor:Image
Image Width : 96
Image Height: 96
Has Color Map : Yes
Color Resolution Depth : 8
Bits Per Pixel : 8
Background Color: 0
GIF-Animation:Image
Animation Iterations: Infinite
Composite:Image
Image Size : 96x96
Megapixels : 0.009
> exiftool -v5 "-*=" "-CommonIFD0=" "DecFail.gif" -o "x.gif"
...
Creating tags in:
Application Extension: NETSCAPE/2.0
Graphic Control: delay=0.03
Image: left=0 top=0 width=96 height=96
Graphic Control: delay=0.04
TransparentColor = 0
Image: left=0 top=0 width=96 he
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by MasterQuestionable): ͏ Even if targeted specific frame rate: maintaining which constantly may not be practical. ͏ And absolute CFR is simply impossible: that demands absolute precision, no system could ever be capable of. ͏ And delay within 10 ms is generally indiscernable to human. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:26> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by Balling): "Wouldn't your system ever jitter or drop frame..?" Jitter is introduced by mkv container, that has millisecond durations, no PTS or DTS. In mkv fork webm they actually introduced some funny way how to signal constant frame rate, apparently bug in firefox that it does not support that in youtube, lol https://bugzilla.mozilla.org/show_bug.cgi?id=1903466 In practice some files on Youtube somehow have this strange issue with 29970/1000 fps instead of 30/1.001, maybe this bug. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:25> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): "Because the YUV (YCrCb) color space is a superset of the RGB color space, illegal RGB values can be generated when YUV is converted to RGB" do you understabd that those values are legal in the new specs because they allow negative RGB and those negative RGB are just converted to XYZ where it is now valid and makes perfect sense? If you send me an email to val.zapod...@gmail.com I can send you the xvYCC ISO standard, free of charge. At the time illegal RGB was just because negative RGB could not be stored... But now it is stored just fine at least on Apple devices. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:50> 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".
Re: [FFmpeg-trac] #11200(undetermined:new): FFmpeg setting all timestamps to end
#11200: FFmpeg setting all timestamps to end -+- Reporter: hachi|Owner: (none) Type: defect | Status: new Priority: normal |Component: | undetermined Version: unspecified | Resolution: Keywords: timestamp| Blocked By: DTS Non-monotonous | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): Please do. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11200#comment:2> 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".
Re: [FFmpeg-trac] #11200(undetermined:new): FFmpeg setting all timestamps to end
#11200: FFmpeg setting all timestamps to end -+- Reporter: hachi|Owner: (none) Type: defect | Status: new Priority: normal |Component: | undetermined Version: unspecified | Resolution: Keywords: timestamp| Blocked By: DTS Non-monotonous | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by hachi): If needed I can attach a 10MB file to see how subtitles are affected -- Ticket URL: <https://trac.ffmpeg.org/ticket/11200#comment:1> 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".
Re: [FFmpeg-trac] #11200(undetermined:new): FFmpeg setting all timestamps to end
#11200: FFmpeg setting all timestamps to end -+- Reporter: hachi|Owner: (none) Type: defect | Status: new Priority: normal |Component: | undetermined Version: unspecified | Resolution: Keywords: timestamp| Blocked By: DTS Non-monotonous | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Changes (by hachi): * Attachment "input.mkv" added. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11200> 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] #11200(undetermined:new): FFmpeg setting all timestamps to end
#11200: FFmpeg setting all timestamps to end
-+-
Reporter: hachi| Type: defect
Status: new | Priority: normal
Component: | Version:
undetermined | unspecified
Keywords: timestamp| Blocked By:
DTS Non-monotonous |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+-
Summary of the bug:
FFmpeg incorrecly alters timestamps, which results in subtitles not
displayed when viewing output file:
{{{
[sost#0:6/copy @ 0x127e150b0] Non-monotonic DTS; previous: 1268750,
current: 150; changing to 1268750. This may result in incorrect timestamps
in the output file.
[sost#0:6/copy @ 0x127e150b0] Non-monotonic DTS; previous: 1268750,
current: 2020; changing to 1268750. This may result in incorrect
timestamps in the output file.
[sost#0:6/copy @ 0x127e150b0] Non-monotonic DTS; previous: 1268750,
current: 5070; changing to 1268750. This may result in incorrect
timestamps in the output file.
}}}
I have not found an option to preserve original timestamps and bypass this
error.
How to reproduce:
{{{
% ffmpeg -i input.mkv -c copy -map 0 output.mkv
ffmpeg version 7.0.2 Copyright (c) 2000-2024 the FFmpeg developers
built with Apple clang version 15.0.0 (clang-1500.3.9.4)
}}}
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11200>
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".
Re: [FFmpeg-trac] #11199(avcodec:new): Unusual GIF decoding failure (display OK in browser)
#11199: Unusual GIF decoding failure (display OK in browser) -+- Reporter: |Owner: (none) MasterQuestionable | Type: defect | Status: new Priority: normal |Component: avcodec Version: git-master | Resolution: Keywords: gif | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Changes (by MasterQuestionable): * Attachment "DecFail.gif" added. https://remark42.browserleaks.com/api/v1/avatar/ff2bede560ba3471281f546ab3f92c37df875940.image -- Ticket URL: <https://trac.ffmpeg.org/ticket/11199> 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] #11199(avcodec:new): Unusual GIF decoding failure (display OK in browser)
#11199: Unusual GIF decoding failure (display OK in browser)
-+-
Reporter: | Type: defect
MasterQuestionable |
Status: new | Priority: normal
Component: avcodec | Version: git-
| master
Keywords: gif | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+-
͏ "Error submitting packet to decoder: Invalid data found when
processing input"
͏ When: `ffmpeg -i "DecFail.gif" "x.gif"`
͏ [https://ffmpeg.org/ffmpeg.html#Stream-copy ͏"-c copy"] no error; but
doesn't fix the image.
͏ Extra:
[[
{{{
> exiftool -U -ee3 -g3:5:2 -api "RequestAll=0" -api "ByteUnit=Binary"
"DecFail.gif"
ExifTool
ExifTool Version Number : 12.96
Error : File format error
System:Other
File Name : DecFail.gif
Directory : .
File Size : 8.0 KiB
File Permissions: -rw-rw-rw-
System:Time
File Modification Date/Time : 2024:09:17 05:02:38+00:00
File Access Date/Time : 2024:09:17 05:02:38+00:00
File Creation Date/Time : 2024:09:17 05:02:38+00:00
GIF:Other
File Type : GIF
File Type Extension : gif
MIME Type : image/gif
GIF:Image
GIF Version : 89a
Transparent Color : 0
Frame Count : 2
Duration: 0.07 s
GIF-ScreenDescriptor:Image
Image Width : 96
Image Height: 96
Has Color Map : Yes
Color Resolution Depth : 8
Bits Per Pixel : 8
Background Color: 0
GIF-Animation:Image
Animation Iterations: Infinite
Composite:Image
Image Size : 96x96
Megapixels : 0.009
> exiftool "-*=" "-CommonIFD0=" "DecFail.gif" -o "x.gif"
Error: Format error in file - DecFail.gif
0 image files updated
1 files weren't updated due to errors
}}}
]]
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11199>
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".
Re: [FFmpeg-trac] #11198(avformat:closed): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment)
segments
-+-
Reporter: adamvaul |Owner: (none)
Type: defect | Status: closed
Priority: normal |Component: avformat
Version: git-master | Resolution: invalid
Keywords: hls | Blocked By:
metadata segment |
Blocking: | Reproduced by developer: 1
Analyzed by developer: 1|
-+-
Description changed by adamvaul:
Old description:
> Summary of the bug:
>
> See a partial fix (12 years ago) here:
> https://trac.ffmpeg.org/ticket/2230
>
> This only provided a fix for metadata flags
> -service_name
> -service_provider
> to be passed on to the chained mpegts muxer
>
> but it did not pass on the flags for
> -mpegts_pmt_start_pid or
> -mpegts_start_pid
>
> You can obtain a copy of big buck bunny here:
> https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
>
> What I want:
>
> {{{
> -mpegts_pmt_start_pid and/or -mpegts_start_pid flags to be passed on to
> the mpegts muxer
>
> Then, if you use TSDuck tsanalyze tool (or another mpegts analyzyer) on
> .ts segment files you should see
> tsanalyze output of final file:
> |===|
> | PID: 0x01E0 (480)
> PMT|
>
> }}}
>
> What I get:
>
> {{{
> |=======|
> | PID: 0x1000 (4096)
> PMT|
> }}}
>
>
>
> How to reproduce:
>
> ffmpeg -i BigBuckBunny_320x180.mp4 -t 24 -hls_playlist_type vod
> -sc_threshold 0 -mpegts_pmt_start_pid 480 -mpegts_start_pid 481 -f hls
> BigBuckBunny.m3u8
>
> See Report logs attached.
New description:
Summary of the bug:
See a partial fix (12 years ago) here: https://trac.ffmpeg.org/ticket/2230
This only provided a fix for metadata flags
-service_name
-service_provider
to be passed on to the chained mpegts muxer
but it did not pass on the flags for
-mpegts_pmt_start_pid or
-mpegts_start_pid
You can obtain a copy of big buck bunny here:
https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
What I want:
{{{
-mpegts_pmt_start_pid and/or -mpegts_start_pid flags to be passed on to
the mpegts muxer
Then, if you use TSDuck tsanalyze tool (or another mpegts analyzyer) on
.ts segment files you should see
tsanalyze output of final file:
|===|
| PID: 0x01E0 (480)
PMT|
}}}
What I get:
{{{
|===|
| PID: 0x1000 (4096)
PMT|
}}}
How to reproduce:
{{{
ffmpeg -i BigBuckBunny_320x180.mp4 -t 24 -hls_playlist_type vod
-sc_threshold 0 -mpegts_pmt_start_pid 480 -mpegts_start_pid 481 -f hls
BigBuckBunny.m3u8
}}}
See Report logs attached.
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11198#comment:11>
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".
Re: [FFmpeg-trac] #11198(avformat:closed): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment)
segments
-+-
Reporter: adamvaul |Owner: (none)
Type: defect | Status: closed
Priority: normal |Component: avformat
Version: git-master | Resolution: invalid
Keywords: hls | Blocked By:
metadata segment |
Blocking: | Reproduced by developer: 1
Analyzed by developer: 1|
-+-
Description changed by adamvaul:
Old description:
> Summary of the bug:
>
> See a partial fix (12 years ago) here:
> https://trac.ffmpeg.org/ticket/2230
>
> This only provided a fix for metadata flags
> -service_name
> -service_provider
> to be passed on to the chained mpegts muxer
>
> but it did not pass on the flags for
> -mpegts_pmt_start_pid or
> -mpegts_start_pid
>
> You can obtain a copy of big buck bunny here:
> https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
>
> What I want:
>
> {{{
> -mpegts_pmt_start_pid and/or -mpegts_start_pid flags to be passed on to
> the mpegts muxer
>
> Then, if you use TSDuck tsanalyze tool (or another mpegts analyzyer) on
> .ts segment files you should see
> tsanalyze output of final file:
> |===|
> | PID: 0x01E0 (480)
> PMT|
>
> }}}
>
> What I get:
>
> {{{
> |===|
> | PID: 0x1000 (4096)
> PMT|
> }}}
>
>
>
> How to reproduce:
> {{{
> % ffmpeg -i BigBuckBunny_320x180.mp4 -t 24 -start_number 1 -hls_time 6
> -segment_time 6 -hls_list_size 0 -hls_segment_filename
> BigBuckBunny_%05d.ts -hls_playlist_type vod -sc_threshold 0
> -mpegts_pmt_start_pid 480 -mpegts_start_pid 481 -f hls BigBuckBunny.m3u8
> }}}
>
> See Report logs attached.
New description:
Summary of the bug:
See a partial fix (12 years ago) here: https://trac.ffmpeg.org/ticket/2230
This only provided a fix for metadata flags
-service_name
-service_provider
to be passed on to the chained mpegts muxer
but it did not pass on the flags for
-mpegts_pmt_start_pid or
-mpegts_start_pid
You can obtain a copy of big buck bunny here:
https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
What I want:
{{{
-mpegts_pmt_start_pid and/or -mpegts_start_pid flags to be passed on to
the mpegts muxer
Then, if you use TSDuck tsanalyze tool (or another mpegts analyzyer) on
.ts segment files you should see
tsanalyze output of final file:
|===|
| PID: 0x01E0 (480)
PMT|
}}}
What I get:
{{{
|===|
| PID: 0x1000 (4096)
PMT|
}}}
How to reproduce:
ffmpeg -i BigBuckBunny_320x180.mp4 -t 24 -hls_playlist_type vod
-sc_threshold 0 -mpegts_pmt_start_pid 480 -mpegts_start_pid 481 -f hls
BigBuckBunny.m3u8
See Report logs attached.
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11198#comment:10>
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".
Re: [FFmpeg-trac] #11198(avformat:closed): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments -+- Reporter: adamvaul |Owner: (none) Type: defect | Status: closed Priority: normal |Component: avformat Version: git-master | Resolution: invalid Keywords: hls | Blocked By: metadata segment | Blocking: | Reproduced by developer: 1 Analyzed by developer: 1| -+- Comment (by adamvaul): Full working command here: ffmpeg -i BigBuckBunny_320x180.mp4 -t 24 -hls_playlist_type vod -sc_threshold 0 -hls_segment_options mpegts_pmt_start_pid=480:mpegts_start_pid=481 -f hls BigBuckBunny.m3u8 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11198#comment:9> 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".
Re: [FFmpeg-trac] #11198(avformat:closed): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment)
segments
-+-
Reporter: adamvaul |Owner: (none)
Type: defect | Status: closed
Priority: normal |Component: avformat
Version: git-master | Resolution: invalid
Keywords: hls | Blocked By:
metadata segment |
Blocking: | Reproduced by developer: 1
Analyzed by developer: 1|
-+-
Description changed by adamvaul:
Old description:
> Summary of the bug:
>
> See a partial fix (12 years ago) here:
> https://trac.ffmpeg.org/ticket/2230
>
> This only provided a fix for metadata flags
> -service_name
> -service_provider
> to be passed on to the chained mpegts muxer
>
> but it did not pass on the flags for
> -mpegts_pmt_start_pid or
> -mpegts_start_pid
>
> You can obtain a copy of big buck bunny here:
> https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
>
> What I want:
>
> {{{
> -mpegts_pmt_start_pid and/or -mpegts_start_pid flags to be passed on to
> the mpegts muxer
>
> Then, if you use TSDuck tsanalyze tool (or another mpegts analyzyer) on
> .ts segment files you should see
> tsanalyze output of final file:
> |===|
> | PID: 0x01E0 (480)
> PMT|
>
> }}}
>
> What I get:
>
> {{{
> |===|
> | PID: 0x1000 (4096)
> PMT|
> }}}
>
>
>
> How to reproduce:
> {{{
> % ffmpeg -i BigBuckBunny_320x180.mp4 -t 24 -start_number 1 -hls_time 6
> -segment_time 6 -hls_list_size 0 -hls_segment_filename
> BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
> -sc_threshold 0 -mpegts_pmt_start_pid 480 -mpegts_start_pid 481 -f hls
> BigBuckBunny_320x180_6S600K360.m3u8
> }}}
>
> See Report logs attached.
New description:
Summary of the bug:
See a partial fix (12 years ago) here: https://trac.ffmpeg.org/ticket/2230
This only provided a fix for metadata flags
-service_name
-service_provider
to be passed on to the chained mpegts muxer
but it did not pass on the flags for
-mpegts_pmt_start_pid or
-mpegts_start_pid
You can obtain a copy of big buck bunny here:
https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
What I want:
{{{
-mpegts_pmt_start_pid and/or -mpegts_start_pid flags to be passed on to
the mpegts muxer
Then, if you use TSDuck tsanalyze tool (or another mpegts analyzyer) on
.ts segment files you should see
tsanalyze output of final file:
|===|
| PID: 0x01E0 (480)
PMT|
}}}
What I get:
{{{
|===|
| PID: 0x1000 (4096)
PMT|
}}}
How to reproduce:
{{{
% ffmpeg -i BigBuckBunny_320x180.mp4 -t 24 -start_number 1 -hls_time 6
-segment_time 6 -hls_list_size 0 -hls_segment_filename
BigBuckBunny_%05d.ts -hls_playlist_type vod -sc_threshold 0
-mpegts_pmt_start_pid 480 -mpegts_start_pid 481 -f hls BigBuckBunny.m3u8
}}}
See Report logs attached.
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11198#comment:8>
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".
Re: [FFmpeg-trac] #11198(avformat:closed): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment)
segments
-+-
Reporter: adamvaul |Owner: (none)
Type: defect | Status: closed
Priority: normal |Component: avformat
Version: git-master | Resolution: invalid
Keywords: hls | Blocked By:
metadata segment |
Blocking: | Reproduced by developer: 1
Analyzed by developer: 1|
-+-
Old description:
> Summary of the bug:
>
> See a partial fix (12 years ago) here:
> https://trac.ffmpeg.org/ticket/2230
>
> This only provided a fix for metadata flags
> -service_name
> -service_provider
> to be passed on to the chained mpegts muxer
>
> but it did not pass on the flags for
> -mpegts_pmt_start_pid or
> -mpegts_start_pid
>
> You can obtain a copy of big buck bunny here:
> https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
>
> What I want:
>
> {{{
> -mpegts_pmt_start_pid and/or -mpegts_start_pid flags to be passed on to
> the mpegts muxer
>
> Then, if you use TSDuck tsanalyze tool (or another mpegts analyzyer) on
> .ts segment files you should see
> tsanalyze output of final file:
> |===|
> | PID: 0x01E0 (480)
> PMT|
>
> }}}
>
> What I get:
>
> {{{
> |===|
> | PID: 0x1000 (4096)
> PMT|
> }}}
>
>
>
> How to reproduce:
> {{{
> % ffmpeg -report -i BigBuckBunny_320x180.mp4 -t 24 -c:v libx264 -crf 22
> -minrate:v 60 -maxrate:v 60 -bufsize:v 120 -preset fast
> -profile:v main -pix_fmt yuv420p -g 30 -keyint_min 30 -level 4.0 -s
> 640x360 -c:a aac -minrate:a 96000 -maxrate:a 96000 -bufsize:a 192000
> -strict -2 -start_number 1 -hls_time 6 -segment_time 6 -hls_list_size 0
> -force_key_frames
> "expr:if(isnan(prev_forced_n),1,eq(n,prev_forced_n+30))" -sn
> -output_ts_offset 0.6667 -hls_segment_filename
> BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
> -sc_threshold 0 -mpegts_pmt_start_pid 480 -streamid 0:481 -streamid 1:482
> -metadata service_provider="Some provider" -metadata service_name="Some
> Channel" -f hls BigBuckBunny_320x180_6S600K360.m3u8
> }}}
>
> See Report logs attached.
New description:
Summary of the bug:
See a partial fix (12 years ago) here: https://trac.ffmpeg.org/ticket/2230
This only provided a fix for metadata flags
-service_name
-service_provider
to be passed on to the chained mpegts muxer
but it did not pass on the flags for
-mpegts_pmt_start_pid or
-mpegts_start_pid
You can obtain a copy of big buck bunny here:
https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
What I want:
{{{
-mpegts_pmt_start_pid and/or -mpegts_start_pid flags to be passed on to
the mpegts muxer
Then, if you use TSDuck tsanalyze tool (or another mpegts analyzyer) on
.ts segment files you should see
tsanalyze output of final file:
|===|
| PID: 0x01E0 (480)
PMT|
}}}
What I get:
{{{
|===|
| PID: 0x1000 (4096)
PMT|
}}}
How to reproduce:
{{{
% ffmpeg -i BigBuckBunny_320x180.mp4 -t 24 -start_number 1 -hls_time 6
-segment_time 6 -hls_list_size 0 -hls_segment_filename
BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
-sc_threshold 0 -mpegts_pmt_start_pid 480 -mpegts_start_pid 481 -f hls
BigBuckBunny_320x180_6S600K360.m3u8
}}}
See Report logs attached.
--
Comment (by adamvaul):
Thank you so much. I will try this!
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11198#comment:7>
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".
Re: [FFmpeg-trac] #11198(avformat:closed): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments -+- Reporter: adamvaul |Owner: (none) Type: defect | Status: closed Priority: normal |Component: avformat Version: git-master | Resolution: invalid Keywords: hls | Blocked By: metadata segment | Blocking: | Reproduced by developer: 1 Analyzed by developer: 1| -+- Changes (by Gyan): * priority: important => normal * version: => git-master -- Ticket URL: <https://trac.ffmpeg.org/ticket/11198#comment:6> 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".
Re: [FFmpeg-trac] #11198(avformat:closed): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments -+- Reporter: adamvaul |Owner: (none) Type: defect | Status: closed Priority: important|Component: avformat Version: | Resolution: invalid Keywords: hls | Blocked By: metadata segment | Blocking: | Reproduced by developer: 1 Analyzed by developer: 1| -+- Changes (by Gyan): * status: new => closed * resolution: => invalid Comment: Your command uses the HLS muxer (`-f hls`), for which you have to specify `-hls_segment_options mpegts_pmt_start_pid=X:mpegts_start_pid=Y` to pass on the values -- Ticket URL: <https://trac.ffmpeg.org/ticket/11198#comment:5> 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".
Re: [FFmpeg-trac] #11198(avformat:new): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment)
segments
-+-
Reporter: adamvaul |Owner: (none)
Type: defect | Status: new
Priority: important|Component: avformat
Version: | Resolution:
Keywords: hls | Blocked By:
metadata segment |
Blocking: | Reproduced by developer: 1
Analyzed by developer: 1|
-+-
Description changed by adamvaul:
Old description:
> Summary of the bug:
>
> See a partial fix (12 years ago) here:
> https://trac.ffmpeg.org/ticket/2230
>
> This only provided a fix for metadata flags
> -service_name
> -service_provider
> to be passed on to the chained mpegts muxer
>
> What I want:
>
> {{{
> -mpegts_pmt_start_pid 480 (see command below) to be respected and produce
> PMT PID: 0x01E0 (480) in each segment eg. 1.ts - 8.ts
> }}}
>
> What I get:
>
> {{{
> mpegts uses the default PID for PMT of 0x1000
> PMT PID: 0x1000 (4096)
> }}}
>
>
>
> How to reproduce:
> {{{
> % ffmpeg -report -i BigBuckBunny_320x180.mp4 -t 24 -c:v libx264 -crf 22
> -minrate:v 60 -maxrate:v 60 -bufsize:v 120 -preset fast
> -profile:v main -pix_fmt yuv420p -g 30 -keyint_min 30 -level 4.0 -s
> 640x360 -c:a aac -minrate:a 96000 -maxrate:a 96000 -bufsize:a 192000
> -strict -2 -start_number 1 -hls_time 6 -segment_time 6 -hls_list_size 0
> -force_key_frames
> "expr:if(isnan(prev_forced_n),1,eq(n,prev_forced_n+30))" -sn
> -output_ts_offset 0.6667 -hls_segment_filename
> BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
> -sc_threshold 0 -mpegts_pmt_start_pid 480 -streamid 0:481 -streamid 1:482
> -metadata service_provider="Some provider" -metadata service_name="Some
> Channel" -f hls BigBuckBunny_320x180_6S600K360.m3u8
> }}}
>
> See Report logs attached.
New description:
Summary of the bug:
See a partial fix (12 years ago) here: https://trac.ffmpeg.org/ticket/2230
This only provided a fix for metadata flags
-service_name
-service_provider
to be passed on to the chained mpegts muxer
What I want:
{{{
If you use TSDuck tsanalyze tool (or another mpegts analyzyer) on the
created .ts segment files you should see
tsanalyze output of final file:
|===|
| PID: 0x01E0 (480)
PMT|
-mpegts_pmt_start_pid 480 (see command below) to be respected and produce
PMT PID: 0x01E0 (480) in each segment eg. 00001.ts - 8.ts
}}}
What I get:
{{{
mpegts uses the default PID for PMT of 0x1000
PMT PID: 0x1000 (4096)
}}}
How to reproduce:
{{{
% ffmpeg -report -i BigBuckBunny_320x180.mp4 -t 24 -c:v libx264 -crf 22
-minrate:v 60 -maxrate:v 60 -bufsize:v 120 -preset fast
-profile:v main -pix_fmt yuv420p -g 30 -keyint_min 30 -level 4.0 -s
640x360 -c:a aac -minrate:a 96000 -maxrate:a 96000 -bufsize:a 192000
-strict -2 -start_number 1 -hls_time 6 -segment_time 6 -hls_list_size 0
-force_key_frames "expr:if(isnan(prev_forced_n),1,eq(n,prev_forced_n+30))"
-sn -output_ts_offset 0.6667 -hls_segment_filename
BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
-sc_threshold 0 -mpegts_pmt_start_pid 480 -streamid 0:481 -streamid 1:482
-metadata service_provider="Some provider" -metadata service_name="Some
Channel" -f hls BigBuckBunny_320x180_6S600K360.m3u8
}}}
See Report logs attached.
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11198#comment:2>
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".
Re: [FFmpeg-trac] #11198(avformat:new): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment)
segments
-+-
Reporter: adamvaul |Owner: (none)
Type: defect | Status: new
Priority: important|Component: avformat
Version: | Resolution:
Keywords: hls | Blocked By:
metadata segment |
Blocking: | Reproduced by developer: 1
Analyzed by developer: 1|
-+-
Description changed by adamvaul:
Old description:
> Summary of the bug:
>
> See a partial fix (12 years ago) here:
> https://trac.ffmpeg.org/ticket/2230
>
> This only provided a fix for metadata flags
> -service_name
> -service_provider
> to be passed on to the chained mpegts muxer
>
> What I want:
>
> {{{
> PMT PID: 0x01E0 (480)
> }}}
>
> What I get:
>
> {{{
> PMT PID: 0x1000 (4096)
> }}}
>
>
>
> How to reproduce:
> {{{
> % ffmpeg -report -i BigBuckBunny_320x180.mp4 -t 24 -c:v libx264 -crf 22
> -minrate:v 60 -maxrate:v 60 -bufsize:v 120 -preset fast
> -profile:v main -pix_fmt yuv420p -g 30 -keyint_min 30 -level 4.0 -s
> 640x360 -c:a aac -minrate:a 96000 -maxrate:a 96000 -bufsize:a 192000
> -strict -2 -start_number 1 -hls_time 6 -segment_time 6 -hls_list_size 0
> -force_key_frames
> "expr:if(isnan(prev_forced_n),1,eq(n,prev_forced_n+30))" -sn
> -output_ts_offset 0.6667 -hls_segment_filename
> BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
> -sc_threshold 0 -mpegts_pmt_start_pid 480 -streamid 0:481 -streamid 1:482
> -metadata service_provider="Some provider" -metadata service_name="Some
> Channel" -f hls BigBuckBunny_320x180_6S600K360.m3u8
> }}}
>
> See Report logs attached.
New description:
Summary of the bug:
See a partial fix (12 years ago) here: https://trac.ffmpeg.org/ticket/2230
This only provided a fix for metadata flags
-service_name
-service_provider
to be passed on to the chained mpegts muxer
What I want:
{{{
-mpegts_pmt_start_pid 480 (see command below) to be respected and produce
PMT PID: 0x01E0 (480) in each segment eg. 1.ts - 8.ts
}}}
What I get:
{{{
mpegts uses the default PID for PMT of 0x1000
PMT PID: 0x1000 (4096)
}}}
How to reproduce:
{{{
% ffmpeg -report -i BigBuckBunny_320x180.mp4 -t 24 -c:v libx264 -crf 22
-minrate:v 60 -maxrate:v 60 -bufsize:v 120 -preset fast
-profile:v main -pix_fmt yuv420p -g 30 -keyint_min 30 -level 4.0 -s
640x360 -c:a aac -minrate:a 96000 -maxrate:a 96000 -bufsize:a 192000
-strict -2 -start_number 1 -hls_time 6 -segment_time 6 -hls_list_size 0
-force_key_frames "expr:if(isnan(prev_forced_n),1,eq(n,prev_forced_n+30))"
-sn -output_ts_offset 0.6667 -hls_segment_filename
BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
-sc_threshold 0 -mpegts_pmt_start_pid 480 -streamid 0:481 -streamid 1:482
-metadata service_provider="Some provider" -metadata service_name="Some
Channel" -f hls BigBuckBunny_320x180_6S600K360.m3u8
}}}
See Report logs attached.
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11198#comment:1>
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".
Re: [FFmpeg-trac] #11198(avformat:new): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment)
segments
-+-
Reporter: adamvaul |Owner: (none)
Type: defect | Status: new
Priority: important|Component: avformat
Version: | Resolution:
Keywords: hls | Blocked By:
metadata segment |
Blocking: | Reproduced by developer: 1
Analyzed by developer: 1|
-+-
Description changed by adamvaul:
Old description:
> Summary of the bug:
>
> See a partial fix (12 years ago) here:
> https://trac.ffmpeg.org/ticket/2230
>
> This only provided a fix for metadata flags
> -service_name
> -service_provider
> to be passed on to the chained mpegts muxer
>
> but it did not pass on the flags for
> -mpegts_pmt_start_pid or
> -mpegts_start_pid
>
> What I want:
>
> {{{
> -mpegts_pmt_start_pid and/or -mpegts_start_pid flags to be passed on to
> the mpegts muxer
>
> Then, if you use TSDuck tsanalyze tool (or another mpegts analyzyer) on
> .ts segment files you should see
> tsanalyze output of final file:
> |===|
> | PID: 0x01E0 (480)
> PMT|
>
> }}}
>
> What I get:
>
> {{{
> |===|
> | PID: 0x1000 (4096)
> PMT|
> }}}
>
>
>
> How to reproduce:
> {{{
> % ffmpeg -report -i BigBuckBunny_320x180.mp4 -t 24 -c:v libx264 -crf 22
> -minrate:v 60 -maxrate:v 60 -bufsize:v 120 -preset fast
> -profile:v main -pix_fmt yuv420p -g 30 -keyint_min 30 -level 4.0 -s
> 640x360 -c:a aac -minrate:a 96000 -maxrate:a 96000 -bufsize:a 192000
> -strict -2 -start_number 1 -hls_time 6 -segment_time 6 -hls_list_size 0
> -force_key_frames
> "expr:if(isnan(prev_forced_n),1,eq(n,prev_forced_n+30))" -sn
> -output_ts_offset 0.6667 -hls_segment_filename
> BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
> -sc_threshold 0 -mpegts_pmt_start_pid 480 -streamid 0:481 -streamid 1:482
> -metadata service_provider="Some provider" -metadata service_name="Some
> Channel" -f hls BigBuckBunny_320x180_6S600K360.m3u8
> }}}
>
> See Report logs attached.
New description:
Summary of the bug:
See a partial fix (12 years ago) here: https://trac.ffmpeg.org/ticket/2230
This only provided a fix for metadata flags
-service_name
-service_provider
to be passed on to the chained mpegts muxer
but it did not pass on the flags for
-mpegts_pmt_start_pid or
-mpegts_start_pid
You can obtain a copy of big buck bunny here:
https://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_320x180.mp4
What I want:
{{{
-mpegts_pmt_start_pid and/or -mpegts_start_pid flags to be passed on to
the mpegts muxer
Then, if you use TSDuck tsanalyze tool (or another mpegts analyzyer) on
.ts segment files you should see
tsanalyze output of final file:
|===|
| PID: 0x01E0 (480)
PMT|
}}}
What I get:
{{{
|===|
| PID: 0x1000 (4096)
PMT|
}}}
How to reproduce:
{{{
% ffmpeg -report -i BigBuckBunny_320x180.mp4 -t 24 -c:v libx264 -crf 22
-minrate:v 60 -maxrate:v 60 -bufsize:v 120 -preset fast
-profile:v main -pix_fmt yuv420p -g 30 -keyint_min 30 -level 4.0 -s
640x360 -c:a aac -minrate:a 96000 -maxrate:a 96000 -bufsize:a 192000
-strict -2 -start_number 1 -hls_time 6 -segment_time 6 -hls_list_size 0
-force_key_frames "expr:if(isnan(prev_forced_n),1,eq(n,prev_forced_n+30))"
-sn -output_ts_offset 0.6667 -hls_segment_filename
BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
-sc_threshold 0 -mpegts_pmt_start_pid 480 -streamid 0:481 -streamid 1:482
-metadata service_provider="Some provider" -metadata service_name="Some
Channel" -f hls BigBuckBunny_320x180_6S600K360.m3u8
}}}
See Report logs attached.
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11198#comment:4>
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".
Re: [FFmpeg-trac] #11198(avformat:new): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment)
segments
-+-
Reporter: adamvaul |Owner: (none)
Type: defect | Status: new
Priority: important|Component: avformat
Version: | Resolution:
Keywords: hls | Blocked By:
metadata segment |
Blocking: | Reproduced by developer: 1
Analyzed by developer: 1|
-+-
Description changed by adamvaul:
Old description:
> Summary of the bug:
>
> See a partial fix (12 years ago) here:
> https://trac.ffmpeg.org/ticket/2230
>
> This only provided a fix for metadata flags
> -service_name
> -service_provider
> to be passed on to the chained mpegts muxer
>
> What I want:
>
> {{{
> If you use TSDuck tsanalyze tool (or another mpegts analyzyer) on the
> created .ts segment files you should see
> tsanalyze output of final file:
> |===|
> | PID: 0x01E0 (480)
> PMT|
>
> -mpegts_pmt_start_pid 480 (see command below) to be respected and produce
> PMT PID: 0x01E0 (480) in each segment eg. 1.ts - 8.ts
>
> }}}
>
> What I get:
>
> {{{
> mpegts uses the default PID for PMT of 0x1000
> PMT PID: 0x1000 (4096)
> }}}
>
>
>
> How to reproduce:
> {{{
> % ffmpeg -report -i BigBuckBunny_320x180.mp4 -t 24 -c:v libx264 -crf 22
> -minrate:v 60 -maxrate:v 60 -bufsize:v 120 -preset fast
> -profile:v main -pix_fmt yuv420p -g 30 -keyint_min 30 -level 4.0 -s
> 640x360 -c:a aac -minrate:a 96000 -maxrate:a 96000 -bufsize:a 192000
> -strict -2 -start_number 1 -hls_time 6 -segment_time 6 -hls_list_size 0
> -force_key_frames
> "expr:if(isnan(prev_forced_n),1,eq(n,prev_forced_n+30))" -sn
> -output_ts_offset 0.6667 -hls_segment_filename
> BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
> -sc_threshold 0 -mpegts_pmt_start_pid 480 -streamid 0:481 -streamid 1:482
> -metadata service_provider="Some provider" -metadata service_name="Some
> Channel" -f hls BigBuckBunny_320x180_6S600K360.m3u8
> }}}
>
> See Report logs attached.
New description:
Summary of the bug:
See a partial fix (12 years ago) here: https://trac.ffmpeg.org/ticket/2230
This only provided a fix for metadata flags
-service_name
-service_provider
to be passed on to the chained mpegts muxer
but it did not pass on the flags for
-mpegts_pmt_start_pid or
-mpegts_start_pid
What I want:
{{{
-mpegts_pmt_start_pid and/or -mpegts_start_pid flags to be passed on to
the mpegts muxer
Then, if you use TSDuck tsanalyze tool (or another mpegts analyzyer) on
.ts segment files you should see
tsanalyze output of final file:
|===|
| PID: 0x01E0 (480)
PMT|
}}}
What I get:
{{{
|===|
| PID: 0x1000 (4096)
PMT|
}}}
How to reproduce:
{{{
% ffmpeg -report -i BigBuckBunny_320x180.mp4 -t 24 -c:v libx264 -crf 22
-minrate:v 60 -maxrate:v 60 -bufsize:v 120 -preset fast
-profile:v main -pix_fmt yuv420p -g 30 -keyint_min 30 -level 4.0 -s
640x360 -c:a aac -minrate:a 96000 -maxrate:a 96000 -bufsize:a 192000
-strict -2 -start_number 1 -hls_time 6 -segment_time 6 -hls_list_size 0
-force_key_frames "expr:if(isnan(prev_forced_n),1,eq(n,prev_forced_n+30))"
-sn -output_ts_offset 0.6667 -hls_segment_filename
BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
-sc_threshold 0 -mpegts_pmt_start_pid 480 -streamid 0:481 -streamid 1:482
-metadata service_provider="Some provider" -metadata service_name="Some
Channel" -f hls BigBuckBunny_320x180_6S600K360.m3u8
}}}
See Report logs attached.
--
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11198#comment:3>
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".
Re: [FFmpeg-trac] #11198(avformat:new): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments -+- Reporter: adamvaul |Owner: (none) Type: defect | Status: new Priority: important|Component: avformat Version: | Resolution: Keywords: hls | Blocked By: metadata segment | Blocking: | Reproduced by developer: 1 Analyzed by developer: 1| -+- Changes (by adamvaul): * Attachment "ffmpeg-20240919-165410.log" added. Report logs -- Ticket URL: <https://trac.ffmpeg.org/ticket/11198> 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] #11198(avformat:new): Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment) segments
#11198: Specified MPEG-TS mpegts_pmt_start_pid is not written to HLS(-ssegment)
segments
-+-
Reporter: adamvaul | Type: defect
Status: new | Priority: important
Component: avformat | Version:
Keywords: hls | Blocked By:
metadata segment |
Blocking: | Reproduced by developer: 1
Analyzed by developer: 1|
-+-
Summary of the bug:
See a partial fix (12 years ago) here: https://trac.ffmpeg.org/ticket/2230
This only provided a fix for metadata flags
-service_name
-service_provider
to be passed on to the chained mpegts muxer
What I want:
{{{
PMT PID: 0x01E0 (480)
}}}
What I get:
{{{
PMT PID: 0x1000 (4096)
}}}
How to reproduce:
{{{
% ffmpeg -report -i BigBuckBunny_320x180.mp4 -t 24 -c:v libx264 -crf 22
-minrate:v 60 -maxrate:v 60 -bufsize:v 120 -preset fast
-profile:v main -pix_fmt yuv420p -g 30 -keyint_min 30 -level 4.0 -s
640x360 -c:a aac -minrate:a 96000 -maxrate:a 96000 -bufsize:a 192000
-strict -2 -start_number 1 -hls_time 6 -segment_time 6 -hls_list_size 0
-force_key_frames "expr:if(isnan(prev_forced_n),1,eq(n,prev_forced_n+30))"
-sn -output_ts_offset 0.6667 -hls_segment_filename
BigBuckBunny_320x180_6S600K360_%05d.ts -hls_playlist_type vod
-sc_threshold 0 -mpegts_pmt_start_pid 480 -streamid 0:481 -streamid 1:482
-metadata service_provider="Some provider" -metadata service_name="Some
Channel" -f hls BigBuckBunny_320x180_6S600K360.m3u8
}}}
See Report logs attached.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11198>
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".
Re: [FFmpeg-trac] #11191(avfilter:new): fate-filter-fps-cfr test fails when ffmpeg configured with --disable-x86asm
#11191: fate-filter-fps-cfr test fails when ffmpeg configured with --disable-x86asm -+- Reporter: vanessa |Owner: (none) pyne | Type: defect | Status: new Priority: minor|Component: avfilter Version: git-master | Resolution: Keywords: test fate| Blocked By: disable-x86asm | Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Changes (by Sean McGovern): * cc: seanmcg (added) * component: undetermined => avfilter -- Ticket URL: <https://trac.ffmpeg.org/ticket/11191#comment:1> 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".
Re: [FFmpeg-trac] #11197(ffmpeg:new): Video duration mismatch between macOS and Ubuntu when transcoding with libx264
#11197: Video duration mismatch between macOS and Ubuntu when transcoding with libx264 -+-- Reporter: Mahendran|Owner: (none) Type: defect | Status: new Priority: important|Component: ffmpeg Version: unspecified | Resolution: Keywords: ffmpeg | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+-- Comment (by Cigaes): Hi. Do not use ffmpeg 4.2 nowadays. Test with the same version of FFmpeg and you will probably get the same results. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11197#comment:1> 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".
Re: [FFmpeg-trac] #11197(ffmpeg:new): Video duration mismatch between macOS and Ubuntu when transcoding with libx264
#11197: Video duration mismatch between macOS and Ubuntu when transcoding with libx264 -+-- Reporter: Mahendran|Owner: (none) Type: defect | Status: new Priority: important|Component: ffmpeg Version: unspecified | Resolution: Keywords: ffmpeg | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+-- Changes (by Mahendran): * Attachment "mac-ffmpeg-20240918-190756.log" added. ffmpeg debug log on macOS -- Ticket URL: <https://trac.ffmpeg.org/ticket/11197> 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".
Re: [FFmpeg-trac] #11197(ffmpeg:new): Video duration mismatch between macOS and Ubuntu when transcoding with libx264
#11197: Video duration mismatch between macOS and Ubuntu when transcoding with libx264 -+-- Reporter: Mahendran|Owner: (none) Type: defect | Status: new Priority: important|Component: ffmpeg Version: unspecified | Resolution: Keywords: ffmpeg | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+-- Changes (by Mahendran): * Attachment "ubuntu-ffmpeg-20240918-190947.log" added. ffmpeg debug log on ubuntu -- Ticket URL: <https://trac.ffmpeg.org/ticket/11197> 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] #11197(ffmpeg:new): Video duration mismatch between macOS and Ubuntu when transcoding with libx264
#11197: Video duration mismatch between macOS and Ubuntu when transcoding with libx264 ---+--- Reporter: Mahendran | Type: defect Status: new| Priority: important Component: ffmpeg | Version: unspecified Keywords: ffmpeg | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ---+--- 1. What you were trying to accomplish: I am trying to transcode a video from mp4 format to mp4 with H.264 encoding (libx264) using the same FFmpeg command on both macOS and Ubuntu. I aim to keep the input video's original duration and apply some video filters such as frame rate control (fps=30) and resizing (scale=480:640). Command: Copy code ffmpeg -i samplevideo.mp4 -vf "fps=30,scale=480:640" -c:v libx264 -profile:v baseline -pix_fmt yuvj420p -r 30 -b:v 4294k -an samplevideo_converted.mp4 2. The problem you encountered: On macOS: The converted video has the same duration (6 seconds) as the input video, which is the expected behavior. On Ubuntu: The converted video has a duration of only 1 second, even though the input video is 6 seconds. I am expecting both platforms to produce videos with consistent durations. 3. The exact command lines you were using: macOS Command: ffmpeg -report -v 9 -loglevel 99 -i samplevideo.mp4 -vf "fps=30,scale=480:640" -c:v libx264 -profile:v baseline -pix_fmt yuvj420p -r 30 -b:v 4294k -an mac-samplevideo_converted.mp4 Ubuntu Command: ffmpeg -v 9 -loglevel 99 -i /tmp/samplevideo.mp4 -vf "fps=30,scale=480:640" -c:v libx264 -profile:v baseline -pix_fmt yuvj420p -r 30 -b:v 4294k -an /tmp/ubuntu-samplevideo_converted.mp4 4. Full console output: The full, uncut console output from both platforms (macOS and Ubuntu) is attached as: ubuntu-ffmpeg-20240918-190119.log mac-ffmpeg-20240918-185939.log 5. Input file: Input file: samplevideo.mp4 (duration: 6 seconds) 6. Additional Notes: Is the use of yuvj420p causing issues on one platform but not the other? Should I switch to yuv420p? Could the redundancy between -r 30 and fps=30 in the -vf filter be contributing to the discrepancy in video durations? Is there any other platform-specific behavior I should be aware of that might cause this inconsistency? 7. Files attached: Ubuntu and macOS log files Input video: samplevideo.mp4 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11197> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by Balling): The frames are dropped because of this bug... This is not Hollwood when 24.000 fps gets converted ti 24/1.001 with an optical flow. Chrome abd others just drop frames. But dedicated apps do not, like Youtube. If you ever tried Youtube app on a TV 0 frames are dropped. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:24> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by MasterQuestionable): ͏ Actual a repetition of... ͏ https://trac.ffmpeg.org/ticket/11055#comment:58 ͏ "Concerning actual playback experience": ͏ Wouldn't your system ever jitter or drop frame..? How to ensure that? -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:23> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by Balling): >Negligible or not, no system can be perfectly CFR. In mkv with milliseconds it cannot be, but in mov/mp4 it can be (it literally is if you do ffmpeg.exe -r 3/1001 -i example.h264 -c copy fnmafa3.mp4), microseconds. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:22> 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".
Re: [FFmpeg-trac] #11196(avformat:new): ffmpeg is unable to identify/open mpeg 2/3 files with only one frame
#11196: ffmpeg is unable to identify/open mpeg 2/3 files with only one frame -+- Reporter: Greisberger |Owner: (none) Christophe | Type: defect | Status: new Priority: normal |Component: avformat Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): To be fair same happens with very small EAC3 files. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11196#comment:1> 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".
Re: [FFmpeg-trac] #11181(avcodec:closed): Add support for Vulkan encoding
#11181: Add support for Vulkan encoding -+- Reporter: Lynne|Owner: (none) Type: enhancement | Status: closed Priority: important|Component: avcodec Version: git-master | Resolution: fixed Keywords: vulkan | Blocked By: encoder| Blocking: 7.1 | Reproduced by developer: 1 Analyzed by developer: 1| -+- Changes (by Lynne): * status: new => closed * resolution: => fixed -- Ticket URL: <https://trac.ffmpeg.org/ticket/11181#comment:5> 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".
Re: [FFmpeg-trac] #11181(avcodec:new): Add support for Vulkan encoding
#11181: Add support for Vulkan encoding -+- Reporter: Lynne|Owner: (none) Type: enhancement | Status: new Priority: important|Component: avcodec Version: git-master | Resolution: Keywords: vulkan | Blocked By: encoder| Blocking: 7.1 | Reproduced by developer: 1 Analyzed by developer: 1| -+- Comment (by Lynne): HEVC encoder merged. Documentation is coming up tomorrow, but for now, you can use `ffmpeg -help encoder=h264_vulkan` and consult the VAAPI documentation since settings match. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11181#comment:4> 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".
Re: [FFmpeg-trac] #11196(avformat:new): ffmpeg is unable to identify/open mpeg 2/3 files with only one frame
#11196: ffmpeg is unable to identify/open mpeg 2/3 files with only one frame -+- Reporter: Greisberger |Owner: (none) Christophe | Type: defect | Status: new Priority: normal |Component: avformat Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Changes (by Greisberger Christophe): * Attachment "sample.32" added. MPEG 3 file (2 frames) -- Ticket URL: <https://trac.ffmpeg.org/ticket/11196> 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".
Re: [FFmpeg-trac] #11196(avformat:new): ffmpeg is unable to identify/open mpeg 2/3 files with only one frame
#11196: ffmpeg is unable to identify/open mpeg 2/3 files with only one frame -+- Reporter: Greisberger |Owner: (none) Christophe | Type: defect | Status: new Priority: normal |Component: avformat Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Changes (by Greisberger Christophe): * Attachment "sample.22" added. MPEG 2 file (2 frames) -- Ticket URL: <https://trac.ffmpeg.org/ticket/11196> 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".
Re: [FFmpeg-trac] #11196(avformat:new): ffmpeg is unable to identify/open mpeg 2/3 files with only one frame
#11196: ffmpeg is unable to identify/open mpeg 2/3 files with only one frame -+- Reporter: Greisberger |Owner: (none) Christophe | Type: defect | Status: new Priority: normal |Component: avformat Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Changes (by Greisberger Christophe): * Attachment "sample.31" added. MPEG 3 file (1 frame) -- Ticket URL: <https://trac.ffmpeg.org/ticket/11196> 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".
Re: [FFmpeg-trac] #11196(avformat:new): ffmpeg is unable to identify/open mpeg 2/3 files with only one frame
#11196: ffmpeg is unable to identify/open mpeg 2/3 files with only one frame -+- Reporter: Greisberger |Owner: (none) Christophe | Type: defect | Status: new Priority: normal |Component: avformat Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Changes (by Greisberger Christophe): * Attachment "sample.21" added. MPEG 2 file (1 frame) -- Ticket URL: <https://trac.ffmpeg.org/ticket/11196> 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] #11196(avformat:new): ffmpeg is unable to identify/open mpeg 2/3 files with only one frame
#11196: ffmpeg is unable to identify/open mpeg 2/3 files with only one frame
-+-
Reporter: Greisberger | Type: defect
Christophe |
Status: new | Priority: normal
Component: avformat | Version:
| unspecified
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+-
Summary of the bug:
How to reproduce:
{{{
% ffmpeg -i input.21 output.wav
[mp3 @ 01A7C88A2C00] Format mp3 detected only with low score of 1,
misdetection possible!
[mp3 @ 01A7C88A2C00] Invalid frame size (768): Could not seek to 768.
[in#0 @ 01A7C887E040] Error opening input: Invalid argument
Error opening input file input.21.
Error opening input files: Invalid argument
}}}
I tracked the problem in `libavformat/mp3_dec.c` here:
{{{
mp3_read_header(AVFormatContext *s)
{
...
ffio_ensure_seekback(s->pb, i + 1024 + frame_size + 4);
ret = check(s->pb, off + i + frame_size, &header2);
if (ret >= 0 &&
(header & MP3_MASK) == (header2 & MP3_MASK))
{
break;
} else if (ret == CHECK_SEEK_FAILED) {
av_log(s, AV_LOG_ERROR, "Invalid frame size (%d): Could
not seek to %"PRId64".\n", frame_size, off + i + frame_size);
return AVERROR(EINVAL);
}
}}}
It seeks to the end of the 1st (any unique) frame, then fails to read 4
bytes (of course).
With files with at least 2 frames, it works
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11196>
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".
Re: [FFmpeg-trac] #11194(avformat:new): image2 frame_pts integer overflow
#11194: image2 frame_pts integer overflow -+- Reporter: Filip|Owner: (none) Type: defect | Status: new Priority: normal |Component: avformat Version: git-master | Resolution: Keywords: image2 | Blocked By: frame_pts | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Filip): [https://ffmpeg.org/pipermail/ffmpeg-devel/2024-September/333602.html] New patch, supersedes the last one. The change is implemented as non–ABI- breaking, with the introduction of av_get_frame_filename**3**, but it raises the issue of the old implementations kicking around, which should probably be deprecated (with the changes announced in the API changelog). I decided this is a necessary change to support the frame_pts option properly since the old code had a lossy narrowing type conversion that caused this defect, and making an entirely new codepath would've made the interface of frame_pts (relying on things like a custom parsing routine for the filename template "%d" specifier) incompatible with the rest of img2enc. The new implementation should be totally backwards-compatible but I still can't test it myself since I can't get make to work on WSL lol. Regression tests are passed though: [https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=12886]. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11194#comment:3> 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".
Re: [FFmpeg-trac] #11193(ffmpeg:new): Dolby Vision metadata not written to MPEG-TS unlike MP4
#11193: Dolby Vision metadata not written to MPEG-TS unlike MP4 -+-- Reporter: SubJunk |Owner: (none) Type: defect | Status: new Priority: normal |Component: ffmpeg Version: 7.0 | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+-- Changes (by SubJunk): * version: unspecified => 7.0 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11193#comment:2> 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] #11195(avformat:new): AVC in MXF container calculates incorrect avg_frame_rate
#11195: AVC in MXF container calculates incorrect avg_frame_rate
--+--
Reporter: ariley| Type: defect
Status: new | Priority: normal
Component: avformat | Version: git-master
Keywords:| Blocked By:
Blocking:| Reproduced by developer: 0
Analyzed by developer: 0 |
--+--
The AVC essence is interlaced 29.97hz, but ffprobe says the essence is
14.99fps -- half what is expected:
{{{
$ ./ffprobe mxf_avc_incorrect_fps.mxf
ffprobe version N-117011-gbb91425eb8 Copyright (c) 2007-2024 the FFmpeg
developers
built with gcc 12 (Debian 12.2.0-14)
configuration: --extra-cflags=-g --extra-cxxflags=-g --optflags=-O0
libavutil 59. 36.100 / 59. 36.100
libavcodec 61. 13.100 / 61. 13.100
libavformat61. 5.101 / 61. 5.101
libavdevice61. 2.101 / 61. 2.101
libavfilter10. 2.102 / 10. 2.102
libswscale 8. 2.100 / 8. 2.100
libswresample 5. 2.100 / 5. 2.100
[mxf @ 0x5606f2464640] index entry 102 + TemporalOffset 127 = 229, which
is out of bounds
Input #0, mxf, from 'mxf_avc_incorrect_fps.mxf':
Metadata:
operational_pattern_ul: 060e2b34.04010101.0d010201.01010100
uid : 28d57eae-5674-1f1e-91b8-00d028174ef2
generation_uid : 32d57eae-5674-1f1e-bd28-00d028174ef2
company_name: Omneon Inc.
product_name: Omneon Media Subsystem
modification_date: 2024-09-16T18:08:31.532000Z
product_version : SB Release 10.2.0.0-eng.3892 (trunk)
product_version_num: 10.2.0.0.1
application_platform: Omneon Media Api (mqx)
product_uid : --1000-8000-050e0b010602
material_package_umid:
0x060A2B34010101050101062313000BF28ED87EAE56741F1E837500D028174EF2
timecode: 00:00:00:00
Duration: 00:00:03.34, start: 0.00, bitrate: 13501 kb/s
Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, top first),
1920x1080 [SAR 1:1 DAR 16:9], 14.99 fps, 29.97 tbr, 29.97 tbn
Metadata:
file_package_umid:
0x060A2B34010101050101062313004C3738D97EAE56741F1E9FF700D028174EF2
}}}
I've tested various versions as far back as 4.1, all of them reporting the
same 14.99fps.
It seems like //avformat_find_stream_info()// is miscalculating the value
of //sti->info->codec_info_duration_fields//:
{{{
2806 if (pkt->duration > 0) {
2807 const int fields = sti->codec_desc &&
(sti->codec_desc->props & AV_CODEC_PROP_FIELDS);
2808 if (avctx->codec_type == AVMEDIA_TYPE_SUBTITLE &&
pkt->pts != AV_NOPTS_VALUE && st->start_time != AV_NOPTS_VALUE && pkt->pts
>= st->start_time
2809 && (uint64_t)pkt->pts - st->start_time <
INT64_MAX
2810 ) {
2811 sti->info->codec_info_duration = FFMIN(pkt->pts -
st->start_time, sti->info->codec_info_duration + pkt->duration);
2812 } else
2813 sti->info->codec_info_duration += pkt->duration;
2814 sti->info->codec_info_duration_fields += sti->parser
&& sti->need_parsing && fields
2815 ?
sti->parser->repeat_pict + 1 : 2;
2816 }
}}}
//fields// is always //1//, and //sti->parser->repeat_pict// is always
//0//, leading to //sti->info->codec_info_duration_fields// having the
same value as //sti->info->codec_info_duration//. Then, when we get here
(where //time_base==1001/3//):
{{{
2924 av_reduce(&st->avg_frame_rate.num,
&st->avg_frame_rate.den,
2925 sti->info->codec_info_duration_fields *
(int64_t) st->time_base.den,
2926 sti->info->codec_info_duration * 2 *
(int64_t) st->time_base.num, 6);
}}}
the //avg_frame_rate// ends up being half what it should (//15000/1001//).
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11195>
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".
Re: [FFmpeg-trac] #11194(avformat:new): image2 frame_pts integer overflow
#11194: image2 frame_pts integer overflow -+- Reporter: Filip|Owner: (none) Type: defect | Status: new Priority: normal |Component: avformat Version: git-master | Resolution: Keywords: image2 | Blocked By: frame_pts | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Filip): [https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240916182420.188-3-shoutple...@gmail.com/] Patch is here. One other change that needs to be made is the snprintf format string needs to handle int64_t properly, which I don't know how to do correctly across platforms (the compiler on patchwork is suggesting "%0*ld"). I would also check that the variable length is being passed correctly since I have a vague memory that only single-digit lengths work correctly. Will update if I have any other ideas. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11194#comment:2> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision
-+-
Reporter: Balling |Owner: Elon Musk
Type: enhancement | Status: open
Priority: wish |Component: avformat
Version: git-master | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 1
Analyzed by developer: 0|
-+-
Comment (by MasterQuestionable):
͏ Pardon. My math went awry.
͏ It seems...
͏ 1/${FPS} not 1/${Time}.
͏ I'll fix it later.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:21>
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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by Balling): chieving 30 × 0.999 = 29.97 frame/s. This is very slightly slower than the true NTSC frame rate of "30 / 1.001 = 29.970029 frame/s. The difference is one additional NTSC frame per 1,000,000 timecode frames, a residual timing error of 1.0 ppm or roughly 2.6 frames (86.4 milliseconds) per day which is considered negligible." It was not negligible, BTW, TV channels had to actually correct this. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:20> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by Balling): I am just quoting wikipedia. https://en.wikipedia.org/wiki/SMPTE_timecode#cite_ref-5 This says 1 frame every 9 hours 15 minutes. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:19> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by MasterQuestionable): ͏ Your math is wrong: ͏ Mistook calculated number of frames as time (in s). ͏ Check comment:12. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:18> 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".
Re: [FFmpeg-trac] #11181(avcodec:new): Add support for Vulkan encoding
#11181: Add support for Vulkan encoding -+- Reporter: Lynne|Owner: (none) Type: enhancement | Status: new Priority: important|Component: avcodec Version: git-master | Resolution: Keywords: vulkan | Blocked By: encoder| Blocking: 7.1 | Reproduced by developer: 1 Analyzed by developer: 1| -+- Comment (by Mads Johansen): I assume there's documentation coming as well? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11181#comment:3> 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".
Re: [FFmpeg-trac] #11194(avformat:new): image2 frame_pts integer overflow
#11194: image2 frame_pts integer overflow -+- Reporter: Filip|Owner: (none) Type: defect | Status: new Priority: normal |Component: avformat Version: git-master | Resolution: Keywords: image2 | Blocked By: frame_pts | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Filip): [https://github.com/FFmpeg/FFmpeg/blob/ceb471cfde901d47e705dd32abba1ea8eab269fa/libavformat/utils.c#L283] I think the best solution is to just change the parameter type of "number", currently int, to uint64_t. The function av_get_frame_filename2 is called in many places with an int "number" argument, except for via the frame_pts codepath, where it's a uint64_t "number" argument. It seems safer to me to cast int into uint64_t rather than the other way round, and I don't foresee any side-effects, though I'm inexperienced with C. Shall I try to submit that as a patch? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11194#comment:1> 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] #11194(avformat:new): image2 frame_pts integer overflow
#11194: image2 frame_pts integer overflow
-+-
Reporter: Filip| Type: defect
Status: new | Priority: normal
Component: avformat | Version: git-
Keywords: image2 | master
frame_pts | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+-
**Summary of the bug:**
The image2 muxer has a frame_pts option, which forwards the pts of every
frame into the filename. When using microsecond precision (which is the
default setting of the drawtext video filter pts template for comparison),
the numbers in the filenames of the output images overflow when the
timestamps go beyond 35m47s.
These calculated pts numbers are being coerced into a signed int32
variable, used for sequence numbers when frame_pts is off, before being
converted into text for the filename. Solutions would be to expand this
variable to int64 or to reroute frame_pts to calculate the pts values as
doubles and then printf them with a float format.
**How to reproduce:**
Substitute video.mp4 for any video longer than 35m48s.
{{{
% ffmpeg -ss 35:47 -t 1 -i video.mp4 -copyts -fps_mode passthrough
-enc_time_base 0.01 -frame_pts 1 %08d.png
}}}
Reproduced on build 2024-09-16-git-76ff97cef5-essentials_build-
www.gyan.dev
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11194>
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".
Re: [FFmpeg-trac] #11181(avcodec:new): Add support for Vulkan encoding
#11181: Add support for Vulkan encoding -+- Reporter: Lynne|Owner: (none) Type: enhancement | Status: new Priority: important|Component: avcodec Version: git-master | Resolution: Keywords: vulkan | Blocked By: encoder| Blocking: 7.1 | Reproduced by developer: 1 Analyzed by developer: 1| -+- Comment (by Lynne): H.264 encoder pushed. And once the HEVC encoder patchset gets pushed, I'll close this issue. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11181#comment:2> 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".
Re: [FFmpeg-trac] #11193(ffmpeg:new): Dolby Vision metadata not written to MPEG-TS unlike MP4
#11193: Dolby Vision metadata not written to MPEG-TS unlike MP4
-+--
Reporter: SubJunk |Owner: (none)
Type: defect | Status: new
Priority: normal |Component: ffmpeg
Version: unspecified | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+--
Description changed by SubJunk:
Old description:
> Summary of the bug:
> If I have an input file with a Dolby Vision video stream, it is easy to
> have the Dolby Vision metadata added to the output file if it is MP4, by
> adding `-strict unofficial` to it, e.g. with the input file dv.mkv with a
> MediaInfo reading that includes:
> {{{
> HDR format : Dolby Vision, Version 1.0,
> Profile 8.1, dvhe.08.06, BL+RPU, no metadata compression, HDR10
> compatible / SMPTE ST 2086, Version HDR10, HDR10 compatible / SMPTE ST
> 2094 App 4, Version HDR10+ Profile B, HDR10+ Profile B compatible
> Mastering display luminance : min: 0.0050 cd/m2, max: 1000
> cd/m2
> Maximum Content Light Level : 806
> MaxCLL_Original : 806 cd/m2
> Maximum Frame-Average Light Level: 78
> MaxFALL_Original : 78 cd/m2
> }}}
>
> FFmpeg outputs a MP4 file with DV metadata:
>
> {{{
> ./ffmpeg -i dv.mkv -c:v copy -f mp4 -strict unofficial output.mp4
> ...
> HDR format : SMPTE ST 2086, Version 1.0,
> dvhe.08.06, BL+RPU, no metadata compression, HDR10 compatible / Dolby
> Vision, Version 1, HDR10 compatible / SMPTE ST 2094 App 4, HDR10+ Profile
> B compatible
> Mastering display luminance : min: 0.0050 cd/m2, max: 1000
> cd/m2
> Maximum Content Light Level : 806 cd/m2
> Maximum Frame-Average Light Level : 78 cd/m2
> }}}
>
> which is good, but the same does not work for MPEG-TS:
>
> {{{
> ./ffmpeg -i dv.mkv -c:v lib265 -f mpegts -strict unofficial output.ts.
> ...
> HDR format : SMPTE ST 2094 App 4, Version
> 1, HDR10+ Profile B compatible
> Mastering display luminance : min: 0.0050 cd/m2, max: 1000
> cd/m2
> Maximum Content Light Level : 806 cd/m2
> Maximum Frame-Average Light Level: 78 cd/m2
> }}}
>
> where it has output different HDR format metadata that is just for
> compatibility, not the DV part.
>
> An interesting note is that if I run the MPEG-TS output through tsMuxeR,
> it corrects the metadata to be:
>
> {{{
> HDR format : Dolby Vision, Version 1.0,
> Profile 8.1, dvhe.08.06, BL+RPU, extended metadata compression, HDR10
> compatible / SMPTE ST 2094 App 4, Version HDR10+ Profile B, HDR10+
> Profile B compatible
> }}}
>
> which allows players to recognize it as Dolby Vision again. I include
> that note just in case it is helpful.
>
> I can provide a sample input if anyone wants too
New description:
Summary of the bug:
If I have an input file with a Dolby Vision video stream, it is easy to
have the Dolby Vision metadata added to the output file if it is MP4, by
adding `-strict unofficial` to it, e.g. with the input file dv.mkv with a
MediaInfo reading that includes:
{{{
HDR format : Dolby Vision, Version 1.0,
Profile 8.1, dvhe.08.06, BL+RPU, no metadata compression, HDR10 compatible
/ SMPTE ST 2086, Version HDR10, HDR10 compatible / SMPTE ST 2094 App 4,
Version HDR10+ Profile B, HDR10+ Profile B compatible
Mastering display luminance : min: 0.0050 cd/m2, max: 1000
cd/m2
Maximum Content Light Level : 806
MaxCLL_Original : 806 cd/m2
Maximum Frame-Average Light Level: 78
MaxFALL_Original : 78 cd/m2
}}}
FFmpeg outputs a MP4 file with DV metadata:
{{{
./ffmpeg -i dv.mkv -c:v copy -f mp4 -strict unofficial output.mp4
...
HDR format : SMPTE ST 2086, Version 1.0,
dvhe.08.06, BL+RPU, no metadata compression, HDR10 compatible / Dolby
Vision, Version 1, HDR10 compatible / SMPTE ST 2094 App 4, HDR10+ Profile
B compatible
Mastering display luminance : min: 0.0050 cd/m2, max: 1000
cd/m2
Maximum Content Light Level : 806 cd/m2
Maximum Frame-Average Light Level: 78 cd/m2
}}}
which is good, but the same does not work for MPEG-TS:
{{{
./ffmpeg -i dv.mkv -c:v copy -f mpegts -strict unofficial output.ts.
...
HDR format
[FFmpeg-trac] #11193(ffmpeg:new): Dolby Vision metadata not written to MPEG-TS unlike MP4
#11193: Dolby Vision metadata not written to MPEG-TS unlike MP4
-+---
Reporter: SubJunk | Type: defect
Status: new | Priority: normal
Component: ffmpeg | Version: unspecified
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+---
Summary of the bug:
If I have an input file with a Dolby Vision video stream, it is easy to
have the Dolby Vision metadata added to the output file if it is MP4, by
adding `-strict unofficial` to it, e.g. with the input file dv.mkv with a
MediaInfo reading that includes:
{{{
HDR format : Dolby Vision, Version 1.0,
Profile 8.1, dvhe.08.06, BL+RPU, no metadata compression, HDR10 compatible
/ SMPTE ST 2086, Version HDR10, HDR10 compatible / SMPTE ST 2094 App 4,
Version HDR10+ Profile B, HDR10+ Profile B compatible
Mastering display luminance : min: 0.0050 cd/m2, max: 1000
cd/m2
Maximum Content Light Level : 806
MaxCLL_Original : 806 cd/m2
Maximum Frame-Average Light Level: 78
MaxFALL_Original : 78 cd/m2
}}}
FFmpeg outputs a MP4 file with DV metadata:
{{{
./ffmpeg -i dv.mkv -c:v copy -f mp4 -strict unofficial output.mp4
...
HDR format : SMPTE ST 2086, Version 1.0,
dvhe.08.06, BL+RPU, no metadata compression, HDR10 compatible / Dolby
Vision, Version 1, HDR10 compatible / SMPTE ST 2094 App 4, HDR10+ Profile
B compatible
Mastering display luminance : min: 0.0050 cd/m2, max: 1000
cd/m2
Maximum Content Light Level : 806 cd/m2
Maximum Frame-Average Light Level: 78 cd/m2
}}}
which is good, but the same does not work for MPEG-TS:
{{{
./ffmpeg -i dv.mkv -c:v lib265 -f mpegts -strict unofficial output.ts.
...
HDR format : SMPTE ST 2094 App 4, Version 1,
HDR10+ Profile B compatible
Mastering display luminance : min: 0.0050 cd/m2, max: 1000
cd/m2
Maximum Content Light Level : 806 cd/m2
Maximum Frame-Average Light Level: 78 cd/m2
}}}
where it has output different HDR format metadata that is just for
compatibility, not the DV part.
An interesting note is that if I run the MPEG-TS output through tsMuxeR,
it corrects the metadata to be:
{{{
HDR format : Dolby Vision, Version 1.0,
Profile 8.1, dvhe.08.06, BL+RPU, extended metadata compression, HDR10
compatible / SMPTE ST 2094 App 4, Version HDR10+ Profile B, HDR10+ Profile
B compatible
}}}
which allows players to recognize it as Dolby Vision again. I include that
note just in case it is helpful.
I can provide a sample input if anyone wants too
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11193>
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".
Re: [FFmpeg-trac] #11188(tools:new): ffmpeg_opt.c correct_input_start_times(void) calculates wrong ts_offset
#11188: ffmpeg_opt.c correct_input_start_times(void) calculates wrong ts_offset -+-- Reporter: Jens Viebig |Owner: (none) Type: defect | Status: new Priority: normal |Component: tools Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+-- Comment (by Jens Viebig): Understood, we will change the patch and resubmit -- Ticket URL: <https://trac.ffmpeg.org/ticket/11188#comment:7> 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".
Re: [FFmpeg-trac] #11192(avformat:new): Raw H264 stream has incorrect frame rate
#11192: Raw H264 stream has incorrect frame rate + Reporter: ariley |Owner: (none) Type: defect | Status: new Priority: important |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | + Comment (by ariley): Thanks. IMO, I think it's better to leave these as two distinct issues. #9814 is filed as a "wish" request for better precision in reporting the frame rate. The brokenness of ffmpeg suddenly returning 25fps for 29.97fps essence is orthogonal (but confounding) to the original request. This latter certainly needs fixing, and is (I suspect) likely to be overlooked if the only report of it is in the midst of comments on a wish list issue. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11192#comment:4> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by Balling): >Where to store the infinite result Erm, the 29.970 is what was used when Timecode was used as main timestamp information. It was accumuating 1 frame every 9 hours 15 minutes because it was saying 29.970 instead of actual 30/1.001. Timecodes were corrected every time. This is a rather basic scenario, and literally what this issue is -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:17> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by MasterQuestionable): ͏ Where to store the infinite result? ͏ Discard outright..? -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:16> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by Balling): "Infinite precision demands infinite resource" No, it does not. E.g. you can calculate each digit of pi without relying on previous digits in constand time. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:15> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by MasterQuestionable): ͏ Learn entropy theory. ͏ Infinite precision demands infinite resource: ͏ Something impossible to practical systems. ͏ The point is, container may also deliver presentation info: ͏ And which is generally more favored. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:14> 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".
Re: [FFmpeg-trac] #11190(avcodec:new): H.264 video stops playing without errors
#11190: H.264 video stops playing without errors -+--- Reporter: kevmo314 |Owner: (none) Type: defect | Status: new Priority: normal |Component: avcodec Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+--- Comment (by kevmo314): Replying to [comment:5 Balling]: > Your patch was not applied https://patchwork.ffmpeg.org/project/ffmpeg/patch/cagb5vbex1eyhtfssyy-f-qo5ahhtehmnacedieqofqmcowh...@mail.gmail.com/ > > you need to use send-email in git I did use `git send-email` to send that patch. Could you share what is missing in that email/why `git send-email` sent an incorrectly-formatted email? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11190#comment:7> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Comment (by Balling): > No system can be of infinite precision. LOL https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:13> 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".
Re: [FFmpeg-trac] #9814(avformat:open): time_scale / num_units_in_tick is not infinite precision
#9814: time_scale / num_units_in_tick is not infinite precision -+- Reporter: Balling |Owner: Elon Musk Type: enhancement | Status: open Priority: wish |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Changes (by MasterQuestionable): * cc: MasterQuestionable (added) Comment: ͏ I fear this is actually none issue: ͏ No system can be of infinite precision. ͏ And the actual playback experience mostly wouldn't differ. ͏ Much comparable to those use ns accuracy for regular timestamps... ͏ See also: https://github.com/MasterInQuestion/talk/discussions/3#issuecomment-1546820018-3 ͏ As for the recent further break: much the result of "Codec container wrestling each other..." -- Ticket URL: <https://trac.ffmpeg.org/ticket/9814#comment:12> 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".
Re: [FFmpeg-trac] #11190(avcodec:new): H.264 video stops playing without errors
#11190: H.264 video stops playing without errors -+--- Reporter: kevmo314 |Owner: (none) Type: defect | Status: new Priority: normal |Component: avcodec Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+--- Changes (by MasterQuestionable): * cc: MasterQuestionable (added) Comment: ͏ Up: https://trac.ffmpeg.org/ticket/11134#comment:7 ͏ Would you kindly instruct how to properly make commits on this project? ͏ Seriously, via email..? ͏ Thanks in advance. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11190#comment:6> 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".
Re: [FFmpeg-trac] #11190(avcodec:new): H.264 video stops playing without errors
#11190: H.264 video stops playing without errors -+--- Reporter: kevmo314 |Owner: (none) Type: defect | Status: new Priority: normal |Component: avcodec Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+--- Comment (by Balling): Your patch was not applied https://patchwork.ffmpeg.org/project/ffmpeg/patch/cagb5vbex1eyhtfssyy-f-qo5ahhtehmnacedieqofqmcowh...@mail.gmail.com/ you need to use send-email in git -- Ticket URL: <https://trac.ffmpeg.org/ticket/11190#comment:5> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): I already see one mistake in mozilla calculator, they use Precision that is 5. It needs to be only 4 for ycbcr to rgb, but Precision of rgb to ycbcr matrix must be increased if you are working with 14 bits or 12 bits per channel. See: "The decoding matrix for BT.2020-NCL is this with 14 decimal places" here https://en.wikipedia.org/wiki/YCbCr Let us check some stuff with that calculator. First of all there is a rule that when you convert 8 bit YCbCr to 10 bit YCbCr you just multiply by 4, even if this is suboptimal that was how ITU defined it. That means that 235 is just multiplied by 4 and you get 940 and that is the same value. Indeed, both 8 bit value of 235, 128, 128 and 940, 512, 512 decode to perfect values 255, 255, 255 and 1023, 1023, 1023, both of them are reference white. Very cute. Same for 64, 512, 512 is perfect 0, 0, 0. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:49> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): >what about this calculator I found in mozilla bugtracker ? It produces the same values... What about it? 126, 128, 16 both calculators produce -50.67, 219.13, 128.08 if you use 601 matrix. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:48> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Andrew-R): Replying to [comment:46 Balling]: > yuv444-rgba-problem1.png shows the difference only in the second raw and third raw because those values are out-of-gamut. Indeed, green is 0x80, 0x80, 0x0. That means it is full range, as 0x0 value is prohibited in limited range YCbCr. Now, let us use calculator https://res18h39.netlify.app/color what about this calculator I found in mozilla bugtracker ? https://kdashg.github.io/misc/colors/from-coeffs.html does this mean that full-range yuv 8-bit signal will fit into 9-bit RGB (not counting undisplayable colors yet?) -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:47> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): yuv444-rgba-problem1.png shows the difference only in the second raw and third raw because those values are out-of-gamut. Indeed, green is 0x80, 0x80, 0x0. That means it is full range, as 0x0 value is prohibited in limited range YCbCr. Now, let us use calculator https://res18h39.netlify.app/color This calculator does not support full range YCbCr, so we should convert it to limited range. 128 in full range Y becomes float value 0.5019607843137254 that becomes *219+16 = 125.9294117647059, 126 Y limited range, Cb 128 becomes 0 float and that becomes 128 Cb; Cr at 0 becomes -0.5 float and that becomes 16 in limited range, so it is 126, 128, 16. In R'G'B' that is -76, 232, 128. There is no bug, RGB cannot preserve such a value in R, red is negative. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:46> 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".
Re: [FFmpeg-trac] #11179(undetermined:closed): JPEG conversion failure with zscale
#11179: JPEG conversion failure with zscale -+- Reporter: Niklas Haas |Owner: (none) Type: defect | Status: closed Priority: normal |Component: | undetermined Version: unspecified | Resolution: fixed Keywords: | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0| -+- Changes (by Niklas Haas): * status: new => closed * resolution: => fixed -- Ticket URL: <https://trac.ffmpeg.org/ticket/11179#comment:11> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Andrew-R): Replying to [comment:44 Balling]: > "note that input file clearly says range PC in both cases" > > What? You forced it to be PC, also known as full range. without any of those parameters yuvtestsrc gives full-range output, as far as I can see? Can you double-check on your end with YUView? > > Just use zscale, I am begging you. I'm not programmer enough for making api changes in our program, so I am a bit stuck with libswscale ..? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:45> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): "note that input file clearly says range PC in both cases" What? You forced it to be PC, also known as full range. If you want limited -vf scale=in_range=tv:out_range=pc, if you want limited output -vf scale=in_range=tv:out_range=tv If you want limited output but input is full range -vf scale=in_range=pc:out_range=tv Same for the other 4 parameters (chroma siting (also known as chroma position or latice), primaries (also known as gamut), color matrix (also known as colorspace), transfer (also known as gamma, EOTF)), each produces different pixels, and each can use a different dither, dufferent upscale algorithm, different scaling algorithm, transfer aware resizing and also accurate_rnd stuff! Just use zscale, I am begging you. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:44> 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".
Re: [FFmpeg-trac] #10430(swscale:new): Wrong yuv420p to rgb24 result on macOS m1 arm64
#10430: Wrong yuv420p to rgb24 result on macOS m1 arm64 ---+--- Reporter: lja|Owner: (none) Type: defect | Status: new Priority: normal |Component: swscale Version: 6.0| Resolution: Keywords: yuv2rgb scale | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ---+--- Changes (by Balling): * keywords: yuv2rgb => yuv2rgb scale Comment: Does it still reproduce in newer versions? -- Ticket URL: <https://trac.ffmpeg.org/ticket/10430#comment:4> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge
difference
-+-
Reporter: Andrew-R |Owner: (none)
Type: defect | Status: closed
Priority: normal |Component: swscale
Version: unspecified | Resolution: invalid
Keywords: colorspace | Blocked By:
color_primaries|
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+-
Comment (by Andrew-R):
Replying to [comment:41 Balling]:
> Well, again. Color_range 2 does not work as input option and that is not
how you handle ranges, you use -vf scale=in_range=pc:out_range=pc
>
I tried as you suggested, and difference still around, note that input
file clearly says range PC in both cases (generating and converting)
{{{
bash-5.1$ /dev/shm/bin/ffmpeg -f lavfi -color_range 2 -i
yuvtestsrc=s=640x480 -vf scale=in_range=pc:out_range=pc -color_range 2
-frames 2 /dev/shm/yuv-pc-yuv444.y4m
ffmpeg version N-115867-g3f84d1d1fb Copyright (c) 2000-2024 the FFmpeg
developers
built with gcc 11.2.0 (GCC)
configuration: --disable-debug
libavutil 59. 36.100 / 59. 36.100
libavcodec 61. 13.100 / 61. 13.100
libavformat61. 5.101 / 61. 5.101
libavdevice61. 2.101 / 61. 2.101
libavfilter10. 2.102 / 10. 2.102
libswscale 8. 2.100 / 8. 2.100
libswresample 5. 2.100 / 5. 2.100
Input #0, lavfi, from 'yuvtestsrc=s=640x480':
Duration: N/A, start: 0.00, bitrate: N/A
Stream #0:0: Video: wrapped_avframe, yuv444p(**pc**), 640x480 [SAR 1:1
DAR 4:3], 25 fps, 25 tbr, 25 tbn
File '/dev/shm/yuv-pc-yuv444.y4m' already exists. Overwrite? [y/N] y
Stream mapping:
Stream #0:0 -> #0:0 (wrapped_avframe (native) -> wrapped_avframe
(native))
Press [q] to stop, [?] for help
Output #0, yuv4mpegpipe, to '/dev/shm/yuv-pc-yuv444.y4m':
Metadata:
encoder : Lavf61.5.101
Stream #0:0: Video: wrapped_avframe, yuv444p(pc, progressive), 640x480
[SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn
Metadata:
encoder : Lavc61.13.100 wrapped_avframe
[out#0/yuv4mpegpipe @ 0xc54e340] video:1KiB audio:0KiB subtitle:0KiB other
streams:0KiB global headers:0KiB muxing overhead: 299133.603896%
frame=2 fps=0.0 q=-0.0 Lsize=1800KiB time=00:00:00.08
bitrate=184327.9kbits/s speed= 10x
bash-5.1$ /dev/shm/bin/ffmpeg -color_range 2 -i /dev/shm/yuv-pc-yuv444.y4m
-vf format=rgba -color_range 2 -frames 2 -pix_fmt yuv444p /dev/shm/yuv-
pc-rgba-yuv444.y4m
ffmpeg version N-115867-g3f84d1d1fb Copyright (c) 2000-2024 the FFmpeg
developers
built with gcc 11.2.0 (GCC)
configuration: --disable-debug
libavutil 59. 36.100 / 59. 36.100
libavcodec 61. 13.100 / 61. 13.100
libavformat61. 5.101 / 61. 5.101
libavdevice61. 2.101 / 61. 2.101
libavfilter10. 2.102 / 10. 2.102
libswscale 8. 2.100 / 8. 2.100
libswresample 5. 2.100 / 5. 2.100
Input #0, yuv4mpegpipe, from '/dev/shm/yuv-pc-yuv444.y4m':
Duration: 00:00:00.08, start: 0.00, bitrate: 184327 kb/s
Stream #0:0: Video: rawvideo (444P / 0x50343434), yuv444p(**pc**,
progressive), 640x480, SAR 1:1 DAR 4:3, 25 fps, 25 tbr, 25 tbn
File '/dev/shm/yuv-pc-rgba-yuv444.y4m' already exists. Overwrite? [y/N] y
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
Output #0, yuv4mpegpipe, to '/dev/shm/yuv-pc-rgba-yuv444.y4m':
Metadata:
encoder : Lavf61.5.101
Stream #0:0: Video: wrapped_avframe, yuv444p(pc, progressive), 640x480
[SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn
Metadata:
encoder : Lavc61.13.100 wrapped_avframe
[out#0/yuv4mpegpipe @ 0xb6a4700] video:1KiB audio:0KiB subtitle:0KiB other
streams:0KiB global headers:0KiB muxing overhead: 299133.603896%
frame=2 fps=0.0 q=-0.0 Lsize=1800KiB time=00:00:00.08
bitrate=184327.9kbits/s speed=4.12x
--
Ticket URL: <ht
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Andrew-R): Replying to [comment:41 Balling]: > Well, again. Color_range 2 does not work as input option and that is not how you handle ranges, you use -vf scale=in_range=pc:out_range=pc > well, but why color_range has no effect on input (in this case reading from lavfilter test source)? Is it stated in documentation? I think in my case autoscale tries to insert right flags, of course it may fail. At least colorspace seems to propagate from input ... -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:42> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): Well, again. Color_range 2 does not work as input option and that is not how you handle ranges, you use -vf scale=in_range=pc:out_range=pc -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:41> 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".
Re: [FFmpeg-trac] #6440(undetermined:closed): Support and re-export of floating-point RGB-type color spaces (e.g. for YUV -based input)
#6440: Support and re-export of floating-point RGB-type color spaces (e.g. for YUV -based input) -+- Reporter: mtc |Owner: (none) Type: defect | Status: closed Priority: normal |Component: | undetermined Version: unspecified | Resolution: duplicate Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): There are more pages in the standard, Annex A, Annex B, Annex C. I have it, but, I suppose I should not post it... Anyway, yes, same EOTF was used by Photo CD. -- Ticket URL: <https://trac.ffmpeg.org/ticket/6440#comment:4> 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".
Re: [FFmpeg-trac] #11192(avformat:new): Raw H264 stream has incorrect frame rate
#11192: Raw H264 stream has incorrect frame rate + Reporter: ariley |Owner: (none) Type: defect | Status: new Priority: important |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | + Comment (by Balling): #9814 there the bug is that the file is tagged 30/1.001 but the result is 30/1.000 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11192#comment:3> 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".
Re: [FFmpeg-trac] #11192(avformat:new): Raw H264 stream has incorrect frame rate
#11192: Raw H264 stream has incorrect frame rate
+
Reporter: ariley |Owner: (none)
Type: defect | Status: new
Priority: important |Component: avformat
Version: git-master | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
+
Comment (by ariley):
Not quite sure how you can make the assertion that I didn't test master?
{{{
$ git branch
* master
$ ./ffprobe regression_ba4b73c977.h264
ffprobe version N-117011-gbb91425eb8 Copyright (c) 2007-2024 the FFmpeg
developers
built with gcc 12 (Debian 12.2.0-14)
configuration: --extra-cflags=-g --extra-cxxflags=-g --optflags=-O0
libavutil 59. 36.100 / 59. 36.100
libavcodec 61. 13.100 / 61. 13.100
libavformat61. 5.101 / 61. 5.101
libavdevice61. 2.101 / 61. 2.101
libavfilter10. 2.102 / 10. 2.102
libswscale 8. 2.100 / 8. 2.100
libswresample 5. 2.100 / 5. 2.100
[h264 @ 0x555f4b2ef640] Stream #0: not enough frames to estimate rate;
consider increasing probesize
Input #0, h264, from 'regression_ba4b73c977.h264':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: h264 (High 4:2:2), yuv422p10le(tv, bt709, top
first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 59.94 tbr, 1200k tbn
$ git log --pretty=oneline | perl -pe'exit if (/ba4b73c977/)' | wc -l
6749
}}}
The results in my initial report are from doing a git-bisect on the master
branch. It may be 6750 commits back in history, but I'm pretty sure I'm
still on the master branch.
If this is a known bug, then I'm happy to have it closed as a duplicate,
but I wasn't able to find any mention of it in trac -- perhaps I'm not
using the correct search terms.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11192#comment:2>
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".
Re: [FFmpeg-trac] #6440(undetermined:closed): Support and re-export of floating-point RGB-type color spaces (e.g. for YUV -based input)
#6440: Support and re-export of floating-point RGB-type color spaces (e.g. for YUV -based input) -+- Reporter: mtc |Owner: (none) Type: defect | Status: closed Priority: normal |Component: | undetermined Version: unspecified | Resolution: duplicate Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Andrew-R): speaking about xvYCC I found two documents: https://www.researchgate.net/publication /250999893_192_xvYCC_A_New_Standard_for_Video_Systems_using_Extended- Gamut_YCC_Color_Space and preview/sample of iec-61966-2-4 (it works as of today, I saved it just because) https://cdn.standards.iteh.ai/samples/14431/9e5a80b3c1a54ad0866f818def33466c/IEC-61966-2-4-2006.pdf so it seems those opto-electrical and inverse transfer functions are simple, but defined as 3 separate segments? -- Ticket URL: <https://trac.ffmpeg.org/ticket/6440#comment:3> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge
difference
-+-
Reporter: Andrew-R |Owner: (none)
Type: defect | Status: closed
Priority: normal |Component: swscale
Version: unspecified | Resolution: invalid
Keywords: colorspace | Blocked By:
color_primaries|
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+-
Comment (by Andrew-R):
using this command
{{{
ffmpeg -f lavfi -color_range 2 -i yuvtestsrc=s=640x480 -color_range 2
-frames 2 /dev/shm/yuv-pc-yuv444.y4m
}}}
and checking result with YUviewer I see that ffmpeg 4.4.5 and git behave
differently on -vf format=rgba action :}
{{{
ffmpeg -color_range 2 -i /dev/shm/yuv-pc-yuv444.y4m -vf format=rgba
-color_range 2 -frames 2 -pix_fmt yuv444p /dev/shm/yuv-pc-rgba-yuv444.y4m
ffmpeg version 4.4.5 Copyright (c) 2000-2024 the FFmpeg developers
built with gcc 11.2.0 (GCC)
configuration: --prefix=/usr --libdir=/usr/lib --shlibdir=/usr/lib
--docdir=/usr/doc/ffmpeg-4.4.5/html --mandir=/usr/man --disable-debug
--enable-shared --disable-static --enable-gpl --enable-version3 --enable-
avresample --arch=i586 --enable-libfontconfig --enable-libfreetype
--enable-libfribidi --enable-gnutls --enable-libass --enable-libbluray
--enable-libcdio --enable-frei0r --enable-libgsm --enable-openal --enable-
libopus --enable-librtmp --enable-libsnappy --enable-libspeex --enable-
libssh --enable-libtheora --enable-libtwolame --enable-libv4l2 --enable-
libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-
libx264 --enable-libx265 --enable-libxvid --enable-libmp3lame --enable-
opencl --enable-opengl --enable-libopenjpeg --disable-libpulse --enable-
libsmbclient --enable-libsvtav1 --enable-libxml2 --enable-librsvg
--enable-libdrm --enable-libaom --enable-libdav1d --enable-libsoxr
--enable-libzimg --enable-vapoursynth
libavutil 56. 70.100 / 56. 70.100
libavcodec 58.134.100 / 58.134.100
libavformat58. 76.100 / 58. 76.100
libavdevice58. 13.100 / 58. 13.100
libavfilter 7.110.100 / 7.110.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 9.100 / 5. 9.100
libswresample 3. 9.100 / 3. 9.100
libpostproc55. 9.100 / 55. 9.100
Input #0, yuv4mpegpipe, from '/dev/shm/yuv-pc-yuv444.y4m':
Duration: 00:00:00.08, start: 0.00, bitrate: 184327 kb/s
Stream #0:0: Video: rawvideo (444P / 0x50343434), yuv444p(pc,
progressive), 640x480, SAR 1:1 DAR 4:3, 25 fps, 25 tbr, 25 tbn, 25 tbc
File '/dev/shm/yuv-pc-rgba-yuv444.y4m' already exists. Overwrite? [y/N] y
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, yuv4mpegpipe, to '/dev/shm/yuv-pc-rgba-yuv444.y4m':
Metadata:
encoder : Lavf58.76.100
Stream #0:0: Video: wrapped_avframe, yuv444p(pc, progressive), 640x480
[SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn
Metadata:
encoder : Lavc58.134.100 wrapped_avframe
frame=2 fps=0.0 q=-0.0 Lsize=1800kB time=00:00:00.08
bitrate=184327.9kbits/s speed=3.97x
video:1kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 232637.25%
bash-5.1$ /dev/shm/bin/ffmpeg -color_range 2 -i /dev/shm/yuv-pc-yuv444.y4m
-vf format=rgba -color_range 2 -frames 2 -pix_fmt yuv444p /dev/shm/yuv-
pc-rgba-yuv444.y4m
ffmpeg version N-115867-g3f84d1d1fb Copyright (c) 2000-2024 the FFmpeg
developers
built with gcc 11.2.0 (GCC)
configuration: --disable-debug
libavutil 59. 36.100 / 59. 36.100
libavcodec 61. 13.100 / 61. 13.100
libavformat61. 5.101 / 61. 5.101
libavdevice61. 2.101 / 61. 2.101
libavfilter10. 2.102 / 10. 2.102
libswscale 8. 2.100 / 8. 2.100
libswresample 5. 2.100 / 5. 2.100
Input #0, yuv4mpegpipe, from '/dev/shm/yuv-pc-yuv444.y4m':
Duration: 00:00:00.08, start: 0.00, bitrate: 184327 kb/s
Stream #0:0: Video: rawvideo (444P / 0x50343434), yuv444p(pc,
progressive), 640x480, SAR 1:1 DAR 4:3, 25 fps, 25 tbr, 25 tbn
File '/dev/shm/yuv-pc-rgba-yuv444.y4m' already exists. Overwrite? [y/N] y
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full, srcrange 0 dstrange = 1
luma range from limited to full,
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Andrew-R): Replying to [comment:37 Balling]: > You did not read until comment #28 on doom9, it starts talking about xvYCC. but yuvtestsrc does not produce xvYCC by default? > > >Not sure how specific figure in YUView should look for invalid colors after such roundtrip > > Depends what algoritm it uses to clip YCbCr out-of-gamut values. Typically you need to use LittleCMS to see how to clip YCbCr color in xvYCC to closest value representative in RGB. But you can enable zoom box in Yuview and you will see actual values. Yes, I was using exactly zoom box to see values first! I found patent from broadcom :) https://patents.google.com/patent/EP1560417A2/en "System and method for clipping values of pixels in one color space so not to exceed the limits of a second color space" and algo from BBC on this constant hue method realized by SGI machinery. But well, may be I just use wrong test source ??? -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:39> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): >so full-range y4m file from yuvtestsrc contain all Y, U, V values (as requested!), even illegal (for RGB conversion later on) ones? Illegal RGB values (that means negative) are valid colors. That must be shown. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:38> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): You did not read until comment #28 on doom9, it starts talking about xvYCC. >Not sure how specific figure in YUView should look for invalid colors after such roundtrip Depends what algoritm it uses to clip YCbCr out-of-gamut values. Typically you need to use LittleCMS to see how to clip YCbCr color in xvYCC to closest value representative in RGB. But you can enable zoom box in Yuview and you will see actual values. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:37> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge
difference
-+-
Reporter: Andrew-R |Owner: (none)
Type: defect | Status: closed
Priority: normal |Component: swscale
Version: unspecified | Resolution: invalid
Keywords: colorspace | Blocked By:
color_primaries|
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+-
Comment (by Andrew-R):
Replying to [comment:35 Balling]:
> >Honestly, until now I was under impression RGB was superset of YUV, not
other way around ... I was wrong!
>
> You just read one small text in
https://stackoverflow.com/questions/17892346/how-to-convert-rgb-yuv-rgb-
both-ways "Since the 8 bit YUV only uses Y values [16, 235] and U, V
values [16, 240] it has less possible colors than RGB using [0, 255].",
which is simply not true, there is a comment from me under that answer
that says: It is not on any flagship TV. If you send YCbCr it will show
superwhite and supercolors no problem. In some cases even xvYCC. LG C9
does it even in internal files player."
Hm, well, I guess I just confused usual chroma subsampling and associated
loss of information with colorspace itself.
There is post titled "U and V ranges for valid RGB" from 2010, it has
animated illustration.
https://forum.doom9.org/showthread.php?t=154731
ffmpeg -i /dev/shm/yuv-mpeg-yuv444p.y4m -vf
"signalstats,metadata=print:file=logfile.txt" -f null /dev/null
from logfile it says
{{{
frame:0pts:0 pts_time:0
lavfi.signalstats.YMIN=0
lavfi.signalstats.YLOW=76
lavfi.signalstats.YAVG=127.733
lavfi.signalstats.YHIGH=178
lavfi.signalstats.YMAX=255
lavfi.signalstats.UMIN=0
lavfi.signalstats.ULOW=76
lavfi.signalstats.UAVG=127.733
lavfi.signalstats.UHIGH=178
lavfi.signalstats.UMAX=255
lavfi.signalstats.VMIN=0
lavfi.signalstats.VLOW=76
lavfi.signalstats.VAVG=127.733
lavfi.signalstats.VHIGH=178
lavfi.signalstats.VMAX=255
}}}
so full-range y4m file from yuvtestsrc contain all Y, U, V values (as
requested!), even illegal (for RGB conversion later on) ones?
But then one method to kill illegal colors in yuv was said to be to
convert it to rgb and back
Not sure how specific figure in YUView should look for invalid colors
after such roundtrip? Right now it still look like limited range
conversion was applied twice at the end of range?
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:36>
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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by Balling): >Honestly, until now I was under impression RGB was superset of YUV, not other way around ... I was wrong! You just read one small text in https://stackoverflow.com/questions/17892346/how-to-convert-rgb-yuv-rgb- both-ways "Since the 8 bit YUV only uses Y values [16, 235] and U, V values [16, 240] it has less possible colors than RGB using [0, 255].", which is simply not true, there is a comment from me under that answer that says: It is not on any flagship TV. If you send YCbCr it will show superwhite and supercolors no problem. In some cases even xvYCC. LG C9 does it even in internal files player." -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:35> 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".
Re: [FFmpeg-trac] #8410(avcodec:new): wishlist vtt: support styling when converting to ass
#8410: wishlist vtt: support styling when converting to ass -+--- Reporter: Yi-Jyun Pan |Owner: (none) Type: enhancement | Status: new Priority: wish |Component: avcodec Version: git-master | Resolution: Keywords: webvtt | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+--- Comment (by Balling): >fit their discription of "data is lost" No, it does not. Data is not lost just not used. -- Ticket URL: <https://trac.ffmpeg.org/ticket/8410#comment:8> 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".
Re: [FFmpeg-trac] #8410(avcodec:new): wishlist vtt: support styling when converting to ass
#8410: wishlist vtt: support styling when converting to ass -+--- Reporter: Yi-Jyun Pan |Owner: (none) Type: enhancement | Status: new Priority: wish |Component: avcodec Version: git-master | Resolution: Keywords: webvtt | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+--- Comment (by solomoncyj): new references: https://github.com/yt-dlp/yt-dlp/issues/10796 https://code.videolan.org/videolan/vlc/-/issues/28744 -- Ticket URL: <https://trac.ffmpeg.org/ticket/8410#comment:7> 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".
Re: [FFmpeg-trac] #8410(avcodec:new): wishlist vtt: support styling when converting to ass
#8410: wishlist vtt: support styling when converting to ass -+--- Reporter: Yi-Jyun Pan |Owner: (none) Type: enhancement | Status: new Priority: wish |Component: avcodec Version: git-master | Resolution: Keywords: webvtt | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+--- Comment (by solomoncyj): can you please elveate to critical/important? it seems to fit their discription of "data is lost" -- Ticket URL: <https://trac.ffmpeg.org/ticket/8410#comment:6> 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".
Re: [FFmpeg-trac] #11159(avcodec:closed): Crash access violation in certain deployment
#11159: Crash access violation in certain deployment -+- Reporter: Truong Quoc |Owner: (none) Khanh | Type: defect | Status: closed Priority: normal |Component: avcodec Version: 7.0 | Resolution: Keywords: windows | worksforme h264 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Changes (by MasterQuestionable): * Attachment "ffmpeg-20240828-155140.log.7z" added. ͏ Workaround failed [ https://streams.videolan.org/upload/ ]. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11159> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Changes (by MasterQuestionable): * Attachment "swscale.c-mod.log" added. ͏ Prints:\\ ͏ https://trac.ffmpeg.org/attachment/ticket/11182/swscale.c-mod.log#L87 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge
difference
-+-
Reporter: Andrew-R |Owner: (none)
Type: defect | Status: closed
Priority: normal |Component: swscale
Version: unspecified | Resolution: invalid
Keywords: colorspace | Blocked By:
color_primaries|
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+-
Comment (by MasterQuestionable):
͏ "Why it calls limited to full if src already in full range?"
Looks like a valid bug?
͏ But the formatting...
͏ `diff --git "a/libswscale/swscale.c" "b/libswscale/swscale.c"`
͏ index df0d5708aa..c33082ca2a 100644
{{{#!diff
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -538,9 +538,12 @@ av_cold void ff_sws_init_range_convert(SwsContext *c)
if (c->srcRange != c->dstRange && !isAnyRGB(c->dstFormat)) {
if (c->dstBpc <= 14) {
if (c->srcRange) {
+ printf("luma range from full to limied\n");
c->lumConvertRange = lumRangeFromJpeg_c;
c->chrConvertRange = chrRangeFromJpeg_c;
} else {
+ printf("luma range from limited to full, srcrange %i
dstrange = %i \n", c->srcRange, c->dstRange);
+
c->lumConvertRange = lumRangeToJpeg_c;
c->chrConvertRange = chrRangeToJpeg_c;
}
}}}
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:34>
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".
Re: [FFmpeg-trac] #11192(avformat:new): Raw H264 stream has incorrect frame rate
#11192: Raw H264 stream has incorrect frame rate + Reporter: ariley |Owner: (none) Type: defect | Status: new Priority: important |Component: avformat Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | + Comment (by Balling): You did not test master. That has a bug that it recogizes all Annex B as 25 fps -- Ticket URL: <https://trac.ffmpeg.org/ticket/11192#comment:1> 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] #11192(avformat:new): Raw H264 stream has incorrect frame rate
#11192: Raw H264 stream has incorrect frame rate
--+--
Reporter: ariley| Type: defect
Status: new | Priority: important
Component: avformat | Version: git-master
Keywords:| Blocked By:
Blocking:| Reproduced by developer: 0
Analyzed by developer: 0 |
--+--
ffmpeg incorrectly decides that the frame rate for the certain H264
streams is 25fps, rather than 29.97fps:
{{{
$ ./ffprobe regression_ba4b73c977.h264
ffprobe version N-110262-gba4b73c977 Copyright (c) 2007-2023 the FFmpeg
developers
built with gcc 12 (Debian 12.2.0-14)
configuration: --extra-cflags=-g --extra-cxxflags=-g --optflags=-O0
libavutil 58. 6.100 / 58. 6.100
libavcodec 60. 9.100 / 60. 9.100
libavformat60. 4.101 / 60. 4.101
libavdevice60. 2.100 / 60. 2.100
libavfilter 9. 5.100 / 9. 5.100
libswscale 7. 2.100 / 7. 2.100
libswresample 4. 11.100 / 4. 11.100
[h264 @ 0x564e43afcdc0] Stream #0: not enough frames to estimate rate;
consider increasing probesize
Input #0, h264, from 'regression_ba4b73c977.h264':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: h264 (High 4:2:2), yuv422p10le(tv, bt709, top
first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 29.97 tbr, 1200k tbn
}}}
This is a regression -- prior to {{{ba4b73c977}}}, the FPS value was
correctly detected as 29.97:
{{{
$ ./ffprobe incorrect_fps.h264
ffprobe version N-110261-gd56652fdc8 Copyright (c) 2007-2023 the FFmpeg
developers
built with gcc 12 (Debian 12.2.0-14)
configuration: --extra-cflags=-g --extra-cxxflags=-g --optflags=-O0
libavutil 58. 6.100 / 58. 6.100
libavcodec 60. 9.100 / 60. 9.100
libavformat60. 4.101 / 60. 4.101
libavdevice60. 2.100 / 60. 2.100
libavfilter 9. 5.100 / 9. 5.100
libswscale 7. 2.100 / 7. 2.100
libswresample 4. 11.100 / 4. 11.100
[h264 @ 0x556699756dc0] Stream #0: not enough frames to estimate rate;
consider increasing probesize
Input #0, h264, from 'regression_ba4b73c977.h264':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: h264 (High 4:2:2), yuv422p10le(tv, bt709, top
first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1200k tbn
}}}
Increasing the probe size does not help.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11192>
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".
Re: [FFmpeg-trac] #10998(avutil:new): Removing the memory address in output messages' header?
#10998: Removing the memory address in output messages' header? -+- Reporter: |Owner: (none) MasterQuestionable | Type: enhancement | Status: new Priority: normal |Component: avutil Version: git-master | Resolution: Keywords: av_log | Blocked By: debug | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by MasterQuestionable): ͏ 2 woe examples: ͏ https://trac.ffmpeg.org/ticket/11185 ͏ https://trac.ffmpeg.org/ticket/11182#comment:32 -- Ticket URL: <https://trac.ffmpeg.org/ticket/10998#comment:2> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference -+- Reporter: Andrew-R |Owner: (none) Type: defect | Status: closed Priority: normal |Component: swscale Version: unspecified | Resolution: invalid Keywords: colorspace | Blocked By: color_primaries| Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+- Comment (by MasterQuestionable): ͏ Why bother such complexity, when even using lossy codecs meddling..? ͏ (however true lossless may not be meaningful whatsoever) -- Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:33> 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".
Re: [FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge
difference
-+-
Reporter: Andrew-R |Owner: (none)
Type: defect | Status: closed
Priority: normal |Component: swscale
Version: unspecified | Resolution: invalid
Keywords: colorspace | Blocked By:
color_primaries|
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0|
-+-
Comment (by Andrew-R):
so, I modded ffmpeg like this:
```
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index df0d5708aa..c33082ca2a 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -538,9 +538,12 @@ av_cold void ff_sws_init_range_convert(SwsContext *c)
if (c->srcRange != c->dstRange && !isAnyRGB(c->dstFormat)) {
if (c->dstBpc <= 14) {
if (c->srcRange) {
+ printf("luma range from full to limied\n");
c->lumConvertRange = lumRangeFromJpeg_c;
c->chrConvertRange = chrRangeFromJpeg_c;
} else {
+ printf("luma range from limited to full, srcrange %i
dstrange = %i \n", c->srcRange, c->dstRange);
+
c->lumConvertRange = lumRangeToJpeg_c;
c->chrConvertRange = chrRangeToJpeg_c;
}
```
and now it prints:
```
bash-5.1$ /dev/shm/ffmpeg/ffmpeg -color_range 2 -colorspace 5 -i /dev/shm
/yuv-mpeg-yuv444p.y4m -sws_dither 0 -vf format=rgb24 -pix_fmt yuv444p
-frames 2 -r 25 -color_range 2 -colorspace 5 /dev/shm/yuv-mpeg-rgba-
yuv444p.y4m -debug log
ffmpeg version N-115843-gc079ebdc57 Copyright (c) 2000-2024 the FFmpeg
developers
built with gcc 11.2.0 (GCC)
configuration: --disable-debug
libavutil 59. 36.100 / 59. 36.100
libavcodec 61. 13.100 / 61. 13.100
libavformat61. 5.101 / 61. 5.101
libavdevice61. 2.101 / 61. 2.101
libavfilter10. 2.102 / 10. 2.102
libswscale 8. 2.100 / 8. 2.100
libswresample 5. 2.100 / 5. 2.100
matched as AVOption 'debug' with argument 'log'.
Trailing option(s) found in the command: may be ignored.
Finished splitting the commandline.
Parsing a group of options: global .
Successfully parsed a group of options.
Parsing a group of options: input url /dev/shm/yuv-mpeg-yuv444p.y4m.
Successfully parsed a group of options.
Opening an input file: /dev/shm/yuv-mpeg-yuv444p.y4m.
[AVFormatContext @ 0xc5baa00] Opening '/dev/shm/yuv-mpeg-yuv444p.y4m' for
reading
[file @ 0xc5bafc0] Setting default whitelist 'file,crypto,data'
[yuv4mpegpipe @ 0xc5baa00] Format yuv4mpegpipe probed with size=2048 and
score=100
[yuv4mpegpipe @ 0xc5baa00] Before avformat_find_stream_info() pos: 67
bytes read:32768 seeks:0 nb_streams:1
[yuv4mpegpipe @ 0xc5baa00] All info found
[yuv4mpegpipe @ 0xc5baa00] After avformat_find_stream_info() pos: 230473
bytes read:230473 seeks:0 frames:1
Input #0, yuv4mpegpipe, from '/dev/shm/yuv-mpeg-yuv444p.y4m':
Duration: 00:00:03.00, start: 0.00, bitrate: 46081 kb/s
Stream #0:0, 1, 1/25: Video: rawvideo, 1 reference frame (444P /
0x50343434), yuv444p(pc, bt470bg/unknown/unknown, progressive), 320x240,
0/1, SAR 1:1 DAR 4:3, 25 fps, 25 tbr, 25 tbn
Successfully opened the file.
Parsing a group of options: output url /dev/shm/yuv-mpeg-rgba-yuv444p.y4m.
Applying option vf (alias for -filter:v (apply filters to video streams))
with argument format=rgb24.
Applying option pix_fmt (set pixel format) with argument yuv444p.
Applying option frames (set the number of frames to output) with argument
2.
Applying option r (override input framerate/convert to given output
framerate (Hz value, fraction or abbreviation)) with argument 25.
Successfully parsed a group of options.
Opening an output file: /dev/shm/yuv-mpeg-rgba-yuv444p.y4m.
[out#0/yuv4mpegpipe @ 0xc5bdb80] No explicit maps, mapping streams
automatically...
[vost#0:0/wrapped_avframe @ 0xc5be380] Created video stream from input
stream 0:0
[AVFilterGraph @ 0xc5bfc40] Setting 'pix_fmts' to value 'rgb24'
File '/dev/shm/yuv-mpeg-rgba-yuv444p.y4m' already exists. Overwrite? [y/N]
y
[file @ 0xc5c1d80] Setting default whitelist 'file,crypto,data'
Successfully opened the file.
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
[vost#0:0/wrapped_avframe @ 0xc5be380] Starting thread...
[vf#0:0 @ 0xc5bf8c0] Starting thread...
[vist#0:0/rawvideo @ 0xc5bd540] [dec:rawvideo @ 0xc5c0ec0] Starting
thread...
[in#0/yuv4mpegpipe @ 0
Re: [FFmpeg-trac] #11190(avcodec:new): H.264 video stops playing without errors
#11190: H.264 video stops playing without errors -+--- Reporter: kevmo314 |Owner: (none) Type: defect | Status: new Priority: normal |Component: avcodec Version: unspecified | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+--- Comment (by kevmo314): Unfortunately we do not have the nvidia decoder and we must use the software decoder. I've submitted a proposed patch here to allow playback of these frames if specific flags are set: https://ffmpeg.org/pipermail /ffmpeg-devel/2024-September/333451.html -- Ticket URL: <https://trac.ffmpeg.org/ticket/11190#comment:4> 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".
Re: [FFmpeg-trac] #11188(tools:new): ffmpeg_opt.c correct_input_start_times(void) calculates wrong ts_offset
#11188: ffmpeg_opt.c correct_input_start_times(void) calculates wrong ts_offset -+-- Reporter: Jens Viebig |Owner: (none) Type: defect | Status: new Priority: normal |Component: tools Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+-- Comment (by Balling): Yes, != has higher priority than ternary operation. Also (not that it matters here) everyone that is coding C needs to know that middle of the conditional operator (between ? and :) is parsed as if parenthesized: its precedence relative to ?: is ignored. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11188#comment:6> 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".
Re: [FFmpeg-trac] #11188(tools:new): ffmpeg_opt.c correct_input_start_times(void) calculates wrong ts_offset
#11188: ffmpeg_opt.c correct_input_start_times(void) calculates wrong ts_offset -+-- Reporter: Jens Viebig |Owner: (none) Type: defect | Status: new Priority: normal |Component: tools Version: git-master | Resolution: Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0| -+-- Comment (by Balling): >Why should we remove the other existing parentheses? Code style... Some other projects literally use clang format to remove all unneeded parentheses. This is high level code base, we do not care that people do not know C rules. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11188#comment:5> 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".
