-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement an FfmpegVideoRenderer #2159
Comments
We don't have any plans to provide an Ffmpeg video renderer. I'm fairly sure it's perfectly feasible to implement one, although note that in many cases software decoders will not be as power efficient or as performant as those provided by the platform. Marking as an enhancement in any case. |
Appreciate the response. I'll definitely take a crack at this then. The idea was that it would only be used as a fallback. There was one thing I wasn't 100% sure of though. Most cases of unsupported video in my use case is generally because of extreme resolutions (3-8MP cameras). Would it make more sense to scale the image using ffmpeg/x264? Or rely on the rasterizer to downscale the final result? |
|
Yep you would be correct. I always assumed it supported decoding, but I never dug into the libx264 side of it too much until now. Sounds like I'll have to do a bit of benchmarking to come up with the ideal solution. I will definitely look at the VP9 extension more. Thanks for the advice. |
It would be great to have a ffmpeg video render |
I ended up not pursuing this on my end because of the licensing issues with FFMPEG. |
I've started writing a skeleton of FfmpegVideoRenderer. At the moment it's mainly a lot of placeholders with plumbing to a ffmpeg mpeg2video decoder. However the decoding fails in ffmpeg, because of invalid input data. The "render" method is very similar to other available renderers: wait for input format, then drain output buffers, then feed input buffers. What I noticed is that the data returned by "readSource" (inherited from BaseRenderer) only contains the picture data (with start code 00000100), but I also need to feed all data to the ffmpeg decoder, in particular the sequence segment (with start code 000001b3). I have no idea why I only get the picture segments, and not the entire MPEG2 stream. Any hint appreciated. |
I've compared the data that is processed by MediaCodecRender (my Android device has a MPEG2 decoder builtin), and it appears that its calls to "readSource" also only get the picture segments. Is that a property of the implementation of H262Reader? (my sample clip is a MPEG/TS with MPEG2/MP2). If yes, is there a workaround to make the renderer to get the full MPEG2 data stream? |
My initial assessment was incorrect. The MPEG2 stream is segmented by H262Reader into TrackOutput on the START_PICTURE boundaries. That's why I see that start code when I inspect the starting bytes of the data received my renderer. However the problem is that the data between the start of the MPEG2 stream and the first START_PICTURE is lost and does not reach the renderer. And this is where the sequence header is located (the stream starts with sequence, extended sequence, GOP and then the first START_PICTURE), which is required by ffmpeg decoder. |
You'll probably find what you're looking for in the |
Thanks, I hadn't realized that the initialization data contained the sequence and sequence extension headers. They're pre-parsed by the mpeg2video codec automatically when set as extradata on the context. Now I can get my FfmpegVideoRenderer to work. |
Hi @goffioul could you share you code regarding |
@michalliu This is the current code I have. It's quite raw, it's just an experiment at the moment. It was focused on getting MPEG2 decoder, but unfortunately I hit bug #2891, in particular bad pixellation due to the segmentation in H262Reader. And trying to fix it resulted in another bug I don't know how to solve. A few things to note:
At the moment I stopped working on this, because of other priorities and a lack of time. But I hope to be able to resume the work at a later stage. Let me know if you're interested in joint effort. |
@goffioul Thanks for sharing the code and the instructions. I'm very interested in this idea. My work is busy too. We use exoplayer in our project currently. Hopefully I can persuade my boss to support my idea so i can put my time on it. |
Hi guys. I'd like to let you know we have implemented hevc software decoder using OpenHEVC, we are ready to submit a merge request soon. |
The repository is located at https://github.com/michalliu/exoplayer2-hevc-extension |
@michalliu how to use this ? |
@ranakhizar1556
|
This comment has been minimized.
This comment has been minimized.
There is a prototype pull request here: #7079 |
Issue: #2159 PiperOrigin-RevId: 301345559
Issue: #2159 PiperOrigin-RevId: 301351495
The restriction that these classes only work with SimpleDecoders is unnecessary. An FfmpegVideoRenderer will not be able to use a SimpleDecoder, because the SimpleDecoder assumption that each input buffer can be decoded immediately into a corresponding output is not true for all video codecs that Ffmpeg supports (e.g., H264 does not have this property). Generalizing SimpleDecoderVideoRenderer to DecoderVideoRenderer will allow FfmpegVideoRenderer to still use the base class, without having to use a SimpleDecoder. This is a preliminary change toward being able to merge a version of #7079. Issue: #2159 PiperOrigin-RevId: 301412344
FFmpeg requires input buffers to be sized larger than the size of the data they contain. This is to allow optimized decoder implementations that read data in fixed size chunks, without the risk of such decoders reading beyond the end of the buffer. Issue: #2159 PiperOrigin-RevId: 310946866
Is there any updates for this request? I wish to try to do similar things now as the Exoplayer is not working in my target devices when playing 4K video(see my issue #7835 ). I understand that the HW decoder is far more powerful than SW's, but the fact is that: |
We haven't made much progress beyond the update above, unfortunately. Doing it properly turned out to be quite a lot of work. Since this issue isn't considered high priority, it's being worked on on a best-effort basis, and we haven't managed to dedicate sufficient time to get something merged. We have made a small amount of progress since the previous update above:
|
This comment has been minimized.
This comment has been minimized.
2 similar comments
any updates here? |
any updates here? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Note for whoever picks this up next: Take a look at the comment here. |
this is an outdated wrapper also it requires a new aar to allow the ffmpeg decoders to work |
this would be enough to be merged to the ffmpeg extenstion |
checkout this library for the implementation of FfmpegVideoRenderer: https://github.com/anilbeesetti/nextlib |
I was having difficulties to use the extension |
I apologize for filing this as an "issue", unfortunately github doesn't provide too many avenues of communication.
I have considered writing my own FfmpegVideoRenderer (or perhaps using libx264 directly) to software decode unsupported formats for viewing on the phone. I was mostly curious if this has been attempted before, and dropped due to technical reasons or perhaps someone had already planned on working on it?
The text was updated successfully, but these errors were encountered: