Mailing List Archive

ffmpeg and mythtranscode
In my project of updating the deprecated ffmpeg calls, I got to
"avcodec_encode_video2", which is the function that passes frames to
ffmpeg for encoding. It is replaced by avcodec_send_frame and
avcodec_receive_packet.

It seems the main use of video encoding is for mythtranscode. It is also
used for nuppelvideo recording.

I have never used mythtranscode, commercial scan or the editing features.

I tested transcode without my changes. I selected the highest resolution
it would allow in the setup (720x480), and selected mpeg-4 (there are
only 2 options, mjpeg and mpeg-4). I ran it on a 1.0 GB 1080i (mpeg2)
file and it produced a 1.5 GB 1920x1080 nuppelvideo H263 file. This
seems less than useful and I question whether it is still used or
needed. Selecting mjpeg produced a 2.7 GB file, even less useful.

With my changes, transcoding to mpeg-4 produced a 1.5 GB unplayable
file, with no error message during transcode but huge numbers of errors
during failed playback.

I checked the code and it seems to be calling everything correctly.

At this point I am leaving the deprecated avcodec_encode_video2 in
place. Maybe the entire transcode process should be deprecated, or maybe
it should be fixed so it is useful and actually produce a smaller file
than the original. H264 would be a better choice.

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: ffmpeg and mythtranscode [ In reply to ]
Mythtranscode can do more than nuppel or mjpeg,

I would have loved to drop all those weird formats, but you still have
users with nuv recorders. That thing never dies.

On Mon, 4 Dec 2017 at 10:07 pm, Peter Bennett <pb.mythtv@gmail.com> wrote:

> In my project of updating the deprecated ffmpeg calls, I got to
> "avcodec_encode_video2", which is the function that passes frames to
> ffmpeg for encoding. It is replaced by avcodec_send_frame and
> avcodec_receive_packet.
>
> It seems the main use of video encoding is for mythtranscode. It is also
> used for nuppelvideo recording.
>
> I have never used mythtranscode, commercial scan or the editing features.
>
> I tested transcode without my changes. I selected the highest resolution
> it would allow in the setup (720x480), and selected mpeg-4 (there are
> only 2 options, mjpeg and mpeg-4). I ran it on a 1.0 GB 1080i (mpeg2)
> file and it produced a 1.5 GB 1920x1080 nuppelvideo H263 file. This
> seems less than useful and I question whether it is still used or
> needed. Selecting mjpeg produced a 2.7 GB file, even less useful.
>
> With my changes, transcoding to mpeg-4 produced a 1.5 GB unplayable
> file, with no error message during transcode but huge numbers of errors
> during failed playback.
>
> I checked the code and it seems to be calling everything correctly.
>
> At this point I am leaving the deprecated avcodec_encode_video2 in
> place. Maybe the entire transcode process should be deprecated, or maybe
> it should be fixed so it is useful and actually produce a smaller file
> than the original. H264 would be a better choice.
>
> Peter
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
Re: ffmpeg and mythtranscode [ In reply to ]
I thought we *had* agreed to drop support for non-hardware recorders after
29?

On Mon, Dec 4, 2017 at 5:49 PM Jean-Yves Avenard <jyavenard@gmail.com>
wrote:

> Mythtranscode can do more than nuppel or mjpeg,
>
> I would have loved to drop all those weird formats, but you still have
> users with nuv recorders. That thing never dies.
>
> On Mon, 4 Dec 2017 at 10:07 pm, Peter Bennett <pb.mythtv@gmail.com> wrote:
>
>> In my project of updating the deprecated ffmpeg calls, I got to
>> "avcodec_encode_video2", which is the function that passes frames to
>> ffmpeg for encoding. It is replaced by avcodec_send_frame and
>> avcodec_receive_packet.
>>
>> It seems the main use of video encoding is for mythtranscode. It is also
>> used for nuppelvideo recording.
>>
>> I have never used mythtranscode, commercial scan or the editing features.
>>
>> I tested transcode without my changes. I selected the highest resolution
>> it would allow in the setup (720x480), and selected mpeg-4 (there are
>> only 2 options, mjpeg and mpeg-4). I ran it on a 1.0 GB 1080i (mpeg2)
>> file and it produced a 1.5 GB 1920x1080 nuppelvideo H263 file. This
>> seems less than useful and I question whether it is still used or
>> needed. Selecting mjpeg produced a 2.7 GB file, even less useful.
>>
>> With my changes, transcoding to mpeg-4 produced a 1.5 GB unplayable
>> file, with no error message during transcode but huge numbers of errors
>> during failed playback.
>>
>> I checked the code and it seems to be calling everything correctly.
>>
>> At this point I am leaving the deprecated avcodec_encode_video2 in
>> place. Maybe the entire transcode process should be deprecated, or maybe
>> it should be fixed so it is useful and actually produce a smaller file
>> than the original. H264 would be a better choice.
>>
>> Peter
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
Re: ffmpeg and mythtranscode [ In reply to ]
On 04/12/17 21:06, Peter Bennett wrote:
> In my project of updating the deprecated ffmpeg calls, I got to
> "avcodec_encode_video2", which is the function that passes frames to
> ffmpeg for encoding. It is replaced by avcodec_send_frame and
> avcodec_receive_packet.
>
> It seems the main use of video encoding is for mythtranscode. It is also
> used for nuppelvideo recording.

That used to be true many years ago.

These days I would say that the primary use for transcoding is
"lossless" transcoding to remove commercials.

That way the actual encoding of the file isn't changed, just the
extra junk is removed.

Having said that, however, it currently only works for mpeg2
content, as nobody has ever got around to implementing it for
h264 or other newer container formats.

>
> I have never used mythtranscode, commercial scan or the editing features.
>
> I tested transcode without my changes. I selected the highest resolution
> it would allow in the setup (720x480), and selected mpeg-4 (there are
> only 2 options, mjpeg and mpeg-4). I ran it on a 1.0 GB 1080i (mpeg2)
> file and it produced a 1.5 GB 1920x1080 nuppelvideo H263 file. This
> seems less than useful and I question whether it is still used or
> needed. Selecting mjpeg produced a 2.7 GB file, even less useful.
>
> With my changes, transcoding to mpeg-4 produced a 1.5 GB unplayable
> file, with no error message during transcode but huge numbers of errors
> during failed playback.
>
> I checked the code and it seems to be calling everything correctly.
>
> At this point I am leaving the deprecated avcodec_encode_video2 in
> place. Maybe the entire transcode process should be deprecated, or maybe
> it should be fixed so it is useful and actually produce a smaller file
> than the original. H264 would be a better choice.
>

MKV containers seem to be a favourite target,
using h264 for video and AC-3 for audio

As jya said, the only other "encoding" use case is for frame grabber
type cards which need software encoding. I think these could also
be served by MKV/H264/AC-3 with an option of MKV/MPEG2/MP3 for lower
powered cpu's

Regards
Stuart

> Peter
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: ffmpeg and mythtranscode [ In reply to ]
On 05/12/17 00:55, John P Poet wrote:
> I thought we /had/ agreed to drop support for non-hardware recorders
> after 29?
>

With the current v4l2 devices available, do they do encoding on the
device, or do they still spit out raw frames?

Regards
Stuart

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: ffmpeg and mythtranscode [ In reply to ]
> On Dec 5, 2017, at 12:13 PM, Stuart Auchterlonie <stuarta@squashedfrog.net> wrote:
>
> On 04/12/17 21:06, Peter Bennett wrote:
>> In my project of updating the deprecated ffmpeg calls, I got to
>> "avcodec_encode_video2", which is the function that passes frames to
>> ffmpeg for encoding. It is replaced by avcodec_send_frame and
>> avcodec_receive_packet.
>>
>> It seems the main use of video encoding is for mythtranscode. It is also
>> used for nuppelvideo recording.
>
> That used to be true many years ago.
>
> These days I would say that the primary use for transcoding is
> "lossless" transcoding to remove commercials.
>
> That way the actual encoding of the file isn't changed, just the
> extra junk is removed.
>
> Having said that, however, it currently only works for mpeg2
> content, as nobody has ever got around to implementing it for
> h264 or other newer container formats.
>
[…]

What about transcoding to wireless-friendly formats? I think that if Myth is to have a future, it needs to work with whatever device the user wants. Phone, tablet, laptop, or something else (watch?).

Right now, HLS transcoding is pretty rough but sort of works.

Craig
(My 2 cents but I’m not the one to develop the code.)
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: ffmpeg and mythtranscode [ In reply to ]
On 12/05/2017 12:15 PM, Stuart Auchterlonie wrote:
> On 05/12/17 00:55, John P Poet wrote:
>> I thought we /had/ agreed to drop support for non-hardware recorders
>> after 29?
>>
> With the current v4l2 devices available, do they do encoding on the
> device, or do they still spit out raw frames?
>
>
There are some HDMI USB3 capture devices available now that use generic
USB protocols that are supported by Linux. I expect that these feed raw
video frames and would need some encoding support to use them.
Eventually cable cards will disappear and maybe those HDMI capture
devices could be an alternative for USA Cable subscribers.

Peter
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: ffmpeg and mythtranscode [ In reply to ]
On 05/12/17 19:01, Stuart Auchterlonie wrote:

> On 05/12/17 18:50, Paul Harrison wrote:
>> On 05/12/17 17:15, Stuart Auchterlonie wrote:
>>
>>> On 05/12/17 00:55, John P Poet wrote:
>>>> I thought we /had/ agreed to drop support for non-hardware recorders
>>>> after 29?
>>>>
>>> With the current v4l2 devices available, do they do encoding on the
>>> device, or do they still spit out raw frames?
>>>
>>> Regards
>>> Stuart
>>>
>> I have one that accepts HDMI in and outputs raw video frames and audio
>> and is seen as a standard v4l2 device. Doesn't currently work in Myth
>> but it would be nice if it did.
>>
>> Paul H.
> If you have it connected, i'd love to see the output from
> `v4l2-ctl --all`
>
> Not that i'll be able to do anything about it any time soon,
> I'm just curious at the moment.
>
>
> Regards
> Stuart
>

Back on the list :) I can't get used to Thunderbird replying to the
sender not the list by default it catches me out every time :(

This is the output after playing a stream at 1280x720 which is about the
limit I can get with my aging dev system with USB2. It will support a
large range of output resolutions from 640x360 up to 1920x1200
regardless of the input resolution though.

$ v4l2-ctl --all
Driver Info (not using libv4l2):
        Driver name   : uvcvideo
        Card type     : XI100DUSB-HDMI: XI100DUSB-HDMI
        Bus info      : usb-0000:00:13.5-6
        Driver version: 4.13.8
        Capabilities  : 0x84200001
                Video Capture
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x04200001
                Video Capture
                Streaming
                Extended Pix Format
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
        Width/Height      : 1280/720
        Pixel Format      : 'YUYV'
        Field             : None
        Bytes per Line    : 2560
        Size Image        : 1843200
        Colorspace        : sRGB
        Transfer Function : Default
        YCbCr/HSV Encoding: Default
        Quantization      : Default
        Flags             :
Crop Capability Video Capture:
        Bounds      : Left 0, Top 0, Width 1280, Height 720
        Default     : Left 0, Top 0, Width 1280, Height 720
        Pixel Aspect: 1/1
Selection: crop_default, Left 0, Top 0, Width 1280, Height 720
Selection: crop_bounds, Left 0, Top 0, Width 1280, Height 720
Streaming Parameters Video Capture:
        Capabilities     : timeperframe
        Frames per second: 50.000 (50/1)
        Read buffers     : 0
                     brightness (int)    : min=-100 max=100 step=1
default=0 value=0
                       contrast (int)    : min=50 max=200 step=1
default=100 value=100
                     saturation (int)    : min=0 max=200 step=1
default=100 value=100
                            hue (int)    : min=-90 max=90 step=1
default=0 value=0

Paul H.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: ffmpeg and mythtranscode [ In reply to ]
On 12/5/17 2:24 PM, Peter Bennett wrote:
> On 12/05/2017 12:15 PM, Stuart Auchterlonie wrote:
>> On 05/12/17 00:55, John P Poet wrote:
>>> I thought we /had/ agreed to drop support for non-hardware recorders
>>> after 29?
>>>
>> With the current v4l2 devices available, do they do encoding on the
>> device, or do they still spit out raw frames?
> There are some HDMI USB3 capture devices available now that use
> generic USB protocols that are supported by Linux. I expect that these
> feed raw video frames and would need some encoding support to use
> them. Eventually cable cards will disappear and maybe those HDMI
> capture devices could be an alternative for USA Cable subscribers.

I just recently renewed my quest for the holy grail in capture devices,
and failed to find one. On the plus side, there are now some cards which
output an H.264- or even H.265-encoded stream over TCP (and I'm not just
referring to HDMI "extenders", which use an Ethernet cable in a
non-Ethernet way.) The down side to these, for me, is that they all
still only encode 2-channel audio.

I'm tempted to try the Blackbox Decklink card, but given the reports of
various stability problems and the fact that they don't do compression,
I'm wary. Assuming the problems don't manifest themselves, if ffmpeg or
the like can't encode it in real-time I'd still have to spool the
incoming data to disk. And for 1080i that means 625Gb/hour just for the
video portion.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: ffmpeg and mythtranscode [ In reply to ]
On 12/05/2017 02:33 PM, Paul Harrison wrote:
> On 05/12/17 19:01, Stuart Auchterlonie wrote:
>
>> On 05/12/17 18:50, Paul Harrison wrote:
>>> On 05/12/17 17:15, Stuart Auchterlonie wrote:
>>>
>>>> On 05/12/17 00:55, John P Poet wrote:
>>>>> I thought we /had/ agreed to drop support for non-hardware recorders
>>>>> after 29?
>>>>>
>>>> With the current v4l2 devices available, do they do encoding on the
>>>> device, or do they still spit out raw frames?
>>>>
>>>> Regards
>>>> Stuart
>>>>
>>> I have one that accepts HDMI in and outputs raw video frames and audio
>>> and is seen as a standard v4l2 device. Doesn't currently work in Myth
>>> but it would be nice if it did.
>>>
>>> Paul H.
>> If you have it connected, i'd love to see the output from
>> `v4l2-ctl --all`
>>
>> Not that i'll be able to do anything about it any time soon,
>> I'm just curious at the moment.
>>
>>
>> Regards
>> Stuart
>>
>
> Back on the list :) I can't get used to Thunderbird replying to the
> sender not the list by default it catches me out every time :(
>
> This is the output after playing a stream at 1280x720 which is about
> the limit I can get with my aging dev system with USB2. It will
> support a large range of output resolutions from 640x360 up to
> 1920x1200 regardless of the input resolution though.
>
> $ v4l2-ctl --all
> Driver Info (not using libv4l2):
>         Driver name   : uvcvideo
>         Card type     : XI100DUSB-HDMI: XI100DUSB-HDMI
>         Bus info      : usb-0000:00:13.5-6
>         Driver version: 4.13.8
>         Capabilities  : 0x84200001
>                 Video Capture
>                 Streaming
>                 Extended Pix Format
>                 Device Capabilities
>         Device Caps   : 0x04200001
>                 Video Capture
>                 Streaming
>                 Extended Pix Format
> Priority: 2
> Video input : 0 (Camera 1: ok)
> Format Video Capture:
>         Width/Height      : 1280/720
>         Pixel Format      : 'YUYV'
>         Field             : None
>         Bytes per Line    : 2560
>         Size Image        : 1843200
>         Colorspace        : sRGB
>         Transfer Function : Default
>         YCbCr/HSV Encoding: Default
>         Quantization      : Default
>         Flags             :
> Crop Capability Video Capture:
>         Bounds      : Left 0, Top 0, Width 1280, Height 720
>         Default     : Left 0, Top 0, Width 1280, Height 720
>         Pixel Aspect: 1/1
> Selection: crop_default, Left 0, Top 0, Width 1280, Height 720
> Selection: crop_bounds, Left 0, Top 0, Width 1280, Height 720
> Streaming Parameters Video Capture:
>         Capabilities     : timeperframe
>         Frames per second: 50.000 (50/1)
>         Read buffers     : 0
>                      brightness (int)    : min=-100 max=100 step=1
> default=0 value=0
>                        contrast (int)    : min=50 max=200 step=1
> default=100 value=100
>                      saturation (int)    : min=0 max=200 step=1
> default=100 value=100
>                             hue (int)    : min=-90 max=90 step=1
> default=0 value=0
>
> Paul H.
> _______________________________________________

If there is a program that captures from the device and writes to std
output or to a file, you can use the import recorder. I recently
committed some contributed changes. I was able to successfully use a DVB
card with standard utilities, ffmpeg and the MythTV Import recorder to
schedule and make recordings on mythtv. It was just a proof of concept
because MythTV supports the DVB card anyway, but using the same method
you should be able to do something similar with other devices. See
https://www.mythtv.org/wiki/Import_recorder

Peter
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org