Re: [FFmpeg-user] Faster ffprobe-based detection of open GOP h264 ?
чт, 11 янв. 2024 г., 03:13 Andrew Randrianasulu :
> I was looking at videohelp forum
>
>
> https://web.archive.org/web/20201125203546/https://forum.videohelp.com/threads/398119-Cutting-Open-GOP-H264-videos-properly
>
> (web archive link because it hopefully will stay active for some time even
> if forum software will be upgraded and ruin old links in the future)
>
> It provides this ffprobe-based method of seeing if given h264 video stream
> is Open GOP or not :
>
> echo entry,pkt_pts_time,pict_type,coded_picture_number > "%~n1.csv"
>
> ffprobe -v 32 -stats -y -hide_banner -i %1 -select_streams v -print_format
> csv -of csv -show_entries
> "frame=pkt_pts_time,pict_type,coded_picture_number" >> "%~n1.csv"
>
> === quote
>
> You can see that the last frame of the first GOP is a B frame -- so that's
> an open GOP. Also, the coded picture number is higher than that of the I
> frame after it -- indicating that the I frame had to be decoded before the
> B frame, another indication of an open GOP.
>
> === quote ends ===
>
> I checked one of my videos:
>
> ffprobe -v 32 -stats -y -hide_banner -i
> ~/Sea_of_life_plus_Mikura_dolphins_test.mp4 -select_streams v -print_format
> csv -of csv -show_entries
> "frame=pkt_pts_time,pict_type,coded_picture_number" >> "Sea_of_life-n1.csv"
>
> and it seems resulting cvs file show it as open GOP consistently with
> mediainfo:
>
> frame,8.308300,B,250
> frame,8.341667,I,249
> frame,8.375033,B,253
>
> mediainfo (v23.11) snip:
>
> === snip ===
>
> Video
>
> ID : 1
>
> Format : AVC
> Format/Info : Advanced Video
> Codec
> Format profile : High@L4.1
> Format settings : 4 Ref Frames
>
> Format settings, CABAC : No
> Format settings, Reference frames: 4 frames
>
> Codec ID : avc1
>
> Codec ID/Info: Advanced Video Coding
>
> Duration : 5 min 4 s
> Bit rate : 16.0 Mb/s
> Width: 1 920 pixels
>
> Height : 1 080 pixels
>
> Display aspect ratio : 16:9
>
> Frame rate mode : Constant
>
> Frame rate : 29.970 (3/1001) FPS
> Color space : YUV
>
> Chroma subsampling : 4:2:0
>
> Bit depth: 8 bits
>
> Scan type: Progressive
>
> Bits/(Pixel*Frame) : 0.257
> Stream size : 575 MiB (99%)
>
> Writing library : x264 core 148
>
> Encoding settings: cabac=0 / ref=3 / deblock=1:0:0
> / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 /
> mixed_ref=1 / me_range=16 / chroma_me=0 / trellis=1 / 8x8dct=1 / cqm=0 /
> deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 /
> lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 /
> bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=0
> / b_bias=0 / direct=1 / weightb=1 / open_gop=1 / weightp=2 / keyint=250 /
> keyint_min=25 / scenecut=0 / intra_refresh=0 / rc_lookahead=40 / rc=abr /
> mbtree=1 / bitrate=16000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 /
> qpstep=4 / ip_ratio=1.41 / aq=1:1.00
>
> Codec configuration box : avcC
>
> snip ends ===
>
> So, at least I may try to cut this video at various intervals and see if
> cutting breaks on specifically open-gop h264 stream.
>
> But as it was said in forum post above - ffprobe a bit slow, few minutes
> for whole video, eating one cpu core completely.
>
> Is there faster way to get this info ?
>
Additionally, I tried to add another variable key_frame to see difference
between IDR frames (I type , key_frame=1) and just I type frames:
ffprobe -v 32 -stats -y -hide_banner -i
~/Sea_of_life_plus_Mikura_dolphins_test.mp4 -select_streams v -print_format
csv -of csv -show_entries
"frame=pkt_pts_time,pict_type,key_frame,coded_picture_number" >>
"Sea_of_life-n1-v1.csv"
but resulting csv file grouped them like
frame,1,8.341667,I,249
like key_frame come before pkt_pts_time.
May be this is bug due to ffprobe being from v. 4.4.4 and not latest. Not
sure. But interesting.
I also see few picture types in libavutil/avutil.h
enum AVPictureType {
AV_PICTURE_TYPE_NONE = 0, ///< Undefined
AV_PICTURE_TYPE_I, ///< Intra
AV_PICTURE_TYPE_P, ///< Predicted
AV_PICTURE_TYPE_B, ///< Bi-dir predicted
AV_PICTURE_TYPE_S, ///< S(GMC)-VOP MPEG-4
AV_PICTURE_TYPE_SI,///< Switching Intra
AV_PICTURE_TYPE_SP,///< Switching Predicted
AV_PICTURE_TYPE_BI,///< BI type
};
Is this list complete when it comes to codecs
[FFmpeg-user] Faster ffprobe-based detection of open GOP h264 ?
I was looking at videohelp forum https://web.archive.org/web/20201125203546/https://forum.videohelp.com/threads/398119-Cutting-Open-GOP-H264-videos-properly (web archive link because it hopefully will stay active for some time even if forum software will be upgraded and ruin old links in the future) It provides this ffprobe-based method of seeing if given h264 video stream is Open GOP or not : echo entry,pkt_pts_time,pict_type,coded_picture_number > "%~n1.csv" ffprobe -v 32 -stats -y -hide_banner -i %1 -select_streams v -print_format csv -of csv -show_entries "frame=pkt_pts_time,pict_type,coded_picture_number" >> "%~n1.csv" === quote You can see that the last frame of the first GOP is a B frame -- so that's an open GOP. Also, the coded picture number is higher than that of the I frame after it -- indicating that the I frame had to be decoded before the B frame, another indication of an open GOP. === quote ends === I checked one of my videos: ffprobe -v 32 -stats -y -hide_banner -i ~/Sea_of_life_plus_Mikura_dolphins_test.mp4 -select_streams v -print_format csv -of csv -show_entries "frame=pkt_pts_time,pict_type,coded_picture_number" >> "Sea_of_life-n1.csv" and it seems resulting cvs file show it as open GOP consistently with mediainfo: frame,8.308300,B,250 frame,8.341667,I,249 frame,8.375033,B,253 mediainfo (v23.11) snip: === snip === Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings : 4 Ref Frames Format settings, CABAC : No Format settings, Reference frames: 4 frames Codec ID : avc1 Codec ID/Info: Advanced Video Coding Duration : 5 min 4 s Bit rate : 16.0 Mb/s Width: 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 29.970 (3/1001) FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth: 8 bits Scan type: Progressive Bits/(Pixel*Frame) : 0.257 Stream size : 575 MiB (99%) Writing library : x264 core 148 Encoding settings: cabac=0 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=0 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=0 / b_bias=0 / direct=1 / weightb=1 / open_gop=1 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=0 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=16000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.41 / aq=1:1.00 Codec configuration box : avcC snip ends === So, at least I may try to cut this video at various intervals and see if cutting breaks on specifically open-gop h264 stream. But as it was said in forum post above - ffprobe a bit slow, few minutes for whole video, eating one cpu core completely. Is there faster way to get this info ? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Best way convert to mpg
Am 10.01.24 um 22:38 schrieb Budi Janto:
Hi,
In last week I tried to convert *.dat, *.avi and other video format to
*.mpg. This caused our application support only for *.mpg file (Work
well). So for this required, I just convert it without any modification
sound/video quality (AS-IS) for e.g:
Command used to convert *.dat to *.mpg.
# find * -type f -iname "*.dat" -exec sh -c 'ffmpeg -hide_banner -y -i
"$0" -vcodec copy -acodec copy "${0%.dat}.mpg"' {} \;
Command used to convert *.avi to *.mpg.
# find * -type f -iname "*.avi" -exec sh -c 'ffmpeg -hide_banner -y -i
"$0" -c:v copy -c:a copy "${0%.avi}.mpg"' {} \;
"-vcodec copy -acodec copy" - so you specify don't re-encode anyhting
which can be done also by changing the file extension, both don't make
any sense
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On 1/10/24 16:50, Devin Heitmueller wrote: On Wed, Jan 10, 2024 at 4:26 PM Mark Filipak wrote: The change from 1048560 to 1174560 has to be happening inside the muxer, wouldn't you say? We now know that what's going into the muxer is right. Here is what went to the target file in the last run: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1,1 Try setting -muxdelay 0 on the output options. If not specified it defaults to 0.7, and the delta between 1174560 and 1048560 is exactly 1.4 seconds. I don't know why you're getting exactly 2x the mux delay rather than just being off by 0.7s, but I suspect it's the muxdelay that is causing you to get PTS values which are not what you would expect. Devon, you're a lifesaver. That did it. Look: 0,1044806,1048560, 3753, 640646, 0x900a1a7a, S=1,1 So, to summarize, I needed '-copyts' before '-i' and '-muxdelay 0' after '-i'. Is there any reason I should _not_ make those permanent and do them every time? Thanks so much for your help. I could _never_ have done that on my own. Now that there's fewer moving parts, I can maybe make more progress in my main task: Towards better trims & concatenations. But first, I have about 30 work files to delete. -- Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On Wed, Jan 10, 2024 at 4:26 PM Mark Filipak wrote: > The change from 1048560 to 1174560 has to be happening inside the muxer, > wouldn't you say? We now > know that what's going into the muxer is right. Here is what went to the > target file in the last run: > > 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1,1 Try setting -muxdelay 0 on the output options. If not specified it defaults to 0.7, and the delta between 1174560 and 1048560 is exactly 1.4 seconds. I don't know why you're getting exactly 2x the mux delay rather than just being off by 0.7s, but I suspect it's the muxdelay that is causing you to get PTS values which are not what you would expect. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Best way convert to mpg
Hi,
In last week I tried to convert *.dat, *.avi and other video format to
*.mpg. This caused our application support only for *.mpg file (Work
well). So for this required, I just convert it without any modification
sound/video quality (AS-IS) for e.g:
Command used to convert *.dat to *.mpg.
# find * -type f -iname "*.dat" -exec sh -c 'ffmpeg -hide_banner -y -i
"$0" -vcodec copy -acodec copy "${0%.dat}.mpg"' {} \;
Command used to convert *.avi to *.mpg.
# find * -type f -iname "*.avi" -exec sh -c 'ffmpeg -hide_banner -y -i
"$0" -c:v copy -c:a copy "${0%.avi}.mpg"' {} \;
But sometime, I got message something like this:
[...]
[mpeg @ 0x1498ec830280] Invalid timestamps stream=0, pts=27603,
dts=20554804, size=2296
[mpeg @ 0x1498ec830500] Invalid DTS: 20523600 PTS: -3601 in output
stream 0:0, replacing by guess
[...]
[...]
[mpeg @ 0x1d7db2030500] Non-monotonic DTS in output stream 0:0;
previous: 16050049, current: 16050049; changing to 16050050. This may
result in incorrect timestamps in the output file.
[mpeg @ 0x1d7db2030500] Non-monotonic DTS in output stream 0:0;
previous: 16057249, current: 16057249; changing to 16057250. This may
result in incorrect timestamps in the output file.
[mpeg @ 0x1d7db2030500] Non-monotonic DTS in output stream 0:0;
previous: 16064449, current: 16064449; changing to 16064450. This may
result in incorrect timestamps in the output file.
[mpeg @ 0x1d7db2030500] Non-monotonic DTS in output stream 0:0;
previous: 16071649, current: 16071649; changing to 16071650. This may
result in incorrect timestamps in the output file.
[...]
[...]
[mpeg @ 0x13522ca30500] buffer underflow st=0 bufi=45673 size=48884
[mpeg @ 0x13522ca30500] packet too large, ignoring buffer limits to mux it
[mpeg @ 0x13522ca30500] buffer underflow st=0 bufi=45673 size=48884
[mpeg @ 0x13522ca30500] buffer underflow st=0 bufi=47702 size=48884
[mpeg @ 0x13522ca30500] packet too large, ignoring buffer limits to mux it
[mpeg @ 0x13522ca30500] buffer underflow st=0 bufi=47702 size=48884
[mpeg @ 0x13522ca30500] buffer underflow st=0 bufi=45144 size=51127
[mpeg @ 0x13522ca30500] packet too large, ignoring buffer limits to mux it
[mpeg @ 0x13522ca30500] buffer underflow st=0 bufi=45144 size=51127
[mpeg @ 0x13522ca30500] buffer underflow st=0 bufi=47173 size=51127
[mpeg @ 0x13522ca30500] packet too large, ignoring buffer limits to mux it
[...]
Can I ignore that messages? But I can play that converts videos. Thanks
for your time.
--
Regards,
Budi Janto
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On 1/10/24 15:46, Mark Filipak wrote: On 1/10/24 13:55, Devin Heitmueller wrote: On Wed, Jan 10, 2024 at 1:42 PM Mark Filipak wrote: Thanks, Devin, but nope, they're a lot closer but they're still not the same. set FORCE=-bsf:v setts=dts=DTS:pts=PTS set SOURCE=h:\BDMV\STREAM\00305.m2ts : IS: 0, 1044806, 1048560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 %FORCE% -c copy -sn -dn c:\target_2.m2ts : RESULT: 0, 1170806, 1174560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 -c copy -sn -dn c:\target_1.m2ts : RESULT: 0, 1170806, 1174560, 3753, 640646, 0x900a1a7a, S=1, 1 While I'm not sure why you're not getting the expected output, you can add "-debug_ts" to your ffmpeg command line as a global option and it will show the timestamps for the packets at every stage (i.e. demux/rebasing/decoding/encoding/muxing). That should allow you to track down where in the pipeline the timestamp is changing. I have some beautified debug to paste in here, but first I need to say that here is where the packet CRCs are really needed. Too bad they're not listed by '-debug_ts'. Here is the first video packet: type pkt_pts pkt_dts duration [vist#0:0/h264...] demuxer video 1048560 1044806 3753 [vist#0:0/h264...] demuxer+tsfixup video 1048560 1044806 3753 demuxer+ffmpeg video 1048560 1044806 3753 off:0 [aost#0:1/copy...] muxer <- audio pkt_pts:1048560 pkt_dts:1048560 duration:960 size:1084 As shown in my previous post, PTS=1048560 is being changed to PTS=1174560 Confirmed: 1048560 is the lowest PTS. Confirmed: 1174560 doesn't appear anywhere. So, the change from 1048560 to 1174560 remains mysterious. The change from 1048560 to 1174560 has to be happening inside the muxer, wouldn't you say? We now know that what's going into the muxer is right. Here is what went to the target file in the last run: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1,1 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On 1/10/24 13:55, Devin Heitmueller wrote: On Wed, Jan 10, 2024 at 1:42 PM Mark Filipak wrote: Thanks, Devin, but nope, they're a lot closer but they're still not the same. set FORCE=-bsf:v setts=dts=DTS:pts=PTS set SOURCE=h:\BDMV\STREAM\00305.m2ts : IS: 0,1044806,1048560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 %FORCE% -c copy -sn -dn c:\target_2.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 -c copy -sn -dn c:\target_1.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 While I'm not sure why you're not getting the expected output, you can add "-debug_ts" to your ffmpeg command line as a global option and it will show the timestamps for the packets at every stage (i.e. demux/rebasing/decoding/encoding/muxing). That should allow you to track down where in the pipeline the timestamp is changing. I have some beautified debug to paste in here, but first I need to say that here is where the packet CRCs are really needed. Too bad they're not listed by '-debug_ts'. Here is the first video packet:type pkt_pts pkt_dts duration [vist#0:0/h264...] demuxer video 1048560 1044806 3753 [vist#0:0/h264...] demuxer+tsfixup video 1048560 1044806 3753 demuxer+ffmpeg video 1048560 1044806 3753 off:0 [aost#0:1/copy...] muxer <- audio pkt_pts:1048560 pkt_dts:1048560 duration:960 size:1084 As shown in my previous post, PTS=1048560 is being changed to PTS=1174560 Confirmed: 1048560 is the lowest PTS. Confirmed: 1174560 doesn't appear anywhere. So, the change from 1048560 to 1174560 remains mysterious. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On Wed, Jan 10, 2024 at 1:42 PM Mark Filipak wrote: > > Correction... > > On 1/10/24 13:21, Devin Heitmueller wrote: > > On Wed, Jan 10, 2024 at 12:50 PM Mark Filipak > > wrote: > >> > >> Question: How can I force the target's DTS to be the source's DTS? > > > > Add "-copyts" to the front of the command-line as a global option. > > The ffmpeg application will automatically rebase timestamps to zero > > after demuxing unless you specify this option (which is further up the > > pipeline than your bsf, hence the bsf has no effect). > > > > Devin > > Thanks, Devin, but nope, they're a lot closer but they're still not the same. > > set FORCE=-bsf:v setts=dts=DTS:pts=PTS > set SOURCE=h:\BDMV\STREAM\00305.m2ts > : IS: 0,1044806,1048560, 3753, 640646, 0x900a1a7a, S=1, 1 > > ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 %FORCE% -c copy -sn -dn > c:\target_2.m2ts > : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 > > ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 -c copy -sn -dn > c:\target_1.m2ts > : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 > > Sorry I flubbed the command lines. These are correct. While I'm not sure why you're not getting the expected output, you can add "-debug_ts" to your ffmpeg command line as a global option and it will show the timestamps for the packets at every stage (i.e. demux/rebasing/decoding/encoding/muxing). That should allow you to track down where in the pipeline the timestamp is changing. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
Correction... On 1/10/24 13:21, Devin Heitmueller wrote: On Wed, Jan 10, 2024 at 12:50 PM Mark Filipak wrote: Question: How can I force the target's DTS to be the source's DTS? Add "-copyts" to the front of the command-line as a global option. The ffmpeg application will automatically rebase timestamps to zero after demuxing unless you specify this option (which is further up the pipeline than your bsf, hence the bsf has no effect). Devin Thanks, Devin, but nope, they're a lot closer but they're still not the same. set FORCE=-bsf:v setts=dts=DTS:pts=PTS set SOURCE=h:\BDMV\STREAM\00305.m2ts : IS: 0,1044806,1048560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 %FORCE% -c copy -sn -dn c:\target_2.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -copyts -i %SOURCE% -map 0 -c copy -sn -dn c:\target_1.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 Sorry I flubbed the command lines. These are correct. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On 1/10/24 13:21, Devin Heitmueller wrote: On Wed, Jan 10, 2024 at 12:50 PM Mark Filipak wrote: Question: How can I force the target's DTS to be the source's DTS? Add "-copyts" to the front of the command-line as a global option. The ffmpeg application will automatically rebase timestamps to zero after demuxing unless you specify this option (which is further up the pipeline than your bsf, hence the bsf has no effect). Devin Thanks, Devin, but nope, they're a lot closer but they're still not the same. set FORCE=-bsf:v setts=dts=DTS:pts=PTS set SOURCE=h:\BDMV\STREAM\00305.m2ts : IS: 0,1044806,1048560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -i %SOURCE% -map 0 -copyts %FORCE% -c copy -sn -dn c:\target_2.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -i %SOURCE% -map 0 -copyts-c copy -sn -dn c:\target_1.m2ts : RESULT: 0,1170806,1174560, 3753, 640646, 0x900a1a7a, S=1, 1 ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Force target DTS == source DTS -- How?
On Wed, Jan 10, 2024 at 12:50 PM Mark Filipak wrote: > > Question: How can I force the target's DTS to be the source's DTS? Add "-copyts" to the front of the command-line as a global option. The ffmpeg application will automatically rebase timestamps to zero after demuxing unless you specify this option (which is further up the pipeline than your bsf, hence the bsf has no effect). Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Force target DTS == source DTS -- How?
Question: How can I force the target's DTS to be the source's DTS? I'm simply demuxing and remuxing. To make the targets: set FORCE=-bsf:v setts=dts=DTS:pts=PTS set SOURCE=h:\BDMV\STREAM\00305.m2ts : IS: 0,1044806,1048560, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -i %SOURCE% -map 0 -c copy -sn -dn c:\target_1.m2ts : RESULT: 0, 126000, 129754, 3753, 640646, 0x900a1a7a, S=1, 1 ffmpeg -to 39.122 -i %SOURCE% -map 0 %FORCE% -c copy -sn -dn c:\target_2.m2ts : RESULT: 0, 126000, 129754, 3753, 640646, 0x900a1a7a, S=1, 1 Thanks, Mark. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Decoding performance, 6.1.1 vs. 4.4.4
On 1/10/2024 4:18 AM, Ren� J. V. Bertin wrote: (sorry for the linebreaks, I'm posting via a newsgroup app.) (Use an email program instead?) To me this looks like there's been a regression that causes an increased overhead in getting the content onto and/or off the GPU. Have you controlled for the graphics drivers (same for each build)? Also, try doing both builds with the same compiler. Is that possible? Could it have to do with the fact that FFmpeg6 auto-enables support for hw-acceleration via Vulkan (a moot selling point on this hardware) and if so would it help to disable that support? Definitely disable it for a better comparison, there may be extra steps in the data pathways which could affect the speed. Later, z! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Decoding performance, 6.1.1 vs. 4.4.4
Hi,
I've just built and installed FFmpeg 6.1.1 in parallel to my trust 4.4.4
installation, using the exact same compiler options and clang (9 and 8,
respectively; v6.1.1 does get debug info via `-g`). This is about performance
on
2 older machines: a Mac with a 2nd gen i7 (Sandybridge) and a Linux notebook
with an N3150 CPU, both having only the eGPU for graphics and thus limited to
H264 decoding in terms of hardware acceleration.
To evaluate performance I used 2 1080p videos; a VP9 one downloaded from YT
(30Hz) and the "Big Buck Bunny" video from the Blender foundation
(bbb_sunflower_1080p_60fps_normal.mp4; H264, 60Hz).
I used `-threads 4 -i -benchmark -f null -`.
On the Mac, performance compares as you'd prefer to see it: v6.1.1 is
consistently a tiny bit faster for CPU decoding than v4.4.4 while
hw-accelerated
decoding is just as fast (or slow if you want).
On Linux the situation is opposite, sadly. A consistent small loss of
performance for v6.1.1 in CPU decoding but the big surprise was a somewhat
bigger loss in VAAPI-accelerated decoding.
FFmpeg 4.4.4:
```
> time ffmpeg -threads 4 -hwaccel vaapi -i bbb_sunflower_1080p_60fps_normal.mp4
> -
benchmark -f null -
frame=38072 fps=123 q=-0.0 Lsize=N/A time=00:10:34.56 bitrate=N/A speed=2.05x
video:19928kB audio:356706kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
bench: utime=198.046s stime=44.752s rtime=309.083s
bench: maxrss=168904kB
198.431 user_cpu 44.791 kernel_cpu 5:09.48 total_time 78.5%CPU {168904M 13F
2504898R 695857I 0O 462253w 226657c}
```
FFmpeg 6.1.1:
```
> time ffmpeg6 -threads 4 -hwaccel vaapi -i
> bbb_sunflower_1080p_60fps_normal.mp4
-benchmark -f null -
frame=38072 fps= 91 q=-0.0 Lsize=N/A time=00:10:34.55 bitrate=N/A speed=1.51x
bench: utime=245.679s stime=119.927s rtime=419.141s
bench: maxrss=137632kB
246.007 user_cpu 119.987 kernel_cpu 6:59.49 total_time 87.2%CPU {137632M 0F
16342471R 695447I 0O 847360w 243741c}
```
(sorry for the linebreaks, I'm posting via a newsgroup app.)
To me this looks like there's been a regression that causes an increased
overhead in getting the content onto and/or off the GPU.
Is that possible? Could it have to do with the fact that FFmpeg6 auto-enables
support for hw-acceleration via Vulkan (a moot selling point on this hardware)
and if so would it help to disable that support?
Thanks,
R.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
