unexpected PTSs inside avcodec_send_frame

[markshw]

It is observed that PTS on frame that is passed to avcodec_send_frame is not as expected, when ffmpeg is invoked with parameters to copy timebase from input to output.
The behavior changed from 5.1 and can be seen with 6.0 when ffmpeg is invoked with filter_complex. On ffmpeg 6.0 when invoked with -vf or without filters it works as expected

To reproduce, please apply the attached patch (or simply add logging in avcodec_send_frame for the frame->pts)

Command line examples:
works as expected:
./ffmpeg -y -i ~/Downloads/test.mp4 -vsync vfr -copyts -enc_time_base -1 -vf "scale=1280:720" -c:v libx264 ~/output.mp4 -loglevel info
logged PTSs are 0, 512,1024,1536,2048,...

UNEXPECTED timestamps
./ffmpeg -y -i ~/Downloads/test.mp4 -vsync vfr -copyts -enc_time_base -1 -filter_complex "scale=1280:720" -c:v libx264 ~/output.mp4 -loglevel info
logged PTSs are
0,1,2,3,4,5....

[markshw]

sample input file

[markshw]

patch to apply to enable logging

[markshw]

I was able to narrow down and looks like the behavior changed with this commit bda06c60fed8e45481ca2dad040ed9d2f521ca15

50ecba7e8474966517cdd28c4ce9d9258e9b14e6 - has the "expected" / previous behavior

[elenril]

You should see something like
[vost#0:0/libx264 @ 0x5611801c3740] Input stream data not available, using default time base
in log. The reason this happens is that with -filter_complex, by definition, there isn't a single unambiguous source stream for your output stream, so taking the source timebase is not a well-defined operation. I've actually written a patch recently that would make it an error:
​http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-May/310279.html

The question is why are you using -filter_complex here at all.

[markshw]

Thanks for looking into it - I'm using filter complex because I'm outputting multiple lanes and I want to reuse the output of some filters that is shared across lanes. For this ticket I simplified the filter graph I'm using to the minimum showing the problem, sorry if this added confusion

The production filter graph I have has one input as well (like in this example), so source timebase is well defined in this case

Thanks again for your help

[elenril]

Should be fixed in dff3a283cd8c71802d43fbbbfcf57fb479784a24.
Note that the -1 syntax is now deprecated and you should switch to -enc_time_base demux instead. filter is now also available, allowing you to use the timebase from the filtergraph.