[FFmpeg-devel] [PATCH v4 1/3] avformat: add fields to AVProgram/AVStream for PMT change tracking

Jan Ekström jeebjp at gmail.com
Sun May 20 17:21:15 EEST 2018


On Sun, May 20, 2018 at 2:06 PM, Jan Ekström <jeebjp at gmail.com> wrote:
> On Sun, May 20, 2018 at 1:54 PM, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>
>> Reading the original submission above, isn't the whole point of the
>> patch to add public symbols to help downstream with real-world
>> issues?
>>
>> Carl Eugen
>
> Yes, currently the API user has no visibility over how the programs
> are being updated. Two alternative takes on this were listed in the
> commit message, one being a call-back and another being a custom data
> packet from stream id 0.
>
> So yes, the pmt_version is most definitely meant to be publicly
> utilized, with it the proper utilization would go as follows:
> 1) API client picks the program(s) it cares about, and gets the
> AVProgram(s)' pointers and notes the pmt_version when it started
> reading.
> 2) After each AVPacket read, it checks if the pmt_version was updated.
> If it was, it iterates over the streams currently registered in the
> AVProgram(s) it cares about.
> 3) If any streams got dropped, those should be no longer cared about
> by the API client. If any streams got added, they should be checked by
> the API client if it is interested in them.
>
> This is an upgrade on the previous state of affairs which would have
> required the following:
> 1) API client picks the program(s) it cares about, and gets the
> AVProgram(s)' pointers.
> 2) After each AVPacket read, it iterates over the streams currently
> registered in the AVProgram(s) it cares about.
> 3) If any streams got dropped, those should be no longer cared about
> by the API client. If any streams got added, they should be checked by
> the API client if it is interested in them.
>
> It is not perfect, but still an upgrade, since you can just check an
> integer now, instead of doing the full iteration every time you read
> an AVPacket.
>
>
> Best regards,
> Jan

Oh, and I'm not sure if lavf's internal reordering of packets could
make it happen that you receive the program update, and then still
receive one or more packets from the previous stream. In that case you
might also incorporate some check that the flush and reset of previous
decoder only happens after you get your first new packet for that new
stream.

Jan


More information about the ffmpeg-devel mailing list