Introduce a protocol for Google-breaks-everything incidents
===========================================================
There have been enough Google-breaks-everything shitstorms, it's time to introduce a better protocol to reduce user confusion during these trying periods.
Here's the protocol:
- Once a report is confirmed and proven to be non-transient (e.g. still reproducible after 24 hours), regardlessly of whether a fix can be made available immediately, the epoch in `googler` and `info.json` should be advanced to the date of the report (in UTC), and the issue number recorded. `info.json` should look like:
```json
{
"epoch": "20201001",
"tracking_issue": 372,
"fixed_on_master": false,
"fixed_in_release": false
}
```
At this point users would see a message like this:
```console
$ googler hello # Issue acknowledged, not fixed.
No results.
Your version of googler is broken due to Google-side changes.
The issue is tracked at https://github.com/jarun/googler/issues/372.
```
- Once a fix is committed to master, `fixed_on_master` should be set to `true`:
```json
{
"epoch": "20201001",
"tracking_issue": 372,
"fixed_on_master": true,
"fixed_in_release": false
}
```
At this point users would see a message like this:
```console
$ googler hello # Fixed on master, not released.
No results.
Your version of googler is broken due to Google-side changes.
The fix has been pushed to master, pending a release.
Please download the master version https://git.io/googler or wait for a release.
```
- Once the fix is released, `fixed_in_released` should be updated to the version tag:
```json
{
"epoch": "20201001",
"tracking_issue": 372,
"fixed_on_master": true,
"fixed_in_release": "v4.3"
}
```
At this point users would see a message like this:
```console
$ googler hello # Fix released.
No results.
Your version of googler is broken due to Google-side changes.
A new version, v4.3, has been released to address the changes.
Please upgrade to the latest version.
```
I'll create a wiki page for this protocol if we can agree on it.
> I'm trying to decode a video in .h264. On C++ I could simply make the pointer inside the AvPacket point to my chunk of h264 data and it'd work. On Rust, since it copies to AvPacket instead of setting pointer, I don't know but I'm not being able to decode.
>
> ...
>
> Is av_parser_parse2 really needed?
If your stream is delimited, you can simply use `Packet::copy` as I demonstrated in #29 ([sample code](https://gist.github.com/zmwangx/0efa56bba9daef3d460b9ccf3a4832df)). If not and you absolutely can't use facilities provided by lavf which handles parsing for you, then I suppose you do need `av_parser_*`. Personally I'm not familiar with `av_parser_*` which is pretty low level.
> I created the parse2 function
I took a very brief look, you're making a big breaking change to `codec::Context` by adding pub fields, which is unacceptable. I think if the `av_parser_*` API should be implemented, it should be separate from the decoder API, but this has to be thought through, and to be clear I haven't familiarized myself with the API and don't have the capacity to do so in the near future. (As stated in README: the crate is in maintenance-only mode for the most part, and I don't have much time to implement new features or even review PRs implementing them.) I can leave this open until I have time or manage to find a collaborator.
> I'm also adding support for compilating against ffmpeg with vdpau, which also have some modificaitons on the rust-ffmpeg-sys repo, I'll post later.
That sort of change is easy to review, so by all means open a PR when you're ready.